Slightly curious, what kind of projects were you working on that are "several hundred million LoC"... wouldn't 45-minutes be reasonable for that many lines of code?

I ask because I've never even come close to touching a project with that many SLOC and I was also under the impression that most modern operating systems are barely fitting into 100million+ LoC category, correct? This is your chance to redefine my perspective on "big project" haha.

A lot of the code may be automatically generated.

Some C# developers use T4 to generate data access code, for instance. This can amount to several hundred thousand lines of code for a moderately sized database. If there are several large databases being accessed, like is often the case in reality, then I could easily see there being millions of lines of automatically generated code in a single project.

I think when you hit several hundred million lines of code in a solution, a governor kicks in to give you more time to think about just what the hell you're doing.

If a single project is several hundred million lines of code, VS probably isn't the problem.

I know nothing about nothing, but having that many projects under the same solution its the biggest clue that you are doing something very wrong.

Even if you have a reason to have 40 projects in what should looks like one solution you can still create various solutions files with just the subset of projects you need. No one works on 40 projects at the same time.

We have a solution with more than 80 C# projects, and visual studio 2010/2012 handles it fine on modest hardware. I usually hit shift+F6 to build just the current project when I'm iterating on some change. This builds very fast because our individual libraries are small. It doesn't really feel "wrong".

Unless u have a very good reason to deploy and distribute 80 different DLLs it should feel wrong.

Many people think that In order to have a well layered and decoupled application you need to breakup every single piece in a separate project and that makes no sense. Thats what folders and namespaces are for.

For C#, maybe (not enough experience, but I would be surprised if what you say is a good practice).

For C / C++: You do that with static libraries, not shared libraries, and that's the only sane way to work: Have all library projects part of your main workspace, so you can easily debug and fix stuff in them, yet manage them independently.

For production/distribution you can always use a tool like ILMerge or SmartAssembly to merge dlls/exes together into something that makes sense for that particular distribution. I've had plenty of success with both tools.

Saying that, I do get what you're saying. Good practices can be taken to the extreme. Some approaches such as prism, take the idea of breaking the UI up into modules that can be registered with a shell - where on reflection, that type of flexibility is rarely going to be needed.

It's sadly far too common for .NET developers to carve up their solutions into far more projects than are necessary. This can seriously slow down compilation times.

Actually if you are changing a dependency right at the bottom of the chain, it makes things much faster as each compilation unit (assembly) is less likely to be coupled to the changed code.

Large assemblies are the enemy of compilation time as you can't partially compile them (like you can with java individual classes).

Yes but that's not the case if you're changing a dependency in the middle of the chain, as is more commonly the case.

Additionally, as far as I can tell, the main thing that slows compilation down isn't so much the actual compilation step as loading in and copying all the project references. Visual Studio does this separately, from scratch, for every project that you rebuild, since each project compilation runs in a separate csc.exe process.

Quote from Jeremy Miller: "I took 56 projects one time and consolidated them down to 10-12 and cut the compile time from 4 minutes to 20 seconds with the same LOC" (http://codebetter.com/jeremymiller/2008/09/30/separate-assem...)

It depends on the size of the project. Our dependencies compile into 130Mb of DLLs excluding all external references.

That's expensive to build.

In that case it's probably sensible to break it up not only into separate projects but separate solutions too.

What bugs me is when relatively small solutions are broken up into large numbers of projects. Very often it's done for no reason whatsoever other than aesthetics. They're often divided up "against the grain" too, putting every layer of your application (presentation layer, business layer, repository, domain model, services, interfaces etc) into a separate project, with the result that a single task requires you to make changes to several different projects.

The general rule that should be followed here is the Common Closure Principle: classes that change together should be packaged together.

Incremental compiler in C#: http://msdn.microsoft.com/en-us/library/aa691231(v=vs.71).as...

That was in 1.0 and 1.1. Gone in 2.0+

http://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%2...

Half of those projects could be class libraries. You can't put those in different solutions cause you miss the whole point of having everything tied up.

We don't have hundreds of millions LoC, but we have a couple of million. We solve the problem you are describing with svn:externals, pulling in the DLL/PDB from other project/solutions as needed on svn up.

I agree it's not as comfy as having everything in one big solution, but being able to count your compile time in seconds as opposed to minutes makes it worthwhile.

We used to use several different solutions with subsets of the projects, now though I use the solution load manager extension, http://visualstudiogallery.msdn.microsoft.com/66350dbe-ed01-... which brings down load times significantly. It basically lets you specify how projects should be loaded, so most can be loaded on demand. We have ~150 projects in total, ~10 million LOC, and VS handles it almost as well as a small solution.

I'm pretty sure I've read on an msdn blog that visual studio was 100 million loc total. I would be very curious to know what kind of projects you're working on.

My 100 MLOC figure is incorrect. The blog post actually states: "With upwards of 50 million lines of code, broad changes to Visual Studio can take some time to fully incorporate."

Here's the link: http://blogs.msdn.com/b/visualstudio/archive/2012/06/20/the-...

For what it's worth, I'm currently working on a number of C/C++ projects that amount to ~15MLOC. Visual Studio handles that load just fine.

Eclipse is fast, but it needs to be configured well and run on a decent system. I guess the same is true for VS. After all both wouldn't be so popular if they wouldn't scale.