Should a Visual Studio project be contained in more than one solution?

Question

Note: This is for a shop that works in C++, C++/CLI, and C# with some products being delivered as a combination of all three.

We currently have a rule that a project should have one and only one containing solution. The rule was originally instated because the source control plug-in for Visual Studio was unable to cope with projects that were contained in multiple solutions, always attempting to change the source control bindings when changing from one solution to another.

For other reasons, we are going to stop using the source control plug-in altogether (not dropping source control, just the brain-dead plug-in). It re-opens the question of whether or not to continue the policy of restricting projects to be contained in only one solution.

We have quite a bit of code in libraries, dlls, and assemblies that are consumed by multiple deliverable products, and we currently control this with a system of inter-solution dependency management whereby if one is working in the solution for an end-product, it is a simple matter to request a build of the dependency solutions, which kicks off other instances of Visual Studio to build them. The system works, but has the following drawbacks:

• The solutions for the common projects are often too fat, containing a few projects needed by the product being currently developed and usually a lot more that aren't needed for the development work at hand. They have merely been lumped into a sort-of catch-all solution that covers projects that are merely loosely related. This results in extended build times due to the compilation of unneeded code.
• Where we have tried to address the above fat solutions, we are often left with a too skinny solution that contains just one project. Each of these requires additional configuration in the inter-solution dependency management system. This, too, can increase build times as multiple instances of Visual Studio are spun up.

I am considering revising the policy to allow a project used in multiple deliverable products to be contained in more than one solution. We could eliminate the inter-solution dependency management and severely reduce the number of solutions (down to one per product). I am concerned about the amount of work this reorganization will take and whether or not it will be worth the effort. I'm afraid I won't even be able to detect the potential benefits until the team has been working with it for a while. I also foresee a couple of potential issues which are the true questions here.

• Do a large number of projects in a single solution pose any stability problems in Visual Studio 2005 (our current development platform)? Does it get any better in VS 2008 or VS 2010?
• If a project is contained in more than one solution, how can one manage the effects on the multiple solutions should project configurations be modified (such as adding a new configuration)?

To anyone already working in an environment with one solution per deliverable product, with common components as projects contained in multiple solutions: Have you encountered any significant drawbacks to such a configuration?

Answer 1

No, use as many solutions as is convenient.

For example, we have a large solution that builds about 53 projects. It includes an installer and uninstaller so that they can be conveniently built by our build server, but if I want to work on those applications, I load them in their own solutions (1 project each), rather than wasitng all that time loading 69 other unnecessary projects. They don't have any dependencies on the other projects, so there's no problem at all doing it this way (indeed, it's a lot more efficient as the solution loads and builds way faster)

The only caveat of multiple solutions is that you have to be careful in any case where you don't build a dependency (e.g. if you don't build a library, then you need to be careful that it gets built whenever the source code for it changes, because it will no longer be built automatically for you)

edit

To answer the last part of your question (because SO takes the question away while you're editing the answer!), the only problem with Solutions in VS2005 is that it is very slow with a lot of projects in them. VS2008 is much faster at loading a large solution, but the main hit is just that the more projects there are in a solution, the longer it takes to build (even if it is just skipping projects that don't need to be built, it takes a long time)

If you add a new solution configuration, then just make one uber-solution (or just keep your existing one!) and then make your changes in that so that they are applied to all porjects in one go. You will still have to add that new configuration to any separate solutions you want to use, but if they're one-project solutions you can just delete them, load up the .csproj and it'll be rebuilt automatically with all the configs in it. And adding new configurations probably isn't going to happen very often.

Answer 2

I too work in an environment that has many common projects that are used in several deliverables. Our policy has been one solution per deliverable application. So a common project may be included in several solutions. This has worked well for us. The common projects, while contained in separate solutions, all map to the same source code repository locations. So if the common code is changed, all containing applications are affected (our continuous integration system) serves as a check that other applications do not break as a result of the change to the common code.

The more projects you have in a VS solution, the longer it takes to load and it just sounds complicated having to manage different build configuration and dependencies in a single solution.

Answer 3

The main problems with having one project in several solutions are:

• If you make a change in the project, it may cause a compile error in another solution in which it is used.
• The solutions must constantly be updated to keep up with the changes in the common projects

The benefit of having a project in each solution that it is used is:

• It is easier to debug when you can follow the problem done to the souce code.

Another way to do it would be to have each solution use the the dll's of the common projects that they require. Then each solution can decide when they want to change which version they use.

The number of projects in a solution is not a major problem. But it will make the sollution slower to load and build. We have solutions of over 50 projects.

Answer 4

We have a "master solution" that contains over 100 projects. This took forever to load in VS.2005 until Microsoft released Intellisense fixes described here.

Our automated "continuous integration" build procedure always builds the master solution. For development, I divide the "master solution" into smaller solutions that contain a subset of related projects. Maintaining this structure takes some time when new projects are added, but is well worth it.

The only problem I've discovered with projects in multiple solutions is avoided by using $(ProjectDir) instead of $(SolutionDir) in build rules, as the latter depends on how the project is loaded.

Answer 5

SO wouldn't let me more than one link. This fix is also required to load large solutions in VS.2005.