1

This question already has an answer here:

For example, I have multiple projects which shares some common libraries:

  • ProjectA
    • CommonLib1
    • CommonLib2
  • ProjectB
    • CommonLib1
    • CommonLib2

At the moment, they are all in one big repository:

  • ProjectA
  • ProjectB
  • CommonLib1
  • CommonLib2

However, I think it is better to have one repository for ProjectA and ProjectB. But how should I manage my common libraries? A common Repository?

The Problem I have with a common repository is: It is out of sync with the specific project repository.

E.g: I want to rollback ProjectA. Doesn't compile. Now I need to rollback CommonLib2. Check in. ProjectB doesn't compile anymore, since it uses methods, which CommonLib2 has not anymore.

My main problem is: How can I keep the Specific Project and the Common Project in Sync?

At the moment I use TFS VC. If there is no good answer for it, would it be for another VCS (e.g. git)?

marked as duplicate by Greg Burghardt, Community Nov 2 '18 at 12:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    While my possible duplicate talks about Git, the problem is the same. You have two projects with common dependencies that need to evolve at different rates. This is not a source control problem. It's a dependency management problem. Since you are in the .NET stack NuGet is the go-to solution. – Greg Burghardt Nov 2 '18 at 12:29
  • Yes, that was exactly my confusion. It seems to be more overhead then simple having a project reference in the solution, but seems to be way more robust. thx @GregBurghardt – Christian Gollhardt Nov 2 '18 at 12:35
  • 2
    Moving those libraries into separate projects and referencing them via NuGet is more complicated. This additional complexity is justified when these common dependencies must evolve at different rates for different projects. – Greg Burghardt Nov 2 '18 at 12:41
3

One simple approach is to treat CommonLib* as external dependencies - generate their deployables, store them in a separate repository, and copy them as needed into the deployables of Project*. That way, when (not if) ProjectA starts depending on a different versions than ProjectB you can easily link each of them to the specific versions of CommonLib* they support.

  • I am coming from a .net background. Does this mean, I need to copy a binary to the specific project and do a check in? How do I edit them? – Christian Gollhardt Nov 1 '18 at 4:37
  • 4
    @ChristianGollhardt In the .net world you'd use nuget. Create a nuget package as part of the build process with the appropriate meta data around version numbers dependencies etc. You can then store this in a repository. This could be a nuget server (there are numerous open source and commercial nuget repositories) or just a simple file share. Once you have this then you can reference the binaries from visual studio as you would any other nuget dependency – James Reed Nov 1 '18 at 9:29

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