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

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 de开发者_JAVA技巧pendency 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?

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.

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.

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 configurations and dependencies in a single solution.

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.

Tools for SLN file (Visual Studio Solution file) contains a tool that:

Make it possible to create filters for a SLN file. The way it work is that when the filter file is opened, a temporary solution is created dynamically. The created solution file contain only the projects that are specified in the filter, and all the dependencies of those projects. This make it possible to have a mega-solution that contain all the projects needed to build the complete system but still have the possibility to work efficiently on a subset of the system.

This removes a big part of the cost of maintain sub-set solution files for speed of development.

However you need to ask youself if you have more project files then you need, as combining project files can speed up compiles and loading of soltuions greatly.

There is now a free Visual Studio extension, "Funnel", that solves this problem by loading predefined subsets of the solution. The link is for VS2012-VS2015; there is also a VS2010 version referenced on the extension home page.

You can set up multiple profiles (i.e. project combinations). These are stored in a parallel solution.sln.vsext file and that file can be committed and shared with your team. While VS2015 has gotten much better at handling large, 100+ C/C++/C# project solutions, I find it particularly useful for excluding makefile projects that are built every time the solution is built.