Written November 19, 2006 at 20:10 MST Tagged continuous integration
I received the following question a couple of days ago:
What do you suggest when having a (in house) library being used by several independent projects?
In practice the simplest solution to this problem, and also (by coincidence) the one that causes the least headaches is to treat those "libraries" as just that, "libraries". It can be too tempting to come up with fancy solutions that brings in the source code of these "shared" projects into your solutions so that you can edit the library code on the fly when needed. This ,however, can open up a maintenance nightmare, as a change that is required for one dependent project may inadvertently cause a bug or disable functionality in another dependent project.
To save myself the pain of dealing with these shared projects, I treat them like I would any third party library. I take the dll's and place them in a subfolder of the lib folder of my project. The lib folder is where I place any 3rd party assemblies that I happen to be using on a project. Here is an example for a project I recently completed:
Inside each of these respective subfolders is all of the dll's required for that third party dependency. All I would have to do is create a new subfolder named using the in house library I want to consume, and I would drop the latest current version of that assembly into the folder under the lib directory.
As I am developing my dependent app against this library, I am shielded from any changes that may be going on with the "shared" project, as I am just making references to the dll that lives in my lib folder. If a feature gets added into the shared library that I would like to consume in my dependent project, I could follow these steps:
As you can see, extremely simple. This has worked for me on small, and very large projects. Hopefully you can take this idea and use it to fit your shared library dependency issues.