Solution with over 100 projects takes over five minutes to build

Question

I have a solution with over 100 projects. It takes a long time to build, and sometimes Visual Studio crashes during the build. How can I deal with this issue and minimize the pain? Have we gone horribly, horribly wrong somewhere?

Some background on the problem:

We are using CAB with WPF, and each module has a ui assembly and a "server" assembly, which is really just a layer for the database. There is only one team, with about 5 developers.

I don't know how many classes or how many lines of code.

Answer 1

You can right click on an individual project in the Solution Explorer and select the option to build just that project. If there are any necessary projects in the build order, it will build those too, but this allows you to only build the necessary items.

Answer 2

Your question is a bit short on specifics, but I imagine the crashing is just a workstation resource issue more than anything. 100 projects isn't a problem in itself as long as there are good reasons for having that many, but by the time you get to over 10 projects, I would hope that you have some sort of management structure in place for them.

Do you really need to be building all 100 projects, all the time? You can switch off individual projects for building using the configuration manager, and you can create solution files with a subset of the total number of projects.

For example, we have 36 projects for one of the enterprise apps I work with. Along with that, we have multiple solution files and configurations designed to allow our devs to load only the projects and configuration that they need in order to work with given subcomponents of the application. In other words, they're only ever loading some subset of the 36 projects. Our build server takes care of putting everything together.

I suggest doing some analysis on your application and finding out what you can consolidate, and what you can partition into other solution files.

Answer 3

Do they all need to build at the same time? If not, you can go into the Configuration Manager and only select the ones you need built at the present time.

Although it seems to me that 100 projects in a solution is quite a bit. Is this really necessary? Can you break it up into smaller related solutions, or are there really this many projects that are inter-dependent on each other?

Answer 4

Your question seems to have more to do with the design of your solution and less about the ability of VS to handle 100 projects. You really want to know if the fact that your solution takes a long time is a code smell for "holy crap we have designed this wrong".

If you have a 1:1 relationship between "UI" assemblies and "Server" assemblies, they are logically the same and could be combined.

It's ok for CAB/CAG module assemblies to have all of their dependencies in one assembly in my opinion. If you intend on sharing data access code across several modules, then it would make sense to break it out into a separate assembly.

If you decide this approach isn't appropriate, what we usually do is have several smaller solutions that allow us to test a few related modules together locally during development, but have one large solution that our build servers build out. This way, long build times are experienced by a dedicated build machine, rather than our local dev boxes (this is a good approach for even the smallest of projects, as well).

Answer 5

The default solution configurations Debug and Release always checks all projects, and builds the ones that are not up to date. You can create your own solution configuration where you disable the build option for projects that you know doesn't need checking.