Versioning and Solution Structure in Visual Studio

Question

I have a system that has three applications (one windows application and two web applications). These applications all share two assemblies in common. Therefore, I have 5 projects in total. In the past, I have had a separate solution for each project. This allowed me to version each assembly individually in source control. However, this has significant overhead because I have to open each solution separately to see if a change I made to one of the common assemblies broke any of the applications.

I have thought about moving to a structure in which one solution contains all of the projects. This allows me to immediately see the impact of any changes I make, but it leads to versioning problems. If I only change the common assembly, or only change one of the applications, each project / assembly is soon at a different version level. In source control, since the entire solution is together, I don't have a single version number to use within my project repository.

Each discussion that I have read seems to solve one problem or the other. Either multiple solutions for easier versioning or a single solution for easier dependency control.

What suggestions do people have to structure solutions / projects while being able to version the assemblies appropriately?

Answer 1

I would stick with multiple solutions. Your windows app really doesn't (and shouldn't) need to know what's going on in your web applications.

I work with a similar setup where we have multiple web apps with common assemblies shared between them. Having a daily (or continuous if your build times are fast enough) build helps greatly. We use NAnt and CruiseControl, but the available options are as plentiful as opinions.

If you go with a continuous build setup you can have the other solution builds (web apps etc) trigger after your shared libraries build and pass their unit tests. You'd still have to open the other solution but the build server can tell you if you need to.

Answer 2

Personally, I like the solution that favors easier dependency control. I'm much more worried about breaking changes than I am about having items at the same version #.

The only time I (personally) would be concerned about the version # is when I have to troubleshoot or do a bug fix. And if I have to do a bug fix, then I'm eventually going to recompile the code, and will have the most recent version. In all honesty, if there is someone out there running code that uses an older version of some shared class library I've developed, so what? If it works, what do I care if it's at an older version. It's likely the only reason there is a newer version is that some OTHER application written later needed additional functionality.

This, of course, assumes you're following the commandment "thou shalt not change shared assemblies is such a way that the change breaks existing code." Adding a new function is OK. Modifying a function so that it works differently internally, but returns the same result is OK. Changing a function so that it works for the new software but breaks existing software is NOT OK. Then worrying about versioning becomes a non-issue.

Of course, this could be because I've never worked in a shop where there is a reason for worrying about the version, so I'm expecting to be beat up for this answer, but even if I am, I'm sure I'll learn from the comments about why this is a bad answer, which is why I like this site anyway.