Skip to main content

In some deployment scenarios it is not possible to bundle everything into a single installer. This may be because you need to install some third-party software, or because your build process forces you to split a single product across multiple MSIs.

Although there is not much in the WiX documentation about this, it is possible to chain multiple MSI installers in a setup.exe wrapper so that the installers execute one after the other. The key to this is the setupbld.exe command-line tool that comes with the WiX 3.0 installation. Jon Torresdal has written a useful article on using setupbld.exe to force elevated privileges for an installer under Vista, and I recommend starting there for an explanation of how to prepare your build to generate setup.exe files. In addition to doing this, setupbld.exe can combine multiple MSI files into a single setup.exe installer. To do this use a command line like:

setupbld.exe -out $(TargetDir)setup.exe -msu FirstInstaller.msi -msu SecondInstaller.msi -setup $(ProjectDir)setup.exe

At the moment I'm in the middle of updating the NetworkedPlanet NPCL Schema Editor so that it works with Visual Studio 2008, a task that sets new standards for the word 'frustrating'. Anyway, having got my whine out of the way, I did find the fix for something which no amount of Googling revealed and I'm writing it up here in the hope that it might save some other poor soul from a bruised forehead.

One of the key steps in deploying a Visual Studio package is writing all of the correct package registration details into the target machine's registry. For my deployment I wanted to use the WiX toolset to create my installer. According to this MSDN article, you can use the tool regpkg.exe in the Visual Studio SDK to generate a .wxs file that contains the necessary WiX magic to get all of the package registration entries written by the installer. Its then just a question of writing the rest of the installer to put files in the right place, include the .wxs file with the right sort of invocation and off you go.

On testing the deployment on a clean Visual Studio installation I found that the project template I had created to allow users to choose to create an NPCL project didn't show up in the New Project dialog box. I could see that my Project Package was properly registered with Visual Studio on the target machine (as proof of which I could see it displayed in the list of registered extensions in the Help > About dialog box). I could also see that the project template was installed into the Common7IDEProjectTemplates directory as expected.

After much cursing, rebuilding, redeploying and retesting I finally went back to first principles and decided to compare my package registration key by key with another project package extension that I knew worked - in this case the WiX installation. What I found was interesting. This is the code generated for my project package's template registration by regpgk.exe:

<Registry Root="HKLM" Key="SoftwareMicrosoftVisualStudio9.0NewProjectTemplatesTemplateDirs{41a84a7e-462c-4a74-9559-3c2568001dc2}/1">

<Registry Name="SortPriority" Value="100" Type="integer" />

<Registry Name="TemplatesDir" Value="[$ComponentPath].NullPath" Type="string" />


And here, for comparison is the Wix registration

<RegistryKey Key="NewProjectTemplatesTemplateDirs$(var.WixVsPackageGuid)" Action="createAndRemoveOnUninstall">

<RegistryKey Key="/1">

<RegistryValue Value="WiX" Type="string" />

<RegistryValue Name="SortPriority" Value="30" Type="integer" />

<RegistryValue Name="TemplatesDir" Value="[VsProjectTemplatesWixDir$(var.VsVersion)]" Type="string" />



The key difference is that the generated registration doesn't set the default value for the /1 registry key. It appears that this default key value is actually the label for the project type that is displayed in the New Project dialog box, but the regpkg.exe tool doesn't generate a <Registry> tag to set its value. In the WiX schema there appear to be multiple ways to do this, and I found the syntax below worked for me:

<Registry Root="HKLM" Key="SoftwareMicrosoftVisualStudio9.0NewProjectTemplatesTemplateDirs{41a84a7e-462c-4a74-9559-3c2568001dc2}/1" Type="string" Value="NPCL">

<Registry Name="SortPriority" Value="100" Type="integer" />

<Registry Name="TemplatesDir" Value="[ptNPCL]" Type="string" />


As an aside, the regpkg.exe generates a .wxs file that uses the schema supported by WiX 2.0. I'm using WiX 3.0 for my installer, and it reports these <Registry> elements as deprecated. However, it does work and I can now get on with finishing off my installer.

I hope that this tip saves some one the hours that I will never get back again ;-)

It is very interesting to see that Amazon have now made available over 1TB of public data. Its great that all of this data is now available in one place, ready shredded into queryable structures that allows developers to get to grips with it and start to do something really interesting. But wait a minute, if I want the DBPedia dump I have to go here..., if I want the Wikipedia english articles I need to go over there. If I want the US census data from 2000 its this place, if its the census data from 1990, its somewhere else. Oh and don't even get me started on having to choose between Windows and Linux. What these data sets are are essentially separate database snapshots that you can load into your own EC2 instance in the Amazon cloud and then start processing.

Read more…