A useful principle in computer programming is DRY (Don’t Repeat Yourself). I am trying to follow this rule as I am refactoring a large .NET Framework MVC project by breaking it down into separate solutions.
One problem that I am still unable to resolve to my satisfaction involves a set of C# libraries (static functions, Authorization Attribute overrides, and others) that need to be identical in each solution. These solutions are pushed to TFS source control, which means that linked projects outside the solution will not copy to source control. In other words, all projects need to be contained within the solution.
This image is a (highly simplified) illustration of what I am trying to describe. My intention is for the top solution "C# .NET Framework Solution" to have the "master copy". The other solutions rely on those same libraries. While I can "link" to those solutions, that approach only works on the PC where those solutions are authored. Projects linked to outside the solution cannot be pushed (in my experience) to source control.
The approach I am using – which does work as intended – is to maintain my “master copy” of C# class libraries in a specific solution. I have manually copied the specific C# class library projects to each of the solutions that need them. The good thing is that because the “copied” project exists in the solution, the solution can be pushed to source control in the intended manner. The bad thing is that this is a “copy”.
My one question is this: is there a way to have the best of both worlds, where the C# library project exists in the solution, but if I make a change to the “master copy” all the “copies” in the other solutions are synced? Why would I want this? Imagine if the code does change in one or more of those libraries and I (or my successor) forgets to make those changes in all those other solutions? What if I make a mistake in one or more of the copies?
Is my current technique the only option I have, or is there a different way for me not to break the DRY principle?