For the past two years, I’ve been content to build my Visual Studio projects individually by hand through the graphical user interface. Each library we shipped had a vcproj file that we used to build a DLL. For each vcproj, we had to build release and debug versions. Some projects were dependent on other projects’ libraries so while a single DLL might be shipped, it may have taken 3 vcproj builds to build it. This was totally fine because the process was not so bad as the need to release these libraries was minimal and in between builds I earned a chance to relax browse the web a bit. However, that’s changed this year. This year we have to ship VS2003 and VS2005 versions of everything. Suddenly all the work has effectively doubled. Now I am not so happy to sit and build everything manually anymore, especially since as we near the dreaded release deadline, we need to distribute the latest DLLs for testing. This means building DLLs over and over again, for VS2003 and then again for VS2005.

I’ve finally concluded that enough is enough, I am going to automate the entire build process so that I can build all the DLLs we need without any user interaction. It’s actually a little known fact that Visual Studio supports non-interactive building through a batch script. The key is to run the “devenv.exe” executable with some choice arguments.

The most important thing to do in your batch script is to set up the command prompt environment properly for Visual Studio. The best thing to do is to call the vsvars32.bat file in your VS install (for 2003, it would be located in C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools or else %VS71COMNTOOLS%) from your batch script. Simply add the command below into your build script (let’s call it build.bat):

call "%VS71COMNTOOLS%\vsvars32.bat"

Once this is done, you’ll need to add a command at the end of build.bat to invoke Visual Studio and use the /Build (or /Rebuild) option followed by the configuration followed by the solution file (*.sln). Since I need to build a release and debug version, this is what my commands will look like:

devenv /Rebuild Release C:\path\to\my\project.sln
devenv /Rebuild DebugRelease C:\path\to\my\project.sln

That’s it! Simply do this for every project and every configuration. I like /Rebuild over /Build since it’s cleaner and less error-prone. If you have any dependencies, make sure to build those projects that have no dependencies first. I’ve also found that you don’t need to supply a .sln as a .vcproj will also suffice, contrary to MSDN documentation. If you need to check the logs for errors, it still creates a BuildLog.htm as is if you had built interactively. To check if the build went through, you could add a line in build.bat to run a find for “0 error” in BuildLog.htm. If a string gets returned, the build was good. Otherwise there was a problem and you should check the build log.

find "0 error" C:\path\to\my\Release\BuildLog.htm

I have different build scripts for each VS2003 and VS2005, and due to linking external DLLs, there is also some extra setup that goes on to make everything nice for VS2003 or VS2005. Make sure you set these up in your build script as needed for your projects.

For a list of all the options you can use with devenv.exe, simply launch the VS command prompt (see location in the picture) and type “devenv /?” or refer to MSDN documentation.

Automating these builds is a one-time process that definitely pays off every time you use it thereafter. It’s a huge time saver because you can just let it run in the background while you do more important work (Solitaire anyone)?

Related Posts

• Random Value Generator with String Arrays in C#