Tired Of Working With Big Visual Studio Solutions?

December 28th, 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:

full_solution_tree

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:

smaller_solution_tree

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:

dependencies

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

  • http://sergiopereira.com/blog Sergio Pereira

    For a moment I believed this would be very helpful for me… Until I tried and Resharper went berserk on the missing references, even though VS compiles the small solution just fine. Apparently I’m destined to eternal frustration with this large solution I have to work with.

  • http://elegantcode.com Davy Brion

    yea Resharper doesn’t recognize the stuff you use from projects that you didn’t include in your solution. In our case it’s usually not a problem since that only happens on pages that only use the old stuff…. we don’t have pages that mix the new and the old stuff.

  • http://www.jamiepenney.co.nz Jamie Penney

    Another problem I can see with this is if you are doing any refactoring, Resharper won’t pick up the references in the larger project. A good idea for a stable codebase however.

  • http://blechie.com/wtilton Willie Tilton

    Couldn’t you have two totally seperate solutions, and then just reference in the dlls from the other solution? This way you could have a lib or dependencies folder, which when you build from the first solution would copy the dlls into the folder, and then when you update your code the latest dlls would be included automatically. That way you wouldn’t have everyone on the team needing a rebuild and you’d still accomplish the same thing.

  • Friend

    most of the times, vs.net add-on’s are the main problem, not the ide itself.
    you are using resharper, your are using visual svn (based on the above images). these add-on’s monitor your codes and activities, so they will have the main impact.

  • http://elegantcode.com Davy Brion

    @Willie

    you can, but it’s not very practical if one of the referenced dll’s is updated pretty much every hour or when you need to make changes in multiple assemblies to implement a new feature

    @Friend

    Resharper and Visual SVN definitely introduce some extra slowness, but Visual Studio itself is the main culprit… for large solutions, Visual Studio is unbearably slow regardless of whether you have resharper/visual svn installed or not

  • http://www.merill.net Merill

    Having the solution on a different hard disk will solve your problem. See ScottGu’s post on it here.

    http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx