by So, you're writing an application, and you break down the functional parts to more base layer services and utility assemblies, and now you want to create a new application and re-use some of your code.
My “go to” answer has always been separate assemblies copied to a global project bin and then adding references to the bins in whatever application needs them. For example:
“Application 1” and “Application 2” represent two applications that are re-using logic. The “Libraries”directory off the root represents the project directory housing “Library 1” and “Library 2” which are the assemblies being re-used, they build to their respective bin directories. The “bin” directory off the root is the global bin where the binaries from “Library 1bin” and “Library 2bin” are copied to for re-use by the applications.
In the above scenario, the Applications reference the libraries from “monkk.combin” and as new versions of Library 1 and Library 2 are released, they can replace the existing ones when required.
The problem with this type of solution is that often times your libraries end up building on each other to create more complex libraries and soon you find yourself in an endless series of updating the various libraries for any new feature necessitated by the applications and so can lead to updating Application 2 because Library 2 had a for Application 1… Not Ideal!
So, what to do, what to do?!?
Well a technique I've now come to employ for just such scenarios is project references. I know, simple how could I not have thought of this? Well I had, but for some reason I've been ignoring them because it just didn't seem “right” because of how intimately coupled the assemblies and projects can become but truth be told, it's so natural (after being forced to use it) I don't know how I ever got along without it. I suppose the problem has been, when you use 3rd party assemblies, it's just not an options, and if all your library assemblies are supposed to be stand-alone assemblies, shouldn't referencing them both be the same?
Well no, it makes complete sense to modify various Libraries while working on Application 1, and likewise for 2. There are some areas for concern, such as not breaking Application 2 while modifying Application 1 and it's Library 2 use. But with a good set of Unit tests for both applications and the libraries themselves, you can do this with less risk. And of course best practices for published assemblies come into play such as adding new function signatures instead of changing existing ones (of re-factoring the internals in the process.)
This obviously applies more to companies writing their own frameworks where the libraries stay internal. My point is this doesn't really scale to mass consumer use due to support issues. In that case, as I'm sure you are, each binary is it's own and the extra work of version management of the application used assemblies, but such is life and it's what we're paid for so, enjoy!
—
Regards!