MsBuild and Installer Projects

I remember the first time I tried msbuild. I read about it and then found out that it can actually work with the VS generated solution files. Great. Seemed easy enough. But when I tried it, I got something like the following:

Project "C:\ZenUtils.sln" on node 0 (default targets).
Building solution configuration "DebugDefault".C:\ZenUtils.sln : warning MSB4078: The project file "ZenUtilsSetup\ZenUtilsSetup.vdproj" is not supported by MSBuild and cannot be built.


Hmmmmn. Not good. The short of it is the developers of msbuild never took into account Installer projects (.vdproj files). While this may change in the future, for now this is what we have. Unfortunately, it also takes msbuild out of the picture as the one-step master builder. You will need to run a solutions containing installer projects separately with devenv.com. Yes, this is a cumbersome step.

To minimize using devenv and maximize using msbuild, I do the following:

• Create 2 solutions. One is for my compiled components and the other is for my installer project(s)
• In the installer project, I manually add the compiled components back in, instead of using the project outputs. I lose some project references in the installer project, but as I found quarky in the first place, it wasn't really a loss.
• I also manually add back in needed merge modules. In my case, Microsoft_VC80_CRT_x86.msm for the common c/c++ runtime and Microsoft_VC80_MFC_x86.msm for MFC support and their associated policy files.
• Then I include the following tasks in my nant build file:
  

<target description="msbuild" name="MsBuildCompile">

    <echo message="Building Binaries">

   <msbuild project="..\..\Src\ZenUtils.sln">

        <arg value="/property:Configuration=Release">

        <arg value="/t:Rebuild">

</target>

<target name="BuildMsi">

    <exec

        program="devenv.com"

        basedir="C:/Program Files/Microsoft Visual Studio 8\Common7/IDE"
        workingdir="..\..\Src\Product"

       commandline="ZenUtilsInstaller.sln

         /Rebuild Release">

    </exec>

</target>

Automating the Build Process

This is the first in a series of articles about automating the build process. While the specifics often involve Windows and VS, hopefully this information is generic to applied cross-platform. The basics have been covered quite well elsewhere. One good resource is http://www.codeplex.com/treesurgeon/Wiki/View.aspx?title=DevelopmentTreeIntroduction&referring.

Briefly, essential tools:

• Compiler, Editor - VS - Actually not that essential, but is in quite common use and includes all the tools needed for compiling and linking. Even those people who use alternative tools, usually know something about how VS works.
• Source control - SVN - quite popular for the last few years and there is a reason for it. Easy to use and integrates well.
• Builder - msbuild - will control the building of the components, include with .NET framework.
• Builder - nant - will control the building of the components

It seems like there is sometimes a debate of which one to use, nant or msbuild, with various camps lining up on one side or the other. My solution is to use them both. More details, later, but in short, I like using msbuild and just give it my automatically made VS solution file and away it goes. I wrap this task (and others) in a nant build file, which is a little bit friendlier to hand edit.

• Unit Testing - nunit - For .NET components
• Unit Testing - UnitTest++ - Currently the one I like for c++

Directory structure

Having a consistent directory structure across components and projects is essential. I can't say more then already mentioned article and it's associated project, Tree surgeon http://www.codeplex.com/treesurgeon.

Using Ant's dotnet lib

The Ant framework now has support for using dotnet tools. Of particular interest, is support for msbuild, which is actually a similiar tool as Ant with Microsoft flavor to it. This can provide a lot variations for automated builds. However, there are few tricks in getting Ant's framework support for dotnet going. If you are having problems using or installing Ant's new support for dotnet, read on...

Ant's framework doesn't inherently support the ant-dotnet.jar until version 1.7.*. So, until then, you will need to patch ant to include. If you are an experienced java developer, this will be an old hat to you. If you are not that familiar with developing or compiling java components, follow the following steps (Note this assumes that have the java compiler installed and in your path):

1. grab this (http://cvs.apache.org/~bodewig/dotnet/ant-dotnet.jar) and place in the same dir as your other ant jars (assuming that you have set an environment variable ANT_HOME, when you installed ant, this would be %ANT_HOME%\lib) Note: My system kept on downloading the file as a '.zip'. It is actually a .jar. Rename as such if necessary.

2. . Also grab (this) XMLFragment.java java file. This is file that you will need to compile and add it into the main ant.jar You can do this by the following:

3. setup a src directory, to the effect of

<basedir>\apache\tools\ant\util

Basedir can be any dir, but the directory structure beneath must be the same.

4. copy the xmlfragment.java file into \org\apache\ant\dotnet\tools\ant\util

5. at a command prompt:

cd <basedir>basedir>\org\apache\ant\dotnet\tools\ant\util

6. javac -classpath %ANT_HOME%\lib\ant.jar XMLFragment.java

7. cd <basedir>

8. jar uvf ant.jar org\apache\tools\ant\XMLFragment.class

9. copy /y ant.jar c:\Java\apache-ant-1.6.5\lib

That's all there is to it.