Visual Studio 2010 has long been announced as a release where a lot of focus would go to the actual performance of the product. As most of you probably know, Visual Studio 2008 is already quite slow when working with large solutions. I really hoped that Visual Studio 2010 would solve that problem, so i was already quite worried when reports first came out that VS 2010 would be using WPF.

I’ve avoided the beta releases of VS 2010, and whenever i saw someone demo it i cringed when i saw how slow it reacted, even while writing code. And now i just read this post from one of the people in charge of Visual Studio 2010. Reading that post just sends chills down my spine. While they seem to be actively working on improving the performance of VS 2010, i think it’s very late in the product cycle for news like this to come out. With only about 3 months left before the release, i really wonder whether they can still deliver on their promise of a fast Visual Studio, and i certainly hope that late performance improvements don’t cause any annoying bugs.

Oh well, if it turns out to be a crappy Visual Studio release, we only have to wait 2 or 3 more years before they’ll fix it, right? Right? Guys?

It’s finally here… i’ve been using the betas for a while now with hardly any issues so this final release should be very solid as well. Most important improvement IMO is the improved performance and reduced memory overhead for large solutions. We all know Visual Studio is pretty slow when it comes to large solutions, and adding Resharper to the mix only makes matters worse (though it still improves your overall productivity a lot no matter what performance penalty is involved). This release should improve this, and the other new features are pretty good too. Be sure to check it out

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