.NET Configuring GIT environment and local build for working with multiple repositories with dependencies between them -

we have multiple teams working on large project divided multiple repositories , each team works on 1 or more repositories , of repositories shared among teams. security policy , dont give developer access repositories ones required project. our dev folder looks :

repos.folder   repo1   repo2   ...   repon   bin.folder 

the developer first download build server dlls bin folder, projects output bin.folder on local build through visual studio .

the problem , because not developers have projects , cannot reference projects .csproj files (as not have references) , reference them dll files in bin folder - developers can download them build server, , , when developer tries setup work space solution (.sln file) , visual studio not automatically detects build order of projects , each developer needs setup sln file himself going through each 1 of projects references -- tremendous overhead ...

wanted ask if has solution problem or if spots caveat/problem in our dev env , know how handle better.

thank you,

james

first of question if security gain in preventing developers access code outweighs problems causes.

but, assuming given situation, consider using nuget:

each project publish it's own nuget package, preferably using build server produces unique semantic version each build , package (ideally coupled version number version control system).

you can publish nuget packages internal feed (e.g. a file share or internally hosted nuget server).

the nuget packages can have dependencies reflect dependencies between projects. don't want have projects in same solution anymore.

this way dependencies between projects become totally independent of actual source code. don't have version control binaries. rather, exact versions particular code depends on clear reading version number packages.config file. makes version control , merging of code easier. makes projects less coupled , resulting components more reusable.

a drawback note, however, modifying dependency , consuming in project become more cumbersome. straightforward path update nuget package using build server , updating nuget package in consuming project.