Product Versions in MSI installers created with WIX - part 2

In a previous post I described how to change the version of MSI installers created with WiX.

This post discusses a way of linking the version number of an assembly (library, dll, executable) to the product version.

This is more suited to a library/framework, where you want to ensure that the product version is the same as the library/framework.

1. On the library project, edit the AssemblyInfo.cs file:

Remove these two lines:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

2. Create a new File called VersionInfo.cs on the Properties folder.

Contents of file should be:

[assembly: System.Reflection.AssemblyVersion("0.0.0.*")]

3. Edit the project file (you'll need to unload the project if you want to do it from Visual Studio) and at the end, you'll find a commented out section. Get rid of it (everything between <!-- -->) and add the following:

<Target Name="BeforeBuild"> < <WriteLinesToFile Condition=" '$(Version)' != '' " File="Properties\VersionInfo.cs" Overwrite="True" Lines="[assembly: System.Reflection.AssemblyVersion(&quot;$(Version)&quot;)] // Auto-generated by build process" /> </ </Target>

4. On the product.wxs file on your WiX project, just add the following:

<Product Id="12c0deff-c0de-c0de-c0de-123f422c0dea" Name="Name" Language="1033" Version ="!(bind.FileVersion.filAB3D3C60ED5901936249D5C56B6C90A6)" Manufacturer="ManyRootsofallevil" UpgradeCode="fafffaff-c0de-c0de-c0de-123f422c0dea">

Where filAB3D3C60ED5901936249D5C56B6C90A6 is the id of your library file

5. Finally, add the following to the wix project. Make sure this is on the initial PropertyGroup Element:

<Version Condition=" '$(Version)' == ''">0.0.0.1</Version>

You can now build this using:

msbuild solution.sln /p:Version=1.3.3.7

TIL - Build solution with msbuild using multiple reference paths

More Jenkins issues today with the build, in particular using multiple reference paths as we finally added some much needed trace logging to the build, so I changed the build command to this:

msbuild solution.sln /p:Configuration=RELEASE /t:Clean;Build /p:referencepath="C:\ReferencePath\Sharepoint;C:\ReferencePath\Log4Net"

Incidentally, if you want to run msbuild from PowerShell, the quotes need escaping:

msbuild solution.sln /p:Configuration=RELEASE /t:"Clean;Build" /p:referencepath=`"C:\ReferencePath\Sharepoint;C:\ReferencePath\Log4Net`"

TIL - Clean a build from MSBuild

Version numbers were wrong on the build as Jenkins was not cleaning the build before compiling so I changed the build command to this:

msbuild solution.sln /p:Configuration=RELEASE /t:Clean;Build

Incidentally, if you want to run msbuild from PowerShell, the build targets need protecting from the shell like this:

msbuild .\solution.sln /p:Configuration=RELEASE /t:"Clean;Build"

Cannot import the keyfile myfile.pfx - error 'The keyfile may be password protected'

I've been doing some work to use Jenkins for CI and last week when we added our first plug-in (MS Dynamics CRM) to the project, the build broke.

Plug-ins are libraries that need to be strongly signed so I had added a password protected signing key, which is just a PKCS#12 certificate, myfile.pfx.

This is the error I got:

Cannot import the following key file: myfile.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_A422D1337C0DEFF95

The solution was quite simple, I installed the key in the Jenkins server:

sn -i myfile.pfx VS_KEY_A422D1337C0DEFF95

sn is the .NET Framework Strong Name Utility and can be found here:

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\sn.exe

Since I try to keep the build server as clean as possible, I just copied the tool to the server, be sure to copy the 1033 folder too.

Note that if you don't use password protected signing keys this problem will not occur.