I recently started out working for a new client with an old legacy codebase in which there are multiple .net solutions, each typically hosts some projects unique to that solution but then "borrows" / "links in" (add existing project) some other projects which technically belongs to other solutions (at least if you go by the folder structure in TFS)
I have never seen a setup this intertwined, there is no clear build order, sometimes a project in solution A just reference dlls directly from the output directory of a project hosted in solution B, sometimes the project has just been included directly even if it resides FAR away in the folder structure.
It looks like everything has been optimized for developer laziness.
When I confronted them with why they didn't have a CI server they responded that it is hard to set up with the code organized like it is. (I'm setting it up now and cursing this code-organization)
The solutions are organized around deployment artifacts (stuff that needs to be deployed together are in the same solution) which I think is a wise decision, but the contents of those solutions (the projects) are all over the place.
Is there a consensus of a best practice to use when reusing common class libraries across multiple solutions / deployment artifacts,
- How to structure code in the VCS
- How to facilitate sharing of business logic between separate deployment artifacts