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?
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.