Wix 3.0 Web Application installer

Going through the exercise of converting a Visual Studio Installer for a web application into a Wix 3.0 installer. I have found several resources which have been invaluable so far:

First, is Jon Torresdal's invaluable WiX and DTF series, which has quite detailed instructions on how to develop Wix 3.0 installers in general, and web installers in particular.

My application consists of two different IIS applications with several hundred content files. Hand-coding the reference to each file would be unthinkable, and unmaintainable, so I had to come up with a solution which would automate the construction of the Component/File hierarchy from web deployment project's output filesystem structure. I did this by adding a pre-build step to the main Wix project, which does this:

- Run a tool which creates two .wxi files by recursing through the web applications filesystem structure. The tool I used is an xml preprocessor based on the one I wrote for CruiseControl.net, however you could easily write a C# console applet to do the same.

The output ends up looking something like this:


<?xml version="1.0" encoding="utf-8"?>
<Include>
<Component Id="C__255ccb909a60444bb9106f6e7e92c473" Guid="07c5697d-31a6-431d-b10d-e0771d2d0a20">
<File Id="_255ccb909a60444bb9106f6e7e92c473" Name="web.config" Source="C:\proj\falcon\buildout2\Setup\x86\Debug\\..\..\..\Company_Website\Debug\web.config" DiskId="1" KeyPath="yes" />
</Component>
<Component Id="C__1a74b7ddd09e4da99ad3d921841bf8fc" Guid="d0ad3e0e-2f6c-414a-b40a-03768a1d259a">
<File Id="_1a74b7ddd09e4da99ad3d921841bf8fc" Name="Login.aspx" Source="C:\proj\falcon\buildout2\Setup\x86\Debug\\..\..\..\Company_Website\Debug\Login.aspx" DiskId="1" KeyPath="yes" />
</Component>
<Directory Id="_d9aa774ef9914fb9bab8455b30217fd6" Name="bin">
<Component Id="C__b5096379faad4a2cbade8d7d7b324006" Guid="db9bdff1-2f25-447d-ae0e-13ef706119b8">
<File Id="_b5096379faad4a2cbade8d7d7b324006" Name="about.aspx.f634c32f.compiled" Source="C:\proj\falcon\buildout2\Setup\x86\Debug\\..\..\..\Company_Website\Debug\bin\about.aspx.f634c32f.compiled" DiskId="1" KeyPath="yes" />
</Component>
</Directory>
<!-- etc.. -->
</Include>


After these are generated, they are run through this simple XSLT transform (using the NXSLT3 tool) , to generate a corresponding .wxi file which contains ComponentRef elements for each component:


<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl"
>
  <xsl:output method="xml" indent="yes"/>

  <xsl:template match="/">
    <xsl:comment>This file was generated by applying the ComponentRef.xslt transform to a wxi input file</xsl:comment>
    <Include>
      <xsl:for-each select=".//Component/@Id">
        <ComponentRef Id="{.}"/>
      </xsl:for-each>
    </Include>
  </xsl:template>

</xsl:stylesheet>


You can then use the Wix preprocessor to include the various files in the right place so that the components are included in a feature.

.

Comments

Post a Comment

Popular posts from this blog

Web Deployment Projects targeting x64

I am working on an ASP.NET web application which has mixed-mode C++/CLI dependencies that call out to pure unmanaged DLLs. A new requirement is a 64-bit version of the application (it runs fine on Win64 in a IIS 32-bit app pool, but since 32-bit mode is an all-or-nothing proposition, it was decided we need a true 64 bit app.) I ran into a problem getting the Visual Studio Web Deployment Project to compile my app. It seems that aspnet_compiler.exe loads all of the dependencies during compilation, and the 32 bit compiler cannot load the 64 bit images (you get a "bad image format" error.) This is true even on Win64 build machines that have the .NET Framework64 (and therefore the 64-bit aspnet_compiler.exe) After a bit of spelunking through the .wdproj, I found that a relatively simple change to the MSBUILD file shipped with the WD project will allow this to work out. It simply forces MSBUILD to use the 64 bit compiler if the $(Platform) variable is set to "x64" Here is...
Read more

Unintuitive error in msi log when DTF is misconfigured

Took me a little headscratching to figure this one out. I was getting an error from my installer with the following text: MSI (s) (A8:50) [14:27:03:446]: Product: MyProduct -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_ConfigFile_Install_Immediate, entry: CA_ConfigFile_Install_Immediate, library: C:\WINDOWS\Installer\MSI51BF.tmp The problem was not really that a DLL was missing, but that I had a typo in my <CustomAction DllEntry="xxx"> declaration. The typo caused a mismatch between the DllEntry value and the actual name of the .NET method implementing the [CustomAction].
Read more

NServiceBus distributor configuration

Technical notes from figuring out how to deploy NServiceBus in a distributed environment, beyond the simple development setups: 1. In a pub-sub scenario, distributors do not need any configuration specific to the publisher they are distributing for, or the subscribers they are distributing to. The configuration they do need is to mainly to define unique queue names for the queues that the distributor owns: NServiceBus.Distributor.dll.config: <add key="DataInputQueue" value="MyDistributorDataInputQueue" /> <add key="ControlInputQueue" value="MyDistributorControlQueue" /> <add key="ErrorQueue" value="MyEnterpriseErrorQueue@machine" /> <add key="StorageQueue" value="MyDistributorStorageQueue" /> At runtime, the subscriber contacts the distributor, sending it a subscription message that includes the publisher's address and the subscription message type. This makes the distribu...
Read more