Reputation: 2795
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.
Upvotes: -1
Views: 375
Reputation: 2795
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
Upvotes: 1
Reputation: 4119
This can be done using dependency injection, instead of recompiling the code all the time, you rely on an xml configuration, in that way you don't need to recompile the code every time a dependency changes. But be aware that will work until you add new features or methods instead of removing or renaming the ones you use.
Below is one of the questions that have your same problem.
Dependency Injection - Choose DLL and class implementation at runtime through configuration file
Now, there is another thing. The tfs has an option of a Continuous Integration process that you can take advantage for, for that you should be an administrator of the tfs. You can specify an option of a Gated Check-In, to safe yourself from a crash when you change your code. Here is the documentation Gated Check-in
Now you can put for all your projects also a trigger on the tfs and if they point to a specific folder to monitor the changes over that folder, if someone checked-in a change on the dependent dll or project that is store there, then you can start an automated build on the tfs to see if that specific project compiles correctly or not using that new dependency.
Upvotes: 1
Reputation: 31616
If updating interfaces is causing rebuilds and the goal is not to have rebuilds against existing consumers on new changes, then one should not make changes to existing interfaces causing the rebuilds.
If new functionality is presented then a new interface should be created which can either inherit from a common interface as a base or even the previous interface; hence only exposing new functionality the new consumers.
Upvotes: 2