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?

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