What is the biggest VS "solution" you've ever seen?

Question

I once worked for a bank, and the solution contained 40 projects. It was .NET 1.1 and took forever to compile.

Answer 1

I regularly work on solutions of 30+/40+ projects.

Answer 2

We have a project which has over 50 solution files (each with over 5-6 projects). They all compile to one application. The reason we keep them as separate solution files is because if we put all projects in one solution file, Visual Studio will fall on its knees.

This is in Visual Studio 2005.

Answer 3

40 projects in one solution? I'd say the bank was doin' it wrong. The application I am working on consists of about 200 csprojs but those are split into about 70-80 semi-independent slns. The key is scripted builds.

I cannot imagine the pain of VS loading, (let alone compiling) in the bank's case.

Answer 4

I have a solution with a dozen projects and something like 20 different build targets (x86 and x64, release and debug, DLL or static lib, DLL or static CRT single and multithreaded, etc.. Not all combinations are used, but most are).

Fortunately, it's only C, so it compiles fairly quickly.

Answer 5

Our solutions consists of about 40 .NET projects (half of them are test projects). The editing speed in general is good, but only you edit just a single projects the whole solution was re-compiled in VS2005.

In VS2008 this behavior was improved so now if you change something in the entry- point all other projects won't get compiled.

As we are developing .NET CF applications we have 2 solutions (one for WinCE and one for Win32). What's very interesting is that the Win32 solutions builds about half as long as the WinCE solution...

Answer 6

The sourcebase I currently work on has 63 projects.

And yes.. it's bloody slow (and painful).

Answer 7

My daily work involves 3 SLN's

One is 66 Projects (Middletier) and the other two are seperate front ends (12 projects and 7 projects).

The middletier solution opens in about 30 seconds, and compiles in under a minute. I usually keep 2-3 instances of Visual Studio open at once.

Get a faster machine =)

Answer 8

I once saw a solution of 72 projects and it wasn't the only solution in the code base. Needless to say, full compilation was a dreaded affair.

Answer 9

Looks like a lot of you guys need to poke your project managers and get some kind of rethinking done as far as the organisation of the projects and solutions are concerned.

With applications that are made up of so many assemblies or other binaries a good automated continuous integration build process and changing your references from Project based to Assembly based is probably going to be much more efficient.

Surely it's rare for someone to need to have the entire application code or even the whole layer loaded in VS in order to get some work done?

Answer 10

The .sln I work with at work has 95 projects, and somewhere in the region of 3 million lines of code (some of which is older than me!)

These are all Native C++ projects, aside from a new C# project I added a few days ago.

Compile time is actually fairly reasonable (We also use Incredibuild to speed up full rebuilds), loading and editing in VS2008 is totally fine.

Answer 11

If you upgrade to Visual Studio 2008 it has a fix which makes it easier for working with large numbers of files (especially closing VS). We have a approx 30 projects in a solution and in VS2005 it was painful - not so much in VS2008.

Answer 12

171 VS 2005 projects in one sln. Changing from 'Debug' to 'Release' could take upwards of 8 minutes on my 3 GHz & 4GB RAM machine.

Using SP1 and a KB hotfix for handling a large numbers of projects, I brought it down to nearly a minute,

Answer 13

We had / have a solution that was upwards of 70 projects, no scripted builds so opening and compiling that sucker was no easy feat.

Answer 14

The solution I am working on right now has 41 projects that compile...there might be more projects but they aren't set to build.

Answer 15

My biggest solution is getting up to 30 projects.

Answer 16

The library I'm currently working in has 1 solution file and (currently) 98 projects, representing roughtly 5 million lines of (C++) code. Compilation (distributed over roughly 20 machines) takes about 1hr.

Answer 17

I was involved in pulling together all of our project files into single solution files. All told, we have upwards of 70 projects in each of 4 main solution files (one solution file per product line; not the best way to do it, but that's how it is).

Loading the solution isn't so bad. It's the builds that take forever.

Answer 18

maybe windows :)

Answer 19

I prefer to keep a solution under 10 projects. Bigger than that and the solution tree just gets harder to navigate if you need to move around. Of course, if you really need to work on several projects at once, your project structure sucks. In general, I see no need for many projects in a solution.

Keeping many things in one soltion is also an indicator of a bad versioning policy - a project should generally be built from independent libraries, not a single tree at once. This smells of a lack of proper change management. Your program should work fine if you just compile the one bit you modified (even if it's the middle tier or backend) and keep the rest the same.

Answer 20

The C# team once got a support request from a customer with 1500 projects in one solution. As I remember, it was hitting some Visual Studio bugs that hadn't been noticed before.

Answer 21

The C# team once got a support request from a customer with 1500 projects in one solution. As I remember, it was hitting some Visual Studio bugs that hadn't been noticed before.

Any details on that?

What can such large projects be for? I am assuming for banks/public sector, but details would be great (I am intrigued).

I'm working on a system which has somewhere between 60-70 projects. I want to execute tests on modules seperately, so I have assemblies each dedicated to one business module (1:1 mapping). This will mean double the assemblies (ie 70 for business logic, exception handling, monitoring, whatever, and then one assembly with unit tests dedicated to one module).

I seem to hit a lot of Visual Studio bugs too, can't seem to find solutions for them. Of course, with such large solutions, the software will be pushed.

Answer 22

Just hit F5 on a solution with 67 projects. Popped in here while I wait for it to build.

It's not too bad with only one instance if VS9 running and frequent enough reboots but obviously aiming to reduce number dramatically. 20 would seem a reasonable threshold.

Answer 23

Our CMake script creates a solution for about 50-60 C++ projects. Compiling all of them takes forever because every project has about 6-8 configurations with a considerable use of templates and meta-programming.