The solutions in the project I’m working on are quite big and can easily take up 30 to 90 seconds to build, even though we have rather fast laptops. This is probably because of some build-plugins we are forced to use and the tight SharePoint integration of those plugins. Nevertheless, it’s quite annoying to see Visual Studio ‘hang’ every time you build your solution.
Last week I had some time on my hands to do some research on how we could improve these long builds. Turns out you can call MSBuild directly and let your solution compile outside of the Visual Studio instance. The build will still take up about the same amount of time, but it’s less annoying as you can still do some work in Visual Studio.
I’ve used Scott Hanselman’s blogpost to create some new External Tools in Visual Studio, placed them in my Menu and created keyboard shortcuts for them.
At the moment I’ve got 3 new items in my menu to build my complete solution, clean my complete solution and to build the project I’m currently working in.
The ‘Clean Solution’ button bound to the default out-of-the-box functionality, offered by Visual Studio.
The External Tool ‘Solution (MSBuild)’ is configured like so:
Arguments: $(SolutionFileName) /m:3 /p:BuildInParallel=true /v:m /p:WarningLevel=0 /p:Configuration=Debug
Initial directory: $(SolutionDir)
The ‘Current Project (MSBuild)’ is implemented like this:
De ‘External tool’ achter de optie _Current Project (MSBuild)_is als volgt:
Title: MSBuild Project
Arguments: $(ProjectFileName) /v:m /p:WarningLevel=0 /p:Configuration=Debug
Initial directory: $(ProjectDir)
For both ‘tools’ I’ve set ‘Use Output Window’ to true.
What you are doing here is telling to do use 3 cores (/m:3), build the projects in parallel (/p:BuildInParallel=true (default)), use minimal logging (/v:m), ignore warnings (/p:WarningLevel=0) and use the debug configuration (/p:Configuration=Debug).
You can also add keyboard shortcuts to the options, this can be done in the screen below.
Disclaimer: copy-paste image of Scott Hanselman’s post
As Scott already mentions in his post, errors aren’t listed in the Error List of Visual Studio, but in the Output Window. If you’ve got a lot of errors, this can be quite annoying.
One other gotcha is the post-build step which is configured in some projects. We’ve got several projects which have post-build steps doing stuff, like aspnet_merge to merge all the usercontrols in the dll’s. This didn’t work anymore.
Apparently, this option, When the build updates the project output, doesn’t work properly with MSBuild:
You have to set it to _On successful build_in order to run the post-build steps.
After having configured this, you are good to go and able to enjoy a responsive Visual Studio again. Also note, we are still working in Visual Studio 2008. It is said performance is a lot better in Visual Studio 2010 and Visual Studio 2012, but I haven’t used these products on this project yet, so I’m not sure about that.
There are also some other Visual Studio performance tuning tips, James Lewis has summed some of them up in a blogpost.