Home » Wix Target for MSBuild

  • Wix Target for MSBuild

    Wix Target for MSBuild

    Wix is great, but having to use the commandline tools is not so cool to do. So, to save time and effort I made a MSBuild target to do the heavy lifting. Be aware that I haven't fully tested all possible scenario's, so there might be some room for improvement.

    Installation

    To install the build target, just copy the contents of the Wix folder in the zipfile over to your "%programfiles%MSBuildWix" directory.

    Configuration

    The build target needs some configuration, the properties described below can be configured using a <PropertyGroup> element inside your buildscript.

    • WixToolsPath – The path to the location where WiX 2.0 is installed (Default is: C:Program filesWindows Installer XML)
    • OutputDirectory – The path where to put the created msi file
    • InstallerName – The name of the installer, without extension
    • SourceBasePath – The path where the sourcefiles are located

    Usage

    To use the Wix build target you need to include the targets file using the following statement:

    <Import Project="$(MSBuildExtensionsPath)WixWix.targets"/>

    You also need to provide the target with a set of scripts to compile and optionally the necessary libraries and localization files to complete the installer. All of these files are divided up into three itemgroups.

    • WixLibrary
    • LocalizationFile
    • WixScript

    The custom target can be called from targets defined in your buildscript. A sample on how to use the Wix target shown below:

    <?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="CreateSetup">
  <!-- Include the custom build targets -->
  <Import Project="$(MSBuildExtensionsPath)WixWix.targets"/>

  <!-- Item group for the localization files -->
  <ItemGroup>
    <LocalizationFile Include=".langWixUI_en-us.wxl"></LocalizationFile>
    <LocalizationFile Include=".langen-us.wxl"></LocalizationFile>
  </ItemGroup>

  <!-- Item group for the libraries needed by the installer -->
  <ItemGroup>
    <WixLibrary Include="$(WixToolsPath)binwixui.wixlib"></WixLibrary>
  </ItemGroup>

  <!-- Item group for the Wix scripts -->
  <ItemGroup>
    <WixScript Include="Product.wxs"></WixScript>
  </ItemGroup>

  <!-- Target to build the actual installer -->
  <Target Name="CreateSetup">
    <!-- Snip -->
    <CallTarget Targets="BuildWixInstaller"/>
  </Target>  
</Project>

    Drop me a line if you have improvements. 🙂

    Share this

Leave a Reply

5 comments

  1. No improvements 🙂 but there is already a MSBuild tasks library with Wix and more various tasks. http://www.codeplex.com/sdctasks

    kawail Reply

  2. Looks interesting, I’m going to keep that one in my favorites.

    willemm Reply

  3. Did you check out the Visual Studio 2005 project types for WiX? These project types are created by the same team that is building WiX. The project types also use MsBuild tasks to compile the WiX code.
    url: http://wix.sourceforge.net/votive.html

    martijnb Reply

  4. Those are cool projects for Visual Studio. Perhaps a great replacement for the not-so-cool setup projects that you have OOB.

    Anonymous Reply

  5. I did notice those on the WiX site, but I didn’t know they used MsBuild tasks internally (A typical doh moment, as VS2005 uses Msbuild for almost every file or project that needs to be compiled or transformed)

    However, these projects aren’t complete, I can’t move or copy files between a Wix project and other projects. Or my VS2005 installation must be broken again.

    I agree with Wouter that WiX is indeed a good replacement for the standard setup projects. You can do a lot more with WiX than you can with the normal setup project. At least without having to create your own custom installers for pretty much every server product.

    I created a setup project with WiX that configures user groups, creates an IIS website and configures a SQL 2005 database. I don’t want to try that with the normal setup projects as it will probably end in some pretty unmaintainable codebase.

    willemm Reply