This question is probably too wide but...
I have 300 projects (say project1_v1.sln, project2_v1.sln...) all dependent on 1 class library (say classLib_v1.sln), every 3 months we need to do a small amendment the class library (interfaces and implementation), which will break some of the projects, you then fix these projects and deploy....nasty....
BUT....
rather than amend the existing projects we would rather regenerate them as a new "branched" version....
so...clone classLib1.sln to make classLib2.sln make the ammendment, and then regenerate project1_v1.sln, to project1_v2.sln, which references classLib2 rather than classLib1.....compile....and fix.
I.e. have 2 versions of the every project.
feels like some sort of automated "production line", of products.
We do use TFS, but our version control is very linear, so I don't especially know how to deal with something like this without causing a mess.
thoughts?
There have been several useful responses, but just to be clear, this isn't about avoiding the breaking change, the code wILL break, its about automating a change (of a reference), and then using that automation to tell us where the code has broken.
Dependency injection has been toted as a solution, and it can be used, but you still need to automated the change to the configuration, and the downside is that configurable DI isn't type safe, so the compiler can no longer tell you where you've got a problem.
Ultimately I think this is a question about CI and sourcecontrol (not software architecture, DI and any other such things), sometimes, inevitably you have to apply a change that breaks something (unless you don't couple your code to any abstraxtions....and use CTRL C to share bahaviour!).
So the answer is...research how to use sourcecontrol and CI to stage development, UAT and production versions of a family of applications