.NET Configuración del entorno GIT y compilation local para trabajar con múltiples repositorys con dependencies entre ellos

Tenemos varios equipos que trabajan juntos en un gran proyecto dividido en varios repositorys, cada equipo trabaja en uno o más repositorys, algunos de los repositorys se comparten entre los equipos. Como política de security, no le damos a un desarrollador acceso a todos los repositorys, sino solo a los que se requieren para su proyecto. Actualmente nuestra carpeta dev se ve así:

Repos.Folder Repo1 Repo2 ... RepoN bin.folder 

El desarrollador primero descarga del server de compilation todos los files dlls a la carpeta bin, todos los proyectos se envían a esa carpeta bin así como a la compilation local a través de Visual Studio.

El problema es que, como no todos los desarrolladores tienen todos los proyectos, no podemos hacer reference a proyectos de files .csproj (ya que no todos tendrían esas references), pero los referencemos a files dll en la carpeta bin, para que todos los desarrolladores puedan downloadlos el server de compilation, Y ASÍ QUE, cuando un desarrollador intenta configurar una solución de espacio de trabajo (file .sln), Visual Studio no detecta automáticamente el order de compilation de los proyectos, por lo que cada desarrollador necesita configurar el file sln revisando cada uno una de las references de los proyectos, que es una tremenda sobrecarga …

Quería preguntar si alguien tiene una solución para ese problema o si alguien detecta una advertencia / problema en nuestro entorno de desarrollo y sabe cómo manejarlo mejor.

Gracias,

James

En primer lugar, me pregunto si el aumento de security para evitar que algunos desarrolladores accedan a algún código realmente supera los problemas que causa.

Pero, asumiendo la situación dada, consideraría usar NuGet :

Cada proyecto podría publicar su propio package NuGet, preferiblemente utilizando un server de compilation que produzca una versión semántica única para cada compilation y package (lo ideal sería que también esté acoplado a un número de versión del sistema de control de versiones).

Puede publicar los packages NuGet en una fuente interna (por ejemplo, un recurso compartido de files o un server NuGet hospedado internamente ).

Los packages NuGet pueden tener dependencies que reflejen las dependencies entre los proyectos. Probablemente ya no quiera tener los proyectos en la misma solución.

De esta forma, las dependencies entre los proyectos se vuelven totalmente independientes del código fuente real. Tampoco es necesario que la versión controle ningún binary. Por el contrario, las versiones exactas de las que depende un código particular son claras al leer el número de versión del file packages.config . Esto también facilita el control de versiones y la fusión del código. También hace que los proyectos estén less acoplados y los componentes resultantes sean más reutilizables.

Sin embargo, una desventaja es que modificar una dependencia y luego consumirla en otro proyecto será más engorroso. La ruta más directa será actualizar el package NuGet utilizando el server de compilation y luego actualizar el package NuGet en el proyecto consumidor.