This is really obvious and simple, but I never got the idea until now when I’m doing a bit of cleaning of my Maperitive code and trying some new approaches.
For all of the projects I’m working on I have the same basic convention: a Build.bat batch script which builds the release version of the solution, including all the testing and packaging. Build.bat is always stored in the solution directory and, if used without arguments, runs the complete build.
So why not integrate this directly into Visual Studio, instead of having a separate command line window?
The screenshots below are for VS 2010, but the same thing should work for older versions of Visual Studio, too.
Step 1: Add an external program
Go to Tools | External Tools … menu and add a new external tool like this:
Make sure you check the Use Output window checkbox - this will make sure the output of your build will be displayed inside Visual Studio and not run as a separate command line window.
Step 2: Add a keyboard shortcut
Go to Tools | Customize… menu, then click on the Keyboard button below. In the Show commands containing: text box enter the Tools.Extern text and find the external command under which your new Build Release is placed. In my case it is ExternalCommand1 because I have it at the first place in the list. Now add a keyboard shortcut to it:
I chose a relatively fiddly Ctrl+Shift+Alt+B hotkey because I wanted to avoid running the build by mistake - these builds can take some time to execute.
That’s it. Enjoy.
UPDATE: after running this for a day or two, I really see the benefits. It’s much easier to browse through the output of the build (and you get the whole output, not just the part that fits into the command line buffer). You can also use VS search to look for stuff like [failed] and you can copy the text from the output more easily.
I’ve also added an additional external command: Build.bat tests.debug which runs all the tests covered by the build script, but in a Debug mode. This way I can run the tests the way they are defined in the build script (first the quick unit test, then the slower integration tests etc.). This is something that is not really possible to do using TestDriven.NET or ReSharper.
There are two things that I miss though, although I can live without them:
- My build scripts use the console coloring to emphasize certain things (errors, slow tests etc.). The coloring is lost when you run the build inside Visual Studio’s Output window.
- The way the unit test framework (Gallio in my case) outputs errors in tests prevents the user for simply double-clicking on the error line and being shown the offending source code in VisualStudio.
