Tired Of Working With Big Visual Studio Solutions?
Posted by Davy Brion on December 29th, 2008
Ever noticed how Visual Studio can be painfully slow when it comes to working with big solutions? It starts using large amounts of RAM, building the project takes way too long, and with practically every change you make it has to rebuild a lot of the projects in the solution which can waste a tremendous amount of time if you add it all up.
Consider the following solution:
Now, i’m not going to get into the specifics of each project in this solution… most of these projects were created before i ever got involved with this project, and i’m not really happy with the entire structure. It’s a pretty big application, and a while ago we decided to move to a new architecture. But since we can’t just rewrite the whole thing, we put the new stuff (using the new architecture) in the same application and we’re going to gradually rewrite the old parts using the new architecture.
I wanted to keep the new stuff completely separated from the old stuff, so i added more projects to it (the EMS.* projects). Before i added the new projects to the solution, it was already painfully slow to use this solution with Visual Studio. After adding the new projects, it obviously only got worse. Since we’re spending most of our development work in the new projects, i wanted to see if i could simply create a new solution which would contain only the projects we usually need. That new solution looks like this:
Much better…. but now you’re probably thinking: doesn’t CMS.WebApplication reference any of the other projects? It does reference a few of them actually:
Visual Studio indicates that it can’t resolve these references. So this new solution isn’t usable, right? Well, it is actually. You just have to make sure that you’ve done a full build of the entire solution (the one that has all of the projects in it) before you build the small one. If you use the small solution after you’ve built the big one, Visual Studio is smart enough to remember where it got those compiled dependencies from in the first place.
So is this really usable? It sure is… we do most of our work in the smaller solution, and we can modify and recompile as much as we want without problems and without wasting huge amounts of time just waiting for Visual Studio and the compiler. The only issue we have with this approach is when we need to make changes in some of the older projects that aren’t in the small solution. Whenever someone makes a change there that requires a recompile of the CMS.WebApplication project, every teammember needs to recompile the entire big solution. But to avoid having to load the entire solution in Visual Studio, you can just run the following command in a Visual Studio 2008 Command Prompt:
msbuild ems.sln
and it builds the entire solution without using Visual Studio. After that, your smaller solution will work again.
If you’re working with big Visual Studio solutions and the slowness of this bothers you, be sure to give this a shot. You can create as many of these small solutions as you like, depending on which parts of the codebase you typically need to work with. It can easily save you a lot of time, and avoid unnecessary frustration as well 
For new solutions, i think it’s better to just keep the number of projects to a minimum which i’ve explained previously here
December 29th, 2008 at 2:22 am
Tired Of Working With Big Visual Studio Solutions?…
Track back from DotNetLinks.net…
December 29th, 2008 at 11:25 am
“Cucumbertime”?
December 29th, 2008 at 1:43 pm
[...] Via Alvin Ashcraft: Davy Brion offers an alternative to working with Big Visual Studio Solutions. [...]
December 29th, 2008 at 8:01 pm
This is a really great tip. One thing that you will have to be aware of when implementing something like this is circular references (particularly if you commit binaries to version control).
December 29th, 2008 at 9:20 pm
Doesn’t work for me at all. My WPF projects complain that dependencies are missing. What type of projects do you use? Plain C# only?
December 29th, 2008 at 9:25 pm
mostly ASP.NET projects, and C# class libraries
December 29th, 2008 at 9:31 pm
Another thing to note is, that msbuild WILL complain about missing references.
December 29th, 2008 at 9:43 pm
@David
in what situation? if you’re trying to build the smaller solution in Visual Studio (which uses MSBuild) without having built the complete one, it fails… like i mentioned in the post
but if you’ve built the larger solution before using the smaller solution, it works
December 29th, 2008 at 10:15 pm
I’d warn against this. While it can be tricky (especially if office politics come in to play) to structure the solution in a way that is both fast and developer-friendly, the way you have this will only make things more convoluted in the future. For example, when you add _another_ layer, what will you call the solution? EMS_NewNewNewArchitectureOnly? Or if you add a junior dev, they’ll need to have it explained that they must first download and build one solution, then download and build the second.
A better solution may be to properly version and separate everything. Create a separate EMS solution, and add a reference to the CMS dlls as needed. If you need to change the CMS code, build a new version and update your reference in EMS. Alternatively, if these are really part of the same product, keep them in one solution, but refactor to have less projects. For example, combine the Common class libraries into one of the others. Only physically separate a project if there is a real functional need. Use namespaces/folders for logical separation of code.
One great way to make this even easier is to put any file references (ie dlls that don’t live in Program Files or the GAC) in an empty project named “_FileReferences”. Set it to not build in any build config (rt click solution -> Build Configurations). Then, when adding a reference, add it from that location. This way, a developer can just get the solution from source control, build, and run. This adds some size to the solution, but is much easier than wrestling with reference locations, etc.
December 29th, 2008 at 10:20 pm
as far as telling newcomers how to use this, it’s really not that hard… both solutions are in the same folder structure. each project only exists in one location, the solution files just point to the included projects.
when someone new joins the project, we tell them to use the EMS_NewArchitectureOnly.sln solution, and if it doesn’t compile, run the local build bat file which simply does an msbuild of the entire solution. After that, it just works… we don’t need to wrestle with reference locations at all.
December 30th, 2008 at 5:50 am
This may not be the most perfect way of handling large Net applications. We have applications that we develop, which literally have over a hundred projects. We divide these up in multiple solutions.
The way we get around dependencies is to use a shared folder on the network which each developer has access to. Whenever a project is changed, it is rebuilt and the dll is copied to this shared folder (its all automated).
Each project has file references to DLLs of its dependencies (instead of project references). This allows everyone to have the latest DLL available as a reference when they build their project/solution.
December 30th, 2008 at 4:52 pm
At least we can agree that this is something Microsoft should look at. Whenever I work with pure C++ solutions, I find it amazing how fast everything is… In C# solutions hundreds of files are copied around all the time (even for just opening the solution). For big solutions (~100 projects), this can add up to 1 GB being copied around for no reason.
I like the idea to split stuff into multiple solutions, although that makes every ’svn update’ more expensive, because I would have to compile all the other solutions first. But with a nice msbuild script that can be solved.
December 30th, 2008 at 8:11 pm
I try msbuild and get “Solution file error MSB4054: The solution file must be opened in the Visual Studio IDE and converted to the latest version before it can be built by MSBuild” with either 2.0 or 3.5 version of msbuild. Note my project is .NET 2.0. I guess MSBuild only works with latest .NET version solutions.
December 30th, 2008 at 8:14 pm
probably using the wrong MSBuild version or something… Visual Studio uses MSBuild to build your solution, so if Visual Studio can do it, so can you
January 6th, 2009 at 3:43 pm
I would suggest create
a) add a solution folder (right click at the top in solution explorer and select add->new solution folder) which will tidy thing up a bit, or
b) if you’re concerned about compilation time copy all you DLLs from your big project that don’t change into a Project/BinRefs folder of your small project and reference those. By the sounds of it this is what you “really” want. Of course all your little projects in the big solution should have their own versioning first otherwise you’ll lose where you are.
Don’t get me wrong I’m all for the odd bodge but I reckon b) is a nicer bodge
January 7th, 2009 at 8:24 pm
This is my own experience and I’m not sure wither it is correct or not but it work find with us:
Separate each group of related projects in a solution folder. Then unload unused folders currenty by you. Use PowerCommands. It is very usefull.
Note:
1- Do not add reference to projects, but add reference to a dll from a hard disk shared folder for a project already exist in the solution to allow debug. Like this you can even unload shared projects and reload them if you want to modify them with any depth.
2- WcfSvcHosting is very bad. It compiles all wcf, dal and entity even you did not modify them. In this case keep maximum 5 wcfs with dals and entities project loaded and unload others to get the solution with 100s projects run in one second.
I have Q6600 with 4GB RAM
3- Do not use CodeRush
4- Do not use more that one IntelliSense. Disable Visual Studio IntelliSense if you use another one that both of them will parse the whole solution and even the framework.
5- Put the solution in a separate hard drive than the OS and the swap file.
6- Use Core to Quad processor and Compile 8 projects simultanusly.
Sorry from my miss spelling if any.
January 17th, 2009 at 4:31 pm
[...] buddy of mine had a great suggestion on how to work with large Visual Studio solutions. At my work it’s not uncommon for us to have Visual Studio solutions with as many as 45, 65, [...]
May 25th, 2009 at 2:37 pm
20 projects is a big solution !? OMFG !
I have Delphi Project Group (aka Solution in VS.NET) that have 153 projects and it’s not slow at all, I really have to think again about my transition in VS.NET
July 23rd, 2009 at 2:54 pm
Just an info. I reorganized my projects from ~80 to <20 and had a 2x faster build time. Even now, most of the build time is completely wasted copying files around (which under Windows, is especially slow).