MSBuild

Build 64-bit MSI file on Cruise Control

Steve Michelotti — Sun, 18 Mar 2007 00:44:00 GMT

There is a known bug when trying to build 64-bit MSI files. That is, the wrong InstallUtilLib.dll is embedded in the MSI. A workaround to that problem is to use Orca to manually manipulate the MSI file in embed the correct version - the workaround is documented here. However, what if you want to automate this process on your build server? Orca is a windows appication requiring user input.

To automate this from the command line, you can leverage a few lines of VBScript code that essentially duplicates the Orca functionality. Specifically, what we are trying to do is embed the 64-bit version of InstallUtilLib.dll into the MSI so that the BadImageFormatException does not rear its ugly head. The key line of the VBScript is the SetStream method of the Record object. The complete VBScript solution is shown below and can simply be invoked from CCNet using a standard command line task such as the Exec MSBuild task with the appropriate command line arguments.

Option Explicit
On Error Resume Next

Const msiViewModifyInsert         = 1
Const msiViewModifyUpdate         = 2
Const msiViewModifyAssign         = 3
Const msiViewModifyReplace        = 4
Const msiViewModifyDelete         = 6

If (WScript.Arguments.Count = 0) Then
Msgbox("No command line argument specified for MSI location. Please try again.")
Wscript.Quit 1
Else
AdjustInstallUtil()
End If

public sub AdjustInstallUtil()
On Error Resume Next

dim msiInstance : msiInstance = WScript.Arguments.Item(0)
dim installer : Set installer = CreateObject("WindowsInstaller.Installer")
dim installerDb : Set installerDb = installer.OpenDatabase(cstr(msiInstance), 1)
dim sqlCommand : sqlCommand = "SELECT * FROM Binary WHERE `Name`='InstallUtil'"
dim view : Set view = installerDb.OpenView(sqlCommand)

view.Execute()
dim record : Set record = view.Fetch()

If Not record Is Nothing Then
  const dataCol = 2
  record.SetStream dataCol, "C:\Program Files\CruiseControl.NET\64BitMSI\InstallUtilLib.dll"
  view.Modify msiViewModifyUpdate, record
  installerDb.Commit
End IF

'clean up
Set installerDb = Nothing
Set view = Nothing
Set installer = Nothing

'Error Handling
If Err.number > 0 Then
   Msgbox("Error while adjusting x64 InstallUtilLib: " & Err.Description & ": " & Err.Source & ": " & Err.number)
End If
end sub

MSBuild with Cruise Control .NET - Part 2 (NUnit)

Steve Michelotti — Sun, 25 Feb 2007 01:37:00 GMT

In a previous post, I laid out our standard structure for MSBuild with Cruise Control. Now I will show the details of FxCop and NUnit.

Now you want to run FxCop:
<Target Name="FxCop" DependsOnTargets="Build">
<Exec
Condition="Exists('$(CCNetWorkingDirectory)\SolutionAnalysis.FxCop')"
Command="fxcopcmd /p:"$(CCNetWorkingDirectory)\SolutionAnalysis.FxCop" /out:"$(CCNetArtifactDirectory)\SolutionAnalysis-Fxcop.xml""
WorkingDirectory="C:\Program Files\Microsoft FxCop 1.35"
ContinueOnError="false"/>
<Message
Condition="!Exists('$(CCNetWorkingDirectory)\SolutionAnalysis.FxCop')"
Text="This solution does not contain a SolutionAnalysis.FxCop file in the solution root." />
<Message Text="TestVar = $(TestVar)"/>
</Target>

You'll notice that this is looking for a "well-known" file called "SolutionAnalysis.fxcop" location in the root of our solution. You may have 20 projects on CCNet - this enables a standard structure across all solutions. If it doesn't find this file, it simply skips the step via the Condition attribute on the Exec task. This Exec task simply calls

MSBuild with Cruise Control .NET

Steve Michelotti — Sat, 24 Feb 2007 00:17:00 GMT

You want to set up a customizable, fully automated build process. You want your build process to incorporate FxCop, NUnit, NCover, etc. but you do not have the license for Team System. No problem. You can do all of this with free tools leveraging MSBuild and Cruise Control .NET (CCNet) as the basis of your solution. This is not new news. In fact, CCNet is probably the best known tool today to do automated builds. However, there are lots of different ways to implement your build process. I'm going to do a series of posts that provide a start to finish implementation of one way to set up your build server. The posts will eventually include custom MSBuild tasks, custom CCNet add-ins, 32 bit / 64 bit considerations, and building MSI files with MSBuild. In this post, I will just start with the primary structure and build process.

To kick off the MSBuild process, you'll use the standard "msbuild" task provided by CCNet pointing to the custom MSBuild project file that we'll construct "ccnetMSBuild.proj":

<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>C:\CCNetArtifact\MyProjectName\Working</workingDirectory>
<projectFile>C:\Program Files\CruiseControl.NET\MSBuildScript\ccnetMSBuild.proj</projectFile>
<timeout>600</timeout>
<buildArgs>/p:ProjectFile=$SolutionFile$</buildArgs>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
</tasks>

The basic outline of the msbuild script will be this:

Version assemblies in the current solution (details to come in a later post)
Do a Debug build (if compile fails, stop build)
Run FxCop on the solution
Run NUnit on the solution
Run NCover on the solution
If everything has run successfully, do a Release build

First, we utilize the standard msbuild task to do a Debug build. Why do a Debug build before a Release build? There are a couple of reasons. First, Debug is the default mode for the developer on their local systems. We encourage the developers to run FxCop locally before checking in - it's most convenient for them to be able to do this straight from Debug mode without having to first rebuild in Release mode. Additionally, we typically will set our NUnit projects to build only in Debug mode but not in Release mode because we do not want to deploy NUnit projects out to a production environment. Again, keeping it in Debug mode simplifies everything here.

This is the standard structure - in the interests of keeping this post a reasonable length, I will expand on the details on my next post...