Lately I have been having a look at the Microsoft Open Source project named Wix. The goal of this project is to provide an Xml DSL that allows the user to build deployment packages that are wrapped up in a Windows Installer package or ".Msi" file. The user can declare user interfaces that allow for additional meta data to be handed down to the installer and conditional information that will influence the deployment process. The meta data along with the components installed on the machine are registered with the Windows OS and on uninstall the removal instructions are executed which can once again query this meta data. Wix allows you to hook into or extend the component installation event sequence if required and custom actions (written in managed or unmanaged code) can query meta data provided by an Installer custom UI during install and uninstall.
Unfortunately Wix is not always 100% stable, and requires some knowledge of MSBuild and the Microsoft Build Engine.
Rob Mensching who works at Microsoft is the development lead on the project. Scott Hanselman interviews him on Hanselminutes podcast 195.
General rules when working with Wix 3.5 in a Visual
Studio
2010 environment.
a) Always use the latest version of Wix 3.5. (At the moment the latest version is 3.5.1916)
b) Wix functionality is not completely extensive and very often requires the user to develop a "custom action" to achieve the required goal.
c) Never make any changes to the MS Build or Wix target files. Attempting such a feat will put you in a world of pain.
d) Make note of where the new Wix target files are located. All VS 2010 Wix project files need to reference the Wix2010.targets file.
e) Wix 3.0 and 3.5 cannot run side by side on the same server. Upgrading Wix 3.0 to Wix 3.5 is a one way street.
f) Upgrading a solution from VS2008 to VS2010 will require you to upgrade Wix 3.0 to Wix 3.5 and will thus require you to manually edit each Wix project file and update the target file references in all of the wix project files (wixproj) referenced by the solution.
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.5\Wix2010.targets</WixTargetsPath>
<WixToolPath>$(ProgramFiles)\Windows Installer XML v3.5\bin\</WixToolPath>
g) There is a bug with Visual Studio 2010 whereby Wix projects are automatically checked out if you edit a Wix XML file (.wxs). Hopefully this will be patched up with Visual Studio SP1.
h) There is no single location for Wix documentation unfortunately. My next blog post will include all the useful internet links that contained information about Wix and MSBuild.
Issues experienced with the Wix installation:
1)
Wix Merge module built after the installer thus causing
the installer to fail. This was a bug with the Light.exe wix command line
utility which linked Wix projects.
C:\Program Files\Windows Installer XML
v3.5\bin\Light.exe ... error LGHT0129: Cannot open the merge module
'XXX' from
file
'XXX.msm'.
The command exited with code 129.
Done executing task "Light" -- FAILED.
Done building target "Link" in project
"YYY.wixproj" -- FAILED.
The bug has been “documented” here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Problem-with-build-order-under-MSBuild-4-0-td4903964.html
2)
Ensure that you have an output path declared in your
Wix project (.wixproj) file.
<PropertyGroup Condition=" '$(Configuration)'
== 'Debug' ">
<OutputPath>
XXX
</OutputPath>
otherwise the build will fail with:
heat.exe : error HEAT5313: Build error during
harvesting: C:\Program Files\MSBuild\Microsoft\WiX\v3.5\Wix2010.targets(425,7):
The
OutputPath property is not set for this project. Please check to make
sure that you have specified a valid Configuration/Platform
combination.
Configuration='Release' Platform='AnyCPU'
[YYY.wixproj]
heat.exe : error HEAT5307: Build failed. [YYY.wixproj]
The command exited with code 5307.
Done executing task "HeatProject" --
FAILED.
Done building target "HarvestProjects"
in project "YYY.wixproj" -- FAILED.
Target "_CheckForCompileAndLinkOutputs"
in file "C:\Program Files\MSBuild\Microsoft\WiX\v3.5\Wix2010.targets"
from
project
3) This is quite obvious but ensure that all your Wix extension projects (i.e. those which use the wix.dll) have been deployed to the Wix target
bin folder(C:\Program Files\Windows Installer XML v3.5\bin) otherwise you will receive the following error:
candle.exe : error CNDL0144: The extension
'C:\Program Files\Windows Installer XML v3.5\bin\XXXWixExtension.dll'
could not
be loaded because of the following reason: Could not load file or
assembly
'file:///C:\Program Files\Windows Installer XML
v3.5\bin\XXXWixExtension.dll'
or one of its dependencies. The system cannot find the file specified.
[YYY.wixproj]
The command exited with code 144.
Done executing task "Candle" -- FAILED.
Done building target "Compile" in
project "YYY.wixproj" -- FAILED.
Target "_CheckForCompileAndLinkOutputs"
in file "C:\Program Files\MSBuild\Microsoft\WiX\v3.5\Wix2010.targets"
from
project "YYY.wixproj" (target
"_CleanGetCurrentAndPriorFileWrites" depends on it):
Task "CreateItem" skipped, due to false
condition; (Exists('%(FullPath)')) was evaluated as (Exists('')).
Task "CreateItem" skipped, due to false
condition; (Exists('%(FullPath)')) was evaluated as (Exists('XXX.msi')).
Visual Studio IDE bugs relating to which have now
been
resolved with the latest version of Wix:
a)
Custom actions project type was missing in Wix3.5 1419.
This led me to believe that a normal C# library which references the
Microsoft.Deployment.WindowsInstaller library would suffice as a
custom action
library which unfortunately is NOT the case. Upgrading to Wix Version 3.5.1916 fixes this problem.
b)
Make sure you specify Mixed platforms as the active
solution platform for the solution which Team Foundation Build will be
using.
Configuration manager can be found in Visual Studio under Build --> Configuration Manager.
Hope this helps all the Wixers out there...