How to structure multiple overlapping solutions / projects in .Net

code-organizationdeploymentprojects-and-solutionsversion control

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

Best Answer

I have never been a fan of including existing projects that belong to other solutions. There are too many variables where making an edit to that project for 1 solution completely breaks something in another solution. Then by fixing that problem you end up breaking the original solution. Lather, rinse, repeat.

When this kind of dependency leaks into multiple solutions, I like to separate out the dependent code into its OWN solution and create a black-box library that is then included as a reference. My thinking is that your solutions were intertwined so that debugging could be done all the way into the shared project for every solution. If the library is built and tested properly, this kind of debugging really isn't necessary. The library should be able to stand on its own merits and should be tested thoroughly so that the expectations of any consumer project would be met consistently.

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

If you want a unified build process, then be sure to put branches/tags/trunk at the root, like this:

branches/
tags/
trunk/
  dev/
    ...

If you don't need a unified build process, then you can put branches/tags/trunks within each project if you want. However, it might be difficult to migrate to a unified build after having put them within each project. A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.

Personally, I like a unified build process. Furthermore, I don't think you should have a "dev" project. You should have projects directly under trunk, and then branch trunk into a dev branch. Use tags for releases. For example, I would do it like this:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

How to convince cowboy programmers to use source control

It's not a training issue, it's a human factors issue. They do not want to, and are creating road blocks. Deal with the broken group dynamics, what is the root cause of their objection - usually fear, is it just fear of change, or is it more sinister.

No professional developer today, or for the last 20 years, has resisted source control. Once, about 30 or 40 years ago, when computers were slow, source control even slower and programs consisted of one 500 line file, it was a pain and there were valid reasons not to use it. These objections can only be coming from the worst kind of cowboys I can think of.

Is the system forced on them making their lives difficult in some way? Find out what it is, and change the system to invalidate the objection. Repeat until done.

I suggest looking at GIT or Mercurial. You can create a repository in each source code tree, they won't even notice and can keep on hacking the way they do now. You can track the changes they have hacked into the code base, make commits, merge them into other source trees etc. When they see you do a merge of a weeks worth of effort into another product in seconds, they might change their ideas. When you roll back one of their screw ups with one command, and save their ass, they might even thank you (don't count on it). At worst, you look good in front of the boss and, for a bonus, make them look like the cowboys they are.

Merging would take not only a great knowledge of the project

In that case, I am afraid you're up the proverbial creek with no paddle. If merging is not an option, neither is implementing it, so you are saying that you can no longer add features you already have in one branch (term used loosely) to another.

If I were you I would reconsider my career prospects...

Best Answer

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

How to convince cowboy programmers to use source control

Related Topic