First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by different teams.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and to ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

  • @DocBrown yes, thank you for your edit.
    – Hopeless
    Commented Apr 19, 2021 at 6:39
  • Is the software mature enough to have releases with version numbers of its components? Commented Apr 20, 2021 at 23:27
  • Actually our teams are still developing on the versions (with bug fixes and new features) so I can say that it's kind of mature (used in production already) but of course that does not mean it has good quality.
    – Hopeless
    Commented Apr 21, 2021 at 6:11
  • Releases should go with published artifacts of the releases so you know they don't change under your feet. If you don't have that, you just release snapshots. Do you maintain old versions? Commented Apr 21, 2021 at 6:25
  • No actually we maintain the latest versions only. The old versions are used just in case of rolling back. But the point here is we have different small teams working on different projects. As I said, one project can reference others of course currently they can't be referenced directly but by adding dll files.
    – Hopeless
    Commented Apr 21, 2021 at 6:29

1 Answer 1


Before thinking about the tools, I would recommend to have a look at the process.

With multiple projects managed by multiple teams, if you don't want the teams and projects tied to each other, from an organizational point of view it is usually best only to only reuse released versions of the libs of other team's projects, ideally of a certain quality. That minimizes the risk of getting unwanted "breaking changes" into your own project when the other team does further development for the library, driven by the requirements of their own project, but not yours.

In a .Net/Visual Studio environment, this means the released versions can be either published as source code and/or in precompiled form (as a debug-mode DLL, a PDB for debugging, and a release-mode DLL). The precompiled form brings you the advantage of reduced build times for everyone. It may be necessary if the compilation of the lib requires additional tools which are not used by every other team.

Assumed your teams/projects work in different repositories, you have basically two options to distribute and deploy those libs among the teams, when you want to make sure you can reliably version the source code with all its dependencies, and a fully automated build process:

  1. Copy source code and precompiled DLLs/PDBs of a released library version into your own repo. This may not be resource efficient, as you noted in your question.

  2. Have a central server with the released versions of the libs, and an automatism which pulls during a build the required version automatically from there.

#2 is where tools like Nuget are for (a private Nuget server, for example). Instead of polluting your own repo with the source and DLLs of tons of other projects/libraries, you simply add Nuget package references to your csproj files, describing which lib and version you need. The Nuget server also knows about the meta data like version of the libs, compatible .Net framework versions, variants etc and lets you manage these things explicitly.

Of course, those internally developed libraries will have bugs and missing features, and often these issues will pop up the first time during reusage by a "foreign" project. Hence you also need a process for getting bug fixes and feature extensions back into the library development. How you do this precisely depends on your organization (for example, "do teams have write access to other team's repos?", "How do teams communicate at all?", or "do teams fix the reused libs first in their own fork of the lib"?) and the precise versioning and release strategy for each library (for example, "do teams fix bugs only in the latest version, or do teams provide patch releases to formerly released versions?").

However, bug fixing for foreign libs is usually more effort than fixing "own" libraries. That's why a certain quality of those libs is important. Automated tests can help to keep that quality above a certain level, and they can be also an instrument to communicate the bugs found by other teams, and avoid regression issues.

  • Thanks for your answer. It has a certain knowledge for me to deal with as well as discuss more about this issue with my team.
    – Hopeless
    Commented May 8, 2021 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.