WiX tricks and tips

Question

We ve been using WiX for a while now  and despite the usual gripes about ease of use  it s going reasonably well  What I m looking for is useful advice regarding    Setting up a WiX project  layout  references  file patterns  Integrating WiX into solutions  and build release processes Configuring installers for new installations and upgrades Any good WiX hacks you d like to share

User · Answer

Printing EULA from Wix3 0 and later  1  When you compile your wix source code  the light exe must reference the WixUIExtension dll in command line  Use the command line switch -ext  for this   2  If when you add the reference to the WixUIExtension dll  your project fails to compile  this is most likely because of clashes of Dialog IDs  i e  your project was using the same IDs of dialogs as some standard dialogs in WixUIExtension dll  give different IDs to your dialogs  This is quite common problem   3  Your license dialog must have ScrollableText control with the id  LicenseText   Wix searches for exactly this name of control when it prints    lt Control Id  LicenseText  Type  ScrollableText  X  20  Y  60  Width  330  Height  160  Sunken  yes  TabSkip  no  gt       lt Text SourceFile  License rtf    gt   lt  Control gt    and a PushButton which refers to the custom action   lt Control Type  PushButton  Id  PrintButton  Width  57  Height  17  X  19  Y  244  Text  Print  gt       lt Publish Event  DoAction  Value  PrintEula  gt 1 lt  Publish gt   lt  Control gt    4  Define CustomAction with the Id  PrintEula  like this    lt CustomAction Id  PrintEula  BinaryKey  WixUIWixca  DllEntry  PrintEula  Return  ignore  Execute  immediate    gt    Note  BinaryKey is different in Wix3 0 comparing to Wix2 0 and must be exactly  WixUIWixca   case sensitive    When user presses the button he she will be presented with the standard Select Printer Dialog and will be able to print from there

User · Answer

It s a nice structure but based on my experience I wonder how you address these conditions   A  Your installs all appear to land in the same destination  If a user needs to install all 3 versions at once will your process allow this   Can they unambiguously tell which version of every executable they are triggering   B  How do you handle new files that exist in TEST and or TRAINING but not yet in LIVE

User · Answer

Installing to C  ProductName  Some applications need to be installed to C  ProductName or something similar  but 99 9   if not 100   of the examples in the net install to C  Program Files CompanyName ProductName   The following code can be used to set the TARGETDIR property to the root of the C  drive  taken from the WiX-users list     lt CustomAction Id  AssignTargetDir  Property  TARGETDIR  Value  C    Execute  firstSequence    gt   lt InstallUISequence gt       lt Custom Action  AssignTargetDir  Before  CostInitialize  gt TARGETDIR    lt  Custom gt   lt  InstallUISequence gt   lt InstallExecuteSequence gt       lt Custom Action  AssignTargetDir  Before  CostInitialize  gt TARGETDIR    lt  Custom gt   lt  InstallExecuteSequence gt    NOTE  By default  TARGETDIR does not point to C    It rather points to ROOTDRIVE which in turn points to the root of the drive with the most free space  see here  - and this is not necessarily the C  drive  There might be another hard drive  partition  or USB drive   Then  somewhere below your  lt Product     gt  tag  you need the following directory tags as usual    lt Directory Id  TARGETDIR  Name  SourceDir  gt       lt Directory Id  APPLICATIONFOLDER  Name    var ProductName   gt           lt  -- your content goes here    -- gt       lt  Directory gt   lt  Directory gt

User · Answer

Instead of ORCA use InstEd which is a good tool for viewing MSI tables  Also it has the ability to diff two packages by  Transform -  Compare To     Additionally a Plus version with additional functionality is available  But also the free version offers a good alternative for Orca

User · Answer

Peter Tate has already shown how you can define reusable ComponentGroup definitions in separate wix fragments  Some additional tricks related to this   Directory Aliasing  The component group fragments don t need to know about directories defined by the main product wxs  In your component group fragment you can talk about a folder like this    lt DirectoryRef Id  component1InstallFolder  gt       lt  DirectoryRef gt    Then the main product can alias one of its directories  e g   productInstallFolder   like this    lt Directory Id  productInstallFolder  Name  ProductName  gt      lt  -- not subfolders  because no Name attribute  but aliases for parent  -- gt      lt Directory Id  component1InstallFolder   gt       lt Directory Id  component2InstallFolder   gt    lt  Directory gt    Dependency Graph  ComponentGroup elements can contain ComponentGroupRef child elements  This is great if you have a big pool of reusable components with a complex dependency graph between them  You just set up a ComponentGroup in its own fragment for each component and declare the dependencies like this     lt ComponentGroup Id  B  gt      lt ComponentRef Id   B    gt      lt ComponentGroupRef Id  A  gt   lt  ComponentGroup gt    If you now reference component group  B  in your setup because it is a direct dependency of your application  it will automatically pull in component group  A  even if the application author never realized that it was a dependency of  B   It  just works  as long as you don t have any circular dependencies   Reusable wixlib  The above dependency graph idea works best if you compile the big-pool-o-reusable-components into a reusable wixlib with lit exe  When creating an application setup  you can reference this wixlib much like a wixobj file  The candle exe linker will automatically eliminate any fragments that are not  pulled in  by the main product wxs file s

User · Answer

Here s a way to help large web projects verify that the number of deployed files matches the number of files built into an MSI  or merge module   I ve just run the custom MSBuild task against our main application  still in development  and it picked up quite a few missing files  mostly images  but a few javascript files had slipped through to     This approach  peeking into File table of MSI by hooking into AfterBuild target of WiX project  could work for other application types where you have access to a complete list of expected files

User · Answer

Creating Custom Action for WIX written in managed code  C   without Votive  http   www codeproject com KB install wixcustomaction aspx

User · Answer

Using Heat exe to smash face and inflict  Epic Pwnage  on painfully large installs    Expanding on Si s and  Robert-P s answers about heat   Translation   Using heat to avoid typing individual files into the project by hand and for automating builds for an overall easier process     WiX 2 0 Heat Syntax detailed   For newer versions  not all that different from older versions but there are potentially annoying syntax changes      go to the directory Heat is in from the cmd exe and just type in heat but I have a example one right here for help with newer versions if needed    Adding the following to your Build Event in visual studio 2010   Right Click Project- Properties - Build Events-  Pre-Build Events      WIX bin heat exe  dir    EnviromentVariable   -cg GroupVariable -gg -scom -sreg -sfrag - srd -dr INSTALLLOCATION -var env LogicPath -out    FragmentDir  FileName wxs    -gg   Generates Guids when heat is run as in when you execute the command above   -scom   Dont grab  COM files   -sreg   Dont grab  Registry Files   -sfrag   Dont grab  Fragments   -srd   Dont grab the  root Dir   dir  dir indicates you want Heat to look in a folder      EnviromentVariable    The name of the variable you would add to the Preprocessor variables in the  Right click project  Go to properties  project properties- Build section where it says Define preprocessor variables  assumes visual studio 2010   Example  EnviromentVariable C  Project bin Debug No double quotes but end with a semicolon  -cg GroupVariable   The ComponentGroup that will be referenced from the fragment created to the main wxs file  FragmentDir  The fragment directory where the output wxs fragment will be stored   FileName wxs  The the name of the file  Full tutorial here  So freakin helpful  Part 1 Part 2

User · Answer

We display the product version somewhere  tiny  in the first screen of the GUI  Because people tend to make mistakes in picking the right version every time   And keep us developers searching for ages    We ve set up TFSBuild to also generate transforms   mst files  with the configuration for our different environments   We know about all environments we need to deploy to      Since the original weblog post by Grant Holliday is down  I copy pasted its contents here     MSBuild task to generate MSI Transform files from XMLMarch 11 2008  In my previous post I described how you can use MSI Transform    mst  files to separate environment-specific configuration settings from a generic MSI package   Although this provides a level of flexibility in your configuration  there are two down-sides of Transform files    They   re a binary format You can   t    edit    or    view    a transform file  You have to apply it or re-create it to see what changes it includes    Fortunately we can use the Microsoft Windows Installer Object Library  c windowssystem32msi dll  to open MSI    databases    and create transform files   Credits go again to Alex Shevchuk     From MSI to WiX     Part 7     Customising installation using Transforms for showing us how to achieve this with VbScript  Essentially all I   ve done is taken Alex   s example and using Interop WindowsInstaller dll I   ve implemented an MSBuild task  The  MSBuild Task  Download the source code  amp  example transforms xml here   7Kb Zipped VS2008 Solution

User · Answer

Registering  NET assemblies for COM Interop with x86 x64 compatibility  NB This fragment is essentially the same as REGASM Assembly dll  codebase  A couple of things are going on in this sample so here s the code and I ll explain it afterwards        lt Wix xmlns  http   schemas microsoft com wix 2006 wi  gt     lt  include   sys CURRENTDIR  Config wxi  gt     lt  if   var Win64    gt     lt  define CLSIDRoots    CLSID Wow6432Node CLSID   gt     lt  else   gt     lt  define CLSIDRoots    CLSID   gt     lt  endif  gt     lt  -- ASCOM Driver Assembly with related COM registrations -- gt     lt Fragment gt       lt DirectoryRef Id  INSTALLLOCATION    gt     lt  Fragment gt     lt Fragment gt       lt ComponentGroup Id  cgAscomDriver  gt         lt Component Id  cmpAscomDriver  Directory  INSTALLLOCATION  Guid   0267031F-991D-4D88-A748-00EC6604171E   gt           lt File Id  filDriverAssembly  Source    var TiGra Astronomy AWRDriveSystem TargetPath   KeyPath  yes  Vital  yes  Assembly   net  AssemblyApplication  filDriverAssembly     gt           lt RegistryKey Root  HKCR  Key    var DriverId    Action  createAndRemoveOnUninstall  gt             lt RegistryValue Type  string  Value    var DriverTypeName    gt             lt RegistryKey Key  CLSID  gt               lt RegistryValue Type  string  Value    var DriverGuid     gt             lt  RegistryKey gt           lt  RegistryKey gt           lt  foreach CLSID in   var CLSIDRoots    gt           lt RegistryKey Root  HKCR  Key    var CLSID   Action  none  gt             lt RegistryKey Key    var DriverGuid   Action  createAndRemoveOnUninstall  gt               lt RegistryValue Type  string  Value    var DriverTypeName    gt               lt RegistryKey Key  InprocServer32  gt                 lt RegistryValue Type  string  Value  mscoree dll    gt                 lt RegistryValue Type  string  Name  ThreadingModel  Value  Both   gt                 lt RegistryValue Type  string  Name  Class  Value    var DriverTypeName    gt                 lt RegistryValue Type  string  Name  Assembly  Value    bind assemblyFullname filDriverAssembly     gt                 lt RegistryValue Type  string  Name  RuntimeVersion  Value  v2 0 50727   gt                 lt RegistryValue Type  string  Name  CodeBase  Value  file      filDriverAssembly     gt                 lt RegistryKey Key    bind fileVersion filDriverAssembly    gt                   lt RegistryValue Type  string  Name  Class  Value    var DriverTypeName    gt                   lt RegistryValue Type  string  Name  Assembly  Value    bind assemblyFullname filDriverAssembly     gt                   lt RegistryValue Type  string  Name  RuntimeVersion  Value  v2 0 50727   gt                   lt RegistryValue Type  string  Name  CodeBase  Value  file      filDriverAssembly     gt                 lt  RegistryKey gt               lt  RegistryKey gt               lt RegistryKey Key  ProgId  Action  createAndRemoveOnUninstall  gt                 lt RegistryValue Type  string  Value    var DriverId     gt               lt  RegistryKey gt               lt RegistryKey Key  Implemented Categories  Action  createAndRemoveOnUninstall   gt                 lt RegistryKey Key   62C8FE65-4EBB-45e7-B440-6E39B2CDBF29   Action  createAndRemoveOnUninstall    gt               lt  RegistryKey gt             lt  RegistryKey gt           lt  RegistryKey gt           lt  endforeach  gt         lt  Component gt       lt  ComponentGroup gt     lt  Fragment gt   lt  Wix gt    If you were wondering  this is actually for an ASCOM Telescope Driver   First  I took advice from above and created some platforma variables in a seperate file  you can see those scattered through the XML   The if-then-else part near the top deals with x86 vs x64 compatibility  My assembly targets  Any CPU  so on an x64 system  I need to register it twice  once in the 64-bit registry and once in the 32-bit Wow6432Node areas  The if-then-else sets me up for this  the values are used in a foreach loop later on  This way  I only have to author the registry keys once  DRY principle    The file element specifies the actual assembly dll being installed and registered    lt File Id  filDriverAssembly  Source    var TiGra Astronomy AWRDriveSystem TargetPath   KeyPath  yes  Vital  yes  Assembly   net  AssemblyApplication  filDriverAssembly     gt    Nothing revolutionary  but notice the Assembly   net  - this attribute alone would cause the assembly to be put into the GAC  which is NOT what I wanted  Using the AssemblyApplication attribute to point back to itself is simply a way of stopping Wix putting the file into the GAC  Now that Wix knows it s a  net assembly  though  it lets me use certain binder variables within my XML  such as the   bind assemblyFullname filDriverAssembly  to get the assembly full name

User · Answer

Using the Msi Diagnostic logging to get detailed failure Information  msiexec  i Package msi  l v c  Package log    Where Package msi is the name of your package  and c  Package log is where you want the output of the log  Msi Error Codes Wix Intro Video Oh and Random Wix intro video featuring  quot Mr  WiX quot  Rob Mensching is  quot conceptual big picture quot  helpful

User · Answer

Before deploying an install package I always control the content of it   It s just a simple call at the command line  according to Terrences post  open command line and enter  msiexec  a Package msi  qb TARGETDIR   CD  Extract   l vx   CD install log     This will extract package contents to an subdir  Extract  with the current path

User · Answer

Using Heat exe to smash face and inflict  Epic Pwnage  on painfully large installs    Expanding on Si s and  Robert-P s answers about heat   Translation   Using heat to avoid typing individual files into the project by hand and for automating builds for an overall easier process     WiX 2 0 Heat Syntax detailed   For newer versions  not all that different from older versions but there are potentially annoying syntax changes      go to the directory Heat is in from the cmd exe and just type in heat but I have a example one right here for help with newer versions if needed    Adding the following to your Build Event in visual studio 2010   Right Click Project- Properties - Build Events-  Pre-Build Events      WIX bin heat exe  dir    EnviromentVariable   -cg GroupVariable -gg -scom -sreg -sfrag - srd -dr INSTALLLOCATION -var env LogicPath -out    FragmentDir  FileName wxs    -gg   Generates Guids when heat is run as in when you execute the command above   -scom   Dont grab  COM files   -sreg   Dont grab  Registry Files   -sfrag   Dont grab  Fragments   -srd   Dont grab the  root Dir   dir  dir indicates you want Heat to look in a folder      EnviromentVariable    The name of the variable you would add to the Preprocessor variables in the  Right click project  Go to properties  project properties- Build section where it says Define preprocessor variables  assumes visual studio 2010   Example  EnviromentVariable C  Project bin Debug No double quotes but end with a semicolon  -cg GroupVariable   The ComponentGroup that will be referenced from the fragment created to the main wxs file  FragmentDir  The fragment directory where the output wxs fragment will be stored   FileName wxs  The the name of the file  Full tutorial here  So freakin helpful  Part 1 Part 2

User · Answer

Registering  NET assemblies for COM Interop with x86 x64 compatibility  NB This fragment is essentially the same as REGASM Assembly dll  codebase  A couple of things are going on in this sample so here s the code and I ll explain it afterwards        lt Wix xmlns  http   schemas microsoft com wix 2006 wi  gt     lt  include   sys CURRENTDIR  Config wxi  gt     lt  if   var Win64    gt     lt  define CLSIDRoots    CLSID Wow6432Node CLSID   gt     lt  else   gt     lt  define CLSIDRoots    CLSID   gt     lt  endif  gt     lt  -- ASCOM Driver Assembly with related COM registrations -- gt     lt Fragment gt       lt DirectoryRef Id  INSTALLLOCATION    gt     lt  Fragment gt     lt Fragment gt       lt ComponentGroup Id  cgAscomDriver  gt         lt Component Id  cmpAscomDriver  Directory  INSTALLLOCATION  Guid   0267031F-991D-4D88-A748-00EC6604171E   gt           lt File Id  filDriverAssembly  Source    var TiGra Astronomy AWRDriveSystem TargetPath   KeyPath  yes  Vital  yes  Assembly   net  AssemblyApplication  filDriverAssembly     gt           lt RegistryKey Root  HKCR  Key    var DriverId    Action  createAndRemoveOnUninstall  gt             lt RegistryValue Type  string  Value    var DriverTypeName    gt             lt RegistryKey Key  CLSID  gt               lt RegistryValue Type  string  Value    var DriverGuid     gt             lt  RegistryKey gt           lt  RegistryKey gt           lt  foreach CLSID in   var CLSIDRoots    gt           lt RegistryKey Root  HKCR  Key    var CLSID   Action  none  gt             lt RegistryKey Key    var DriverGuid   Action  createAndRemoveOnUninstall  gt               lt RegistryValue Type  string  Value    var DriverTypeName    gt               lt RegistryKey Key  InprocServer32  gt                 lt RegistryValue Type  string  Value  mscoree dll    gt                 lt RegistryValue Type  string  Name  ThreadingModel  Value  Both   gt                 lt RegistryValue Type  string  Name  Class  Value    var DriverTypeName    gt                 lt RegistryValue Type  string  Name  Assembly  Value    bind assemblyFullname filDriverAssembly     gt                 lt RegistryValue Type  string  Name  RuntimeVersion  Value  v2 0 50727   gt                 lt RegistryValue Type  string  Name  CodeBase  Value  file      filDriverAssembly     gt                 lt RegistryKey Key    bind fileVersion filDriverAssembly    gt                   lt RegistryValue Type  string  Name  Class  Value    var DriverTypeName    gt                   lt RegistryValue Type  string  Name  Assembly  Value    bind assemblyFullname filDriverAssembly     gt                   lt RegistryValue Type  string  Name  RuntimeVersion  Value  v2 0 50727   gt                   lt RegistryValue Type  string  Name  CodeBase  Value  file      filDriverAssembly     gt                 lt  RegistryKey gt               lt  RegistryKey gt               lt RegistryKey Key  ProgId  Action  createAndRemoveOnUninstall  gt                 lt RegistryValue Type  string  Value    var DriverId     gt               lt  RegistryKey gt               lt RegistryKey Key  Implemented Categories  Action  createAndRemoveOnUninstall   gt                 lt RegistryKey Key   62C8FE65-4EBB-45e7-B440-6E39B2CDBF29   Action  createAndRemoveOnUninstall    gt               lt  RegistryKey gt             lt  RegistryKey gt           lt  RegistryKey gt           lt  endforeach  gt         lt  Component gt       lt  ComponentGroup gt     lt  Fragment gt   lt  Wix gt    If you were wondering  this is actually for an ASCOM Telescope Driver   First  I took advice from above and created some platforma variables in a seperate file  you can see those scattered through the XML   The if-then-else part near the top deals with x86 vs x64 compatibility  My assembly targets  Any CPU  so on an x64 system  I need to register it twice  once in the 64-bit registry and once in the 32-bit Wow6432Node areas  The if-then-else sets me up for this  the values are used in a foreach loop later on  This way  I only have to author the registry keys once  DRY principle    The file element specifies the actual assembly dll being installed and registered    lt File Id  filDriverAssembly  Source    var TiGra Astronomy AWRDriveSystem TargetPath   KeyPath  yes  Vital  yes  Assembly   net  AssemblyApplication  filDriverAssembly     gt    Nothing revolutionary  but notice the Assembly   net  - this attribute alone would cause the assembly to be put into the GAC  which is NOT what I wanted  Using the AssemblyApplication attribute to point back to itself is simply a way of stopping Wix putting the file into the GAC  Now that Wix knows it s a  net assembly  though  it lets me use certain binder variables within my XML  such as the   bind assemblyFullname filDriverAssembly  to get the assembly full name

User · Answer

Creating Live  Test  Training      versions using the same source files   In a nutshell  Create unique UpgradeCode for each installer and automagically define the first character of each Guid for each installer  leaving the remaining 31 unique   Prerequisites   MSBuild Community Tasks   Assumptions   WiX variables are used to define UpgradeCode  ProductName  InstallName  You already have a working installer  I wouldn t attempt this until you do  All your Components are kept in one file  Components wxs   This process will work if you have multiple files  there will just be more work to do    Directory Structure   Setup Library   All wxs files  Components  Features  UI Dialogs        Common Config wxi  ProductCode      ProductVersion  PlatformProgramFilesFolder        Setup Live  wixproj    Link all Setup Library files using  Add Existing File  -   Add As Link   the little down arrow button right next to the Add button in Visual Studio  Config wxi  has unique UpgradeCode  ProductName  InstallName        Setup Test        as per live but Config wxi is configured for Test environment     Process   Create Setup Library directory and move all your wxs and wxi files  except Config wxi  from existing project  Create Setup Live  Setup Test  etc as per normal wixproj  Add BeforeBuild target in wixproj in Setup Live  etc to perform MSBuild Community Task FileUpdate to modify Guids  I used A for Live  B for Test and C for training  Add AfterBuild target to revert Components wxs Guids back to 0  Verify with Orca that each component in each MSI has the modified guid  Verify that original guids are restored   Verify that each MSI is installing  and upgrading  correct product and location    Example Config wxi   lt  xml version  1 0  encoding  utf-8   gt   lt Include gt   lt  -- Upgrade code should not change unless you want to install       a new product and have the old product remain installed        that is  both products existing as separate instances  -- gt   lt  define UpgradeCode    YOUR-GUID-HERE    gt    lt  -- Platform specific variables -- gt   lt  if   var Platform    x64   gt     lt  -- Product name as you want it to appear in Add Remove Programs-- gt     lt  define ProductName    Foo 64 Bit  Live     gt   lt  else   gt     lt  define ProductName     Foo  Live     gt   lt  endif   gt    lt  -- Directory name used as default installation location -- gt   lt  define InstallName    Foo  Live     gt    lt  -- Registry key name used to store installation location -- gt   lt  define InstallNameKey    FooLive    gt    lt  define VDirName    FooLive    gt   lt  define AppPoolName    FooLiveAppPool    gt   lt  define DbName    BlahBlahLive    gt   lt  Include gt    Example Config Common wxi   lt  xml version  1 0  encoding  utf-8   gt   lt Include gt   lt  -- Auto-generate ProductCode for each build  release and upgrade -- gt   lt  define ProductCode         gt    lt  -- Note that 4th version  Revision  is ignored by Windows Installer -- gt   lt  define ProductVersion    1 0 0 0    gt    lt  -- Minimum version supported if product already installed and this is an upgrade -- gt   lt  -- Note that 4th version  Revision  is ignored by Windows Installer -- gt   lt  define MinimumUpgradeVersion    0 0 0 0    gt    lt  -- Platform specific variables -- gt   lt  if   var Platform    x64   gt      lt  define Win64    yes    gt      lt  define PlatformProgramFilesFolder    ProgramFiles64Folder    gt   lt  else   gt      lt  define Win64    no    gt      lt  define PlatformProgramFilesFolder    ProgramFilesFolder    gt   lt  endif   gt    lt  define ProductManufacturer    Foo Technologies   gt    lt  -- Decimal Language ID  LCID  for the Product  Used for localization  -- gt   lt  define ProductLanguage    1033    gt    lt  define WebSiteName    DefaultWebSite    gt   lt  define WebSitePort    80    gt    lt  define DbServer     local     gt   lt  Include gt    Example Components wxs   lt  xml version  1 0  encoding  utf-8   gt   lt Wix xmlns  http   schemas microsoft com wix 2006 wi  gt     lt  -- The pre-processor variable which allows the magic to happen    -- gt     lt  include   sys CURRENTDIR  Config wxi  gt     lt  include    Setup Library Config Common wxi  gt     lt Fragment Id  ComponentsFragment  gt       lt Directory Id  TARGETDIR  Name  SourceDir  gt         lt Directory Id    var PlatformProgramFilesFolder   gt           lt Directory Id  INSTALLLOCATION  Name    var InstallName   gt             lt Component Id  ProductComponent  Guid  0XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  KeyPath  yes  gt                  Note  I would now suggest leaving the Guid attribute out of Component  equivalent of     using one file per component and setting the file as the keypath  This removes the need for calling ModifyComponentsGuids and RevertComponentsGuids targets shown below  This might not be possible for all your components though   Example Setup Live wixproj   lt Import Project    MSBuildExtensionsPath  MSBuildCommunityTasks MSBuild Community Tasks Targets    gt   lt Target Name  BeforeBuild  gt     lt CallTarget Targets  ModifyComponentsGuids    gt   lt  Target gt   lt Target Name  AfterBuild  gt     lt CallTarget Targets  RevertComponentsGuids    gt   lt  Target gt   lt  -- Modify the first character of every Guid to create unique value for Live  Test and Training builds -- gt   lt Target Name  ModifyComponentsGuids  gt     lt FileUpdate Files     Setup Library Components wxs  Regex  Guid  amp quot   a-f   A-F   d   ReplacementText  Guid  amp quot A    gt   lt  Target gt   lt  -- Revert the first character of every Guid back to initial value -- gt   lt Target Name  RevertComponentsGuids  gt     lt FileUpdate Files     Setup Library Components wxs  Regex  Guid  amp quot   a-f   A-F   d   ReplacementText  Guid  amp quot 0    gt   lt  Target gt    Final thoughts   This process should also work for creating different installers for different merge modules  Live  Test      as features  for the same installer  I went with different installers as it seemed a safer option  there is more risk that someone might upgrade Live instead of Training if they re on the same box and you just use features for the different merge modules  If you use your MSI to perform upgrades as well as new installs i e  the major upgrade only approach  and you save your installation location in the registry  remember to create a variable for the key name for each install  We also create variables in each Config wxi to enable unique virtual directory names  application pools  database names  et cetera for each installer    UPDATE 1  Auto-generating component Guids removes the need for calling FileUpdate task if you create component with Guid     for each file  setting the file as the keypath   UPDATE 2  One of the issues we ve come up against is if you don t auto-generate your component Guid s and the build fails  then the temp files need to be manually deleted   UPDATE 3  Found a way to remove reliance on svn externals and temporary file creation  This makes the build process more resilient  and is best option if you can t wildcard your Guids  and less brittle if there is a build failure in light or candle   UPDATE 4  Support for Multiple Instances using instance transforms is in WiX 3 0   definitely also worth a look

User · Answer

Here s a way to help large web projects verify that the number of deployed files matches the number of files built into an MSI  or merge module   I ve just run the custom MSBuild task against our main application  still in development  and it picked up quite a few missing files  mostly images  but a few javascript files had slipped through to     This approach  peeking into File table of MSI by hooking into AfterBuild target of WiX project  could work for other application types where you have access to a complete list of expected files

User · Answer

Set the DISABLEADVTSHORTCUTS property to force all advertised shortcuts in your installer to become regular shortcuts  and you don t need to include a dummy reg key to be used as the keypath    lt Property Id  DISABLEADVTSHORTCUTS  Value  1   gt    I think Windows Installer 4 0 or higher is a requirement

User · Answer

Set the DISABLEADVTSHORTCUTS property to force all advertised shortcuts in your installer to become regular shortcuts  and you don t need to include a dummy reg key to be used as the keypath    lt Property Id  DISABLEADVTSHORTCUTS  Value  1   gt    I think Windows Installer 4 0 or higher is a requirement

User · Answer

Setting the IIS enable32BitAppOnWin64 flag http   trycatchfail com blog post WiX-Snippet-change-enable32BitAppOnWin64 aspx   lt InstallExecuteSequence gt      lt RemoveExistingProducts After  InstallFinalize    gt      lt Custom Action  ConfigureAppPool  After  InstallFinalize   gt        lt   CDATA NOT Installed AND VersionNT64  gt   600   gt               lt  Custom gt   lt  InstallExecuteSequence gt    lt CustomAction Id  ConfigureAppPool  Return  check  Directory  TARGETDIR  ExeCommand   SystemFolder inetsrv appcmd set apppool  apppool name  APPPOOLNAME   enable32BitAppOnWin64 false    gt

User · Answer

Create a UI that has a custom action that will set a variable and the UI will disable enable the next button  or similar  based upon the variable set in the custom action   Not as straight-forward as you would think  not too difficult just not documented anywhere   Wix Interactions with Conditions  Properties  amp  Custom Actions

User · Answer

Editing Dialogs  One good ability to edit dialogs is using SharpDevelop in a version 4 0 1 7090  or higher   With help of this tool a standalone dialog  wxs files from WiX sources like e g  InstallDirDlg wxs  can be opened  previewed and edited in Design view

User · Answer

Put Components which may be patched individually inside their own Fragments  It goes for both making product installers and patches that if you include any component in a fragment  you must include all of the components in that fragment  In the case of building an installer  if you miss any component references  you ll get a linking error from light exe  However  when you make a patch  if you include a single component reference in a fragment  then all changed components from that fragment will show up in your patch   like this    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent1  Guid   C28843DA-EF08-41CC-BA75-D2B99D8A1983   DiskId  1  gt               lt File Id  SampleFile1  Source      var Version f Sample1 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent2  Guid   6CEA5599-E7B0-4D65-93AA-0F2F64402B22   DiskId  1  gt              lt File Id  SampleFile2  Source      var Version f Sample2 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent3  Guid   4030BAC9-FAB3-426B-8D1E-DC1E2F72C2FC   DiskId  1  gt              lt File Id  SampleFile3  Source      var Version f Sample3 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    instead of this    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent1  Guid   C28843DA-EF08-41CC-BA75-D2B99D8A1983   DiskId  1  gt               lt File Id  SampleFile1  Source      var Version  Sample1 txt    gt           lt  Component gt            lt Component Id  SampleComponent2  Guid   6CEA5599-E7B0-4D65-93AA-0F2F64402B22   DiskId  1  gt              lt File Id  SampleFile2  Source      var Version  Sample2 txt    gt           lt  Component gt            lt Component Id  SampleComponent3  Guid   4030BAC9-FAB3-426B-8D1E-DC1E2F72C2FC   DiskId  1  gt              lt File Id  SampleFile3  Source      var Version  Sample3 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    Also  when patching using the  Using Purely WiX  topic from the WiX chm help file  using this procedure to generate the patch   torch exe -p -xi 1 0 product wixpdb 1 1 product wixpdb -out patch diff wixmst candle exe patch wxs light exe patch wixobj -out patch patch wixmsp pyro exe patch patch wixmsp -out patch patch msp -t RTM patch diff wixmst   it s not enough to just have the 1 1 version of the product wixpdb built using the components in separate fragments  So be sure to correctly fragment your product before shipping

User · Answer

Use Javascript CustomActions because they re soooo easy  People have said that Javascript is the wrong thing to use for MSI CustomActions   Reasons given   hard to debug  hard to make it reliable   I don t agree   It s not hard to debug  certainly no harder than C     Its just different   I found writing CustomActions in Javascript to be super easy  much easier than using C     Much faster   And just as reliable    There s just one drawback  Javascript CustomActions  can be extracted via Orca  whereas a C C   CA would require reverse-engineering   If you consider your installer magic to be protected intellectual property  you will want to avoid script    If you use script   you just need to start with some structure   Here s some to get you started     Javascript  boilerplate  code for CustomAction          CustomActions js         Template for WIX Custom Actions written in Javascript             Mon  23 Nov 2009  10 54                                                                                 http   msdn microsoft com en-us library sfw6660x VS 85  aspx var Buttons             OkOnly             0          OkCancel           1          AbortRetryIgnore   2          YesNoCancel        3     var Icons             Critical           16          Question           32          Exclamation        48          Information        64     var MsgKind             Error              0x01000000          Warning            0x02000000          User               0x03000000          Log                0x04000000        http   msdn microsoft com en-us library aa371254 VS 85  aspx var MsiActionStatus             None               0          Ok                 1     success         Cancel             2          Abort              3          Retry              4     aka suspend          Ignore             5     skip remaining actions  this is not an error       function MyCustomActionInJavascript CA         try           LogMessage  Hello from MyCustomActionInJavascript                  do work here            LogMessage  Goodbye from MyCustomActionInJavascript              catch  exc1            Session Property  CA EXCEPTION     exc1 message           LogException exc1           return MsiActionStatus Abort            return MsiActionStatus Ok        Pop a message box   also spool a message into the MSI log  if it is enabled   function LogException exc        var record   Session Installer CreateRecord 0       record StringData 0     CustomAction  Exception  0x    decimalToHexString exc number            exc message      Session Message MsgKind Error   Icons Critical   Buttons btnOkOnly  record          spool an informational message into the MSI log  if it is enabled   function LogMessage msg        var record   Session Installer CreateRecord 0       record StringData 0     CustomAction       msg      Session Message MsgKind Log  record          http   msdn microsoft com en-us library d5fk67ky VS 85  aspx var WindowStyle         Hidden   0      Minimized   1      Maximized   2        http   msdn microsoft com en-us library 314cz14s v VS 85  aspx var OpenMode         ForReading   1      ForWriting   2      ForAppending   8        http   msdn microsoft com en-us library a72y2t1c v VS 85  aspx var SpecialFolders         WindowsFolder   0       SystemFolder    1       TemporaryFolder   2        Run a command via cmd exe from within the MSI function RunCmd command        var wshell   new ActiveXObject  WScript Shell        var fso   new ActiveXObject  Scripting FileSystemObject        var tmpdir   fso GetSpecialFolder SpecialFolders TemporaryFolder       var tmpFileName   fso BuildPath tmpdir  fso GetTempName          LogMessage  shell Run   command               use cmd exe to redirect the output     var rc   wshell Run   comspec   c     command     gt      tmpFileName  WindowStyle Hidden  true       LogMessage  shell Run rc        rc           here  optionally parse the output of the command      if  parseOutput            var textStream   fso OpenTextFile tmpFileName  OpenMode ForReading           while   textStream AtEndOfStream                var oneLine   textStream ReadLine                var line   ParseOneLine oneLine                                         textStream Close               if  deleteOutput            fso DeleteFile tmpFileName              return           rc   rc          outputfile    deleteOutput    null   tmpFileName              Then  register the custom action with something like this     lt Fragment gt     lt Binary Id  IisScript CA  SourceFile  CustomActions js    gt      lt CustomAction Id  CA MyCustomAction                BinaryKey  IisScript CA                JScriptCall  MyCustomActionInJavascript CA                Execute  immediate                Return  check    gt   lt  Fragmemt gt      You can  of course  insert as many Javascript functions as you like  for multiple custom actions   One example  I used Javascript to do a WMI query on IIS  to get a list of existing websites  to which an ISAPI filter could be installed   This list was then used to populate a listbox shown later in the UI sequence   All very easy    On IIS7  there is no WMI provider for IIS  so I used the shell Run   approach to invoke appcmd exe to perform the work   Easy   Related question  About Javascript CustomActions

User · Answer

Installing to C  ProductName  Some applications need to be installed to C  ProductName or something similar  but 99 9   if not 100   of the examples in the net install to C  Program Files CompanyName ProductName   The following code can be used to set the TARGETDIR property to the root of the C  drive  taken from the WiX-users list     lt CustomAction Id  AssignTargetDir  Property  TARGETDIR  Value  C    Execute  firstSequence    gt   lt InstallUISequence gt       lt Custom Action  AssignTargetDir  Before  CostInitialize  gt TARGETDIR    lt  Custom gt   lt  InstallUISequence gt   lt InstallExecuteSequence gt       lt Custom Action  AssignTargetDir  Before  CostInitialize  gt TARGETDIR    lt  Custom gt   lt  InstallExecuteSequence gt    NOTE  By default  TARGETDIR does not point to C    It rather points to ROOTDRIVE which in turn points to the root of the drive with the most free space  see here  - and this is not necessarily the C  drive  There might be another hard drive  partition  or USB drive   Then  somewhere below your  lt Product     gt  tag  you need the following directory tags as usual    lt Directory Id  TARGETDIR  Name  SourceDir  gt       lt Directory Id  APPLICATIONFOLDER  Name    var ProductName   gt           lt  -- your content goes here    -- gt       lt  Directory gt   lt  Directory gt

User · Answer

We display the product version somewhere  tiny  in the first screen of the GUI  Because people tend to make mistakes in picking the right version every time   And keep us developers searching for ages    We ve set up TFSBuild to also generate transforms   mst files  with the configuration for our different environments   We know about all environments we need to deploy to      Since the original weblog post by Grant Holliday is down  I copy pasted its contents here     MSBuild task to generate MSI Transform files from XMLMarch 11 2008  In my previous post I described how you can use MSI Transform    mst  files to separate environment-specific configuration settings from a generic MSI package   Although this provides a level of flexibility in your configuration  there are two down-sides of Transform files    They   re a binary format You can   t    edit    or    view    a transform file  You have to apply it or re-create it to see what changes it includes    Fortunately we can use the Microsoft Windows Installer Object Library  c windowssystem32msi dll  to open MSI    databases    and create transform files   Credits go again to Alex Shevchuk     From MSI to WiX     Part 7     Customising installation using Transforms for showing us how to achieve this with VbScript  Essentially all I   ve done is taken Alex   s example and using Interop WindowsInstaller dll I   ve implemented an MSBuild task  The  MSBuild Task  Download the source code  amp  example transforms xml here   7Kb Zipped VS2008 Solution

User · Answer

Peter Tate has already shown how you can define reusable ComponentGroup definitions in separate wix fragments  Some additional tricks related to this   Directory Aliasing  The component group fragments don t need to know about directories defined by the main product wxs  In your component group fragment you can talk about a folder like this    lt DirectoryRef Id  component1InstallFolder  gt       lt  DirectoryRef gt    Then the main product can alias one of its directories  e g   productInstallFolder   like this    lt Directory Id  productInstallFolder  Name  ProductName  gt      lt  -- not subfolders  because no Name attribute  but aliases for parent  -- gt      lt Directory Id  component1InstallFolder   gt       lt Directory Id  component2InstallFolder   gt    lt  Directory gt    Dependency Graph  ComponentGroup elements can contain ComponentGroupRef child elements  This is great if you have a big pool of reusable components with a complex dependency graph between them  You just set up a ComponentGroup in its own fragment for each component and declare the dependencies like this     lt ComponentGroup Id  B  gt      lt ComponentRef Id   B    gt      lt ComponentGroupRef Id  A  gt   lt  ComponentGroup gt    If you now reference component group  B  in your setup because it is a direct dependency of your application  it will automatically pull in component group  A  even if the application author never realized that it was a dependency of  B   It  just works  as long as you don t have any circular dependencies   Reusable wixlib  The above dependency graph idea works best if you compile the big-pool-o-reusable-components into a reusable wixlib with lit exe  When creating an application setup  you can reference this wixlib much like a wixobj file  The candle exe linker will automatically eliminate any fragments that are not  pulled in  by the main product wxs file s

User · Answer

I m surprised no one has mentioned using T4 to generate the WXS file during build  I learned about this by way of Henry Lee   New Age Solutions   Essentially  you create a custom MSBuild task to execute a T4 template  and that template outputs the WXS just before the Wix project is compiled  This allows you to  depending on how you implement it  automatically include all assemblies output from compiling another solution  meaning that you no longer have to edit the wxs ever time you add a new assembly

User · Answer

Including COM Objects   heat generates all most  if not all  the registry entries and other configuration needed for them   Rejoice   Including Managed COM Objects  aka   NET or C  COM objects   Using heat on a managed COM object will give you an almost complete wix document     If you don t need the library available in the GAC  ie  globally available  MOST of the time you do not need this with your  NET assemblies anyway - you ve probably done something wrong at this point if it s not intended to be a shared library  you will want to make sure to update the CodeBase registry key to be set to   ComponentName    If you ARE planning on installing it to the GAC  eg  you ve made some new awesome common library that everyone will want to use  you must remove this entry  and add two new attributes to the File element  Assembly and KeyPath   Assembly should be set to   net  and KeyPath should be set to  yes    However  some environments  especially anything with managed memory such as scripting languages  will need access to the Typelib as well   Make sure to run heat on your typelib and include it   heat will generate all the needed registry keys   How cool is that

User · Answer

Printing EULA from Wix3 0 and later  1  When you compile your wix source code  the light exe must reference the WixUIExtension dll in command line  Use the command line switch -ext  for this   2  If when you add the reference to the WixUIExtension dll  your project fails to compile  this is most likely because of clashes of Dialog IDs  i e  your project was using the same IDs of dialogs as some standard dialogs in WixUIExtension dll  give different IDs to your dialogs  This is quite common problem   3  Your license dialog must have ScrollableText control with the id  LicenseText   Wix searches for exactly this name of control when it prints    lt Control Id  LicenseText  Type  ScrollableText  X  20  Y  60  Width  330  Height  160  Sunken  yes  TabSkip  no  gt       lt Text SourceFile  License rtf    gt   lt  Control gt    and a PushButton which refers to the custom action   lt Control Type  PushButton  Id  PrintButton  Width  57  Height  17  X  19  Y  244  Text  Print  gt       lt Publish Event  DoAction  Value  PrintEula  gt 1 lt  Publish gt   lt  Control gt    4  Define CustomAction with the Id  PrintEula  like this    lt CustomAction Id  PrintEula  BinaryKey  WixUIWixca  DllEntry  PrintEula  Return  ignore  Execute  immediate    gt    Note  BinaryKey is different in Wix3 0 comparing to Wix2 0 and must be exactly  WixUIWixca   case sensitive    When user presses the button he she will be presented with the standard Select Printer Dialog and will be able to print from there

User · Answer

Modify the  Ready to install   dialog  aka VerifyReadyDlg  to provide a summary of choices made   It looks like this  alt text http   i46 tinypic com s4th7t jpg  Do this with a Javascript CustomAction      Javascript code      http   msdn microsoft com en-us library aa372516 VS 85  aspx var MsiViewModify                  Refresh            0          Insert             1          Update             2          Assign             3          Replace            4          Merge              5          Delete             6          InsertTemporary    7       cannot permanently modify the MSI during install         Validate           8          ValidateNew        9          ValidateField      10          ValidateDelete     11             http   msdn microsoft com en-us library sfw6660x VS 85  aspx var Buttons                  OkOnly             0          OkCancel           1          AbortRetryIgnore   2          YesNoCancel        3         var Icons                 Critical           16          Question           32          Exclamation        48          Information        64        var MsgKind                 Error              0x01000000          Warning            0x02000000          User               0x03000000          Log                0x04000000            http   msdn microsoft com en-us library aa371254 VS 85  aspx var MsiActionStatus                  None               0          Ok                 1     success         Cancel             2          Abort              3          Retry              4     aka suspend          Ignore             5     skip remaining actions  this is not an error          function UpdateReadyDialog CA sitename        try                   can retrieve properties from the install session like this          var selectedWebSiteId   Session Property  MSI PROPERTY HERE                can retrieve requested feature install state like this          var fInstallRequested     Session FeatureRequestState  F FeatureName             var text1    This is line 1 of text in the VerifyReadyDlg            var text2    This is the second line of custom text            var controlView       Session Database OpenView  SELECT   FROM Control            controlView Execute             var rec               Session Installer CreateRecord 12           rec StringData 1       VerifyReadyDlg         Dialog          rec StringData 2       CustomVerifyText1      Control - can be any name         rec StringData 3       Text                   Type         rec IntegerData 4     25                      X         rec IntegerData 5     60                      Y         rec IntegerData 6     320                     Width         rec IntegerData 7     85                      Height         rec IntegerData 8     2                       Attributes         rec StringData 9                              Property         rec StringData 10     vText1                  Text         rec StringData 11                             Control Next         rec StringData 12                             Help         controlView Modify MsiViewModify InsertTemporary  rec            rec                   Session Installer CreateRecord 12           rec StringData 1       VerifyReadyDlg         Dialog          rec StringData 2       CustomVerifyText2      Control - any unique name         rec StringData 3       Text                   Type         rec IntegerData 4     25                      X         rec IntegerData 5     160                     Y         rec IntegerData 6     320                     Width         rec IntegerData 7     65                      Height         rec IntegerData 8     2                       Attributes         rec StringData 9                              Property         rec StringData 10     text2                   Text         rec StringData 11                             Control Next         rec StringData 12                             Help         controlView Modify MsiViewModify InsertTemporary  rec            controlView Close              catch  exc1                Session Property  CA EXCEPTION     exc1 message           LogException  UpdatePropsWithSelectedWebSite   exc1           return MsiActionStatus Abort            return MsiActionStatus Ok      function LogException loc  exc        var record   Session Installer CreateRecord 0       record StringData 0     Exception      loc           exc number           exc message      Session Message MsgKind Error   Icons Critical   Buttons btnOkOnly  record         Declare the Javascript CA     lt Fragment gt     lt Binary Id  IisScript CA  SourceFile  CustomActions js    gt      lt CustomAction Id  CA UpdateReadyDialog                BinaryKey  IisScript CA                JScriptCall  UpdateReadyDialog CA                Execute  immediate                Return  check    gt   lt  Fragment gt      Attach the CA to a button   In this example  the CA is fired when Next is clicked from the CustomizeDlg    lt UI     gt     lt Publish Dialog  CustomizeDlg  Control  Next  Event  DoAction              Value  CA UpdateReadyDialog  Order  1   gt   lt  UI gt      Related SO Question  How can I set  at runtime  the text to be displayed in VerifyReadyDlg

User · Answer

Fix the ProgressDlg so that it displays properly   I ve increased the font size for my installer from 8 to 10  to make the font a more human  usable scale on high-res monitors  I do this with this XML magic     lt UI Id  MyCustomUI  gt     lt TextStyle Id  WixUI Font Normal  FaceName  Tahoma  Size  10    gt     lt TextStyle Id  WixUI Font Big     FaceName  Tahoma  Size  12    gt     lt TextStyle Id  WixUI Font Bigger  FaceName  Tahoma  Size  14    gt     lt TextStyle Id  WixUI Font Title   FaceName  Tahoma  Size  12  Bold  yes    gt      lt Property Id  DefaultUIFont  Value  WixUI Font Normal    gt   lt  UI gt    But this means the ProgressDlg doesn t display properly any longer   This is the one that displays the progress of the install  right at the very end   The ActionText gets clipped  so descenders on letters like g and j do not display   Fix this by adjusting the size and position of the various controls on the Progressdialog  in a post-processing Javascript  Run this script after generating the MSI     var msiOpenDatabaseModeTransact   1  var filespec   WScript Arguments 0   var installer   new ActiveXObject  WindowsInstaller Installer    var database   installer OpenDatabase filespec  msiOpenDatabaseModeTransact       The text on the exit dialog is too close to the title   This     step moves the text down from Y 70 to Y 90  about one line   sql    UPDATE  Control  SET  Control   Y     90           WHERE  Control   Dialog    ExitDialog  AND  Control   Control   Description    view   database OpenView sql   view Execute    view Close        The progressbar is too close to the status text on the Progress dialog      This step moves the progressbar down from Y 115 to Y 118  about 1 3 line   sql    UPDATE  Control  SET  Control   Y     118           WHERE  Control   Dialog    ProgressDlg  AND  Control   Control   ProgressBar    view   database OpenView sql   view Execute    view Close        The StatusLabel and ActionText controls are too short on the Progress dialog     which means the bottom of the text is cut off   This step    increases the height from 10 to 16  sql    UPDATE  Control  SET  Control   Height     16           WHERE  Control   Dialog    ProgressDlg  AND  Control   Control   StatusLabel    view   database OpenView sql   view Execute    view Close    sql    UPDATE  Control  SET  Control   Height     16           WHERE  Control   Dialog    ProgressDlg  AND  Control   Control   ActionText    view   database OpenView sql   view Execute    view Close     database Commit

User · Answer

Keep all IDs in separate namespaces   Features begin with F   Examples   F Documentation  F Binaries  F SampleCode   Components begin with C   Ex   C ChmFile  C ReleaseNotes  C LicenseFile  C IniFile  C Registry CustomActions are CA   Ex   CA LaunchHelp  CA UpdateReadyDlg  CA SetPropertyX Files are Fi    Directories are Di  and so on    I find this helps immensely in keeping track of all the various id s in all the various categories

User · Answer

We display the product version somewhere  tiny  in the first screen of the GUI  Because people tend to make mistakes in picking the right version every time   And keep us developers searching for ages    We ve set up TFSBuild to also generate transforms   mst files  with the configuration for our different environments   We know about all environments we need to deploy to      Since the original weblog post by Grant Holliday is down  I copy pasted its contents here     MSBuild task to generate MSI Transform files from XMLMarch 11 2008  In my previous post I described how you can use MSI Transform    mst  files to separate environment-specific configuration settings from a generic MSI package   Although this provides a level of flexibility in your configuration  there are two down-sides of Transform files    They   re a binary format You can   t    edit    or    view    a transform file  You have to apply it or re-create it to see what changes it includes    Fortunately we can use the Microsoft Windows Installer Object Library  c windowssystem32msi dll  to open MSI    databases    and create transform files   Credits go again to Alex Shevchuk     From MSI to WiX     Part 7     Customising installation using Transforms for showing us how to achieve this with VbScript  Essentially all I   ve done is taken Alex   s example and using Interop WindowsInstaller dll I   ve implemented an MSBuild task  The  MSBuild Task  Download the source code  amp  example transforms xml here   7Kb Zipped VS2008 Solution

User · Answer

Checking if IIS is installed    lt Property Id  IIS MAJOR VERSION  gt       lt RegistrySearch Id  CheckIISVersion  Root  HKLM  Key  SOFTWARE Microsoft InetStp  Name  MajorVersion  Type  raw    gt   lt  Property gt    lt Condition Message  IIS must be installed  gt      Installed OR IIS MAJOR VERSION  lt  Condition gt    Checking if IIS 6 Metabase Compatibility is installed on Vista     lt Property Id  IIS METABASE COMPAT  gt       lt RegistrySearch Id  CheckIISMetabase  Root  HKLM  Key  SOFTWARE Microsoft InetStp Components  Name  ADSICompatibility  Type  raw    gt   lt  Property gt    lt Condition Message  IIS 6 Metabase Compatibility feature must be installed  gt      Installed OR   VersionNT  amp lt  600  OR IIS METABASE COMPAT   lt  Condition gt

User · Answer

Environmental Variables  When compiling your Wxs documents to wixobj code  you can make use of environmental variables to determine various information   For example  lets say you want to change which files get included in a project   Lets say you have an environmental variable called RELEASE MODE  that you set right before you build your MSI  either with a script or manually  it doesn t matter   In your wix source  you can do something like    lt define FILESOURCE   c  source output bin   env RELEASE MODE   gt    and then later in your code  use it in place to on the fly change your wxs document  eg    lt Icon Id  myicon ico  SourceFile    var FILESOURCE     gt

User · Answer

Fantastic question   I d love to see some best practices shown   I ve got a lot of files that I distribute  so I ve set up my project into several wxs source files   I have a top level source file which I call Product wxs which basically contains the structure for the installation  but not the actual components   This file has several sections    lt Product     gt     lt Package     gt       lt Media gt          lt Condition gt s         lt Upgrade    gt      lt Directory gt                   lt  Directory gt      lt Feature gt         lt ComponentGroupRef      gt  A bunch of these that     lt  Feature gt      lt UI     gt      lt Property    gt      lt Custom Actions    gt      lt Install Sequences        lt  Package gt   lt  Product gt    The rest of the  wix files are composed of Fragments that contain ComponentGroups which are referenced in the Feature tag in the Product wxs   My project contains a nice logical grouping of the files that I distribute   lt Fragment gt      lt ComponentGroup gt        lt ComponentRef gt                 lt  ComponentGroup gt       lt DirectoryRef gt         lt Component    for each file                  lt  DirectoryRef gt   lt  Fragment gt    This isn t perfect  my OO spider sense tingles a bit because the fragments have to reference names in the Product wxs file  e g  the DirectoryRef  but I find it easier to maintain that a single large source file   I d love to hear comments on this  or if anyone has any good tips too

User · Answer

Performing a forced reinstall when an install doesn t allow uninstall or reinstall and doesn t roll back    VBscript script used for overriding an install that isn t uninstalling for whatever reason    Dim objShell set objShell   wscript createObject  wscript shell    iReturn   objShell Run  CMD  K MsiExec exe  I   C  Users TheUser Documents Visual Studio 2010 Projects InstallationTarget HelloInstaller bin Debug HelloInstaller msi   REINSTALLMODE vomus REINSTALL ALL   True

User · Answer

I m surprised no one has mentioned using T4 to generate the WXS file during build  I learned about this by way of Henry Lee   New Age Solutions   Essentially  you create a custom MSBuild task to execute a T4 template  and that template outputs the WXS just before the Wix project is compiled  This allows you to  depending on how you implement it  automatically include all assemblies output from compiling another solution  meaning that you no longer have to edit the wxs ever time you add a new assembly

User · Answer

Checking if IIS is installed    lt Property Id  IIS MAJOR VERSION  gt       lt RegistrySearch Id  CheckIISVersion  Root  HKLM  Key  SOFTWARE Microsoft InetStp  Name  MajorVersion  Type  raw    gt   lt  Property gt    lt Condition Message  IIS must be installed  gt      Installed OR IIS MAJOR VERSION  lt  Condition gt    Checking if IIS 6 Metabase Compatibility is installed on Vista     lt Property Id  IIS METABASE COMPAT  gt       lt RegistrySearch Id  CheckIISMetabase  Root  HKLM  Key  SOFTWARE Microsoft InetStp Components  Name  ADSICompatibility  Type  raw    gt   lt  Property gt    lt Condition Message  IIS 6 Metabase Compatibility feature must be installed  gt      Installed OR   VersionNT  amp lt  600  OR IIS METABASE COMPAT   lt  Condition gt

User · Answer

Modify the  Ready to install   dialog  aka VerifyReadyDlg  to provide a summary of choices made   It looks like this  alt text http   i46 tinypic com s4th7t jpg  Do this with a Javascript CustomAction      Javascript code      http   msdn microsoft com en-us library aa372516 VS 85  aspx var MsiViewModify                  Refresh            0          Insert             1          Update             2          Assign             3          Replace            4          Merge              5          Delete             6          InsertTemporary    7       cannot permanently modify the MSI during install         Validate           8          ValidateNew        9          ValidateField      10          ValidateDelete     11             http   msdn microsoft com en-us library sfw6660x VS 85  aspx var Buttons                  OkOnly             0          OkCancel           1          AbortRetryIgnore   2          YesNoCancel        3         var Icons                 Critical           16          Question           32          Exclamation        48          Information        64        var MsgKind                 Error              0x01000000          Warning            0x02000000          User               0x03000000          Log                0x04000000            http   msdn microsoft com en-us library aa371254 VS 85  aspx var MsiActionStatus                  None               0          Ok                 1     success         Cancel             2          Abort              3          Retry              4     aka suspend          Ignore             5     skip remaining actions  this is not an error          function UpdateReadyDialog CA sitename        try                   can retrieve properties from the install session like this          var selectedWebSiteId   Session Property  MSI PROPERTY HERE                can retrieve requested feature install state like this          var fInstallRequested     Session FeatureRequestState  F FeatureName             var text1    This is line 1 of text in the VerifyReadyDlg            var text2    This is the second line of custom text            var controlView       Session Database OpenView  SELECT   FROM Control            controlView Execute             var rec               Session Installer CreateRecord 12           rec StringData 1       VerifyReadyDlg         Dialog          rec StringData 2       CustomVerifyText1      Control - can be any name         rec StringData 3       Text                   Type         rec IntegerData 4     25                      X         rec IntegerData 5     60                      Y         rec IntegerData 6     320                     Width         rec IntegerData 7     85                      Height         rec IntegerData 8     2                       Attributes         rec StringData 9                              Property         rec StringData 10     vText1                  Text         rec StringData 11                             Control Next         rec StringData 12                             Help         controlView Modify MsiViewModify InsertTemporary  rec            rec                   Session Installer CreateRecord 12           rec StringData 1       VerifyReadyDlg         Dialog          rec StringData 2       CustomVerifyText2      Control - any unique name         rec StringData 3       Text                   Type         rec IntegerData 4     25                      X         rec IntegerData 5     160                     Y         rec IntegerData 6     320                     Width         rec IntegerData 7     65                      Height         rec IntegerData 8     2                       Attributes         rec StringData 9                              Property         rec StringData 10     text2                   Text         rec StringData 11                             Control Next         rec StringData 12                             Help         controlView Modify MsiViewModify InsertTemporary  rec            controlView Close              catch  exc1                Session Property  CA EXCEPTION     exc1 message           LogException  UpdatePropsWithSelectedWebSite   exc1           return MsiActionStatus Abort            return MsiActionStatus Ok      function LogException loc  exc        var record   Session Installer CreateRecord 0       record StringData 0     Exception      loc           exc number           exc message      Session Message MsgKind Error   Icons Critical   Buttons btnOkOnly  record         Declare the Javascript CA     lt Fragment gt     lt Binary Id  IisScript CA  SourceFile  CustomActions js    gt      lt CustomAction Id  CA UpdateReadyDialog                BinaryKey  IisScript CA                JScriptCall  UpdateReadyDialog CA                Execute  immediate                Return  check    gt   lt  Fragment gt      Attach the CA to a button   In this example  the CA is fired when Next is clicked from the CustomizeDlg    lt UI     gt     lt Publish Dialog  CustomizeDlg  Control  Next  Event  DoAction              Value  CA UpdateReadyDialog  Order  1   gt   lt  UI gt      Related SO Question  How can I set  at runtime  the text to be displayed in VerifyReadyDlg

User · Answer

Create a UI that has a custom action that will set a variable and the UI will disable enable the next button  or similar  based upon the variable set in the custom action   Not as straight-forward as you would think  not too difficult just not documented anywhere   Wix Interactions with Conditions  Properties  amp  Custom Actions

User · Answer

Keep variables in a separate wxi include file  Enables re-use  variables are faster to find and  if needed  allows for easier manipulation by an external tool  Define Platform variables for x86 and x64 builds   lt  -- Product name as you want it to appear in Add Remove Programs-- gt   lt  if   var Platform    x64   gt     lt  define ProductName    Product Name  64 bit     gt     lt  define Win64    yes    gt     lt  define PlatformProgramFilesFolder    ProgramFiles64Folder    gt   lt  else   gt     lt  define ProductName    Product Name    gt     lt  define Win64    no    gt     lt  define PlatformProgramFilesFolder    ProgramFilesFolder    gt   lt  endif   gt   Store the installation location in the registry  enabling upgrades to find the correct location  For example  if a user sets custom install directory      lt Property Id  INSTALLLOCATION  gt       lt RegistrySearch Id  RegistrySearch  Type  raw  Root  HKLM  Win64    var Win64                 Key  Software Company Product  Name  InstallLocation    gt    lt  Property gt    Note  WiX guru Rob Mensching has posted an excellent blog entry which goes into more detail and fixes an edge case when properties are set from the command line   Examples using 1  2  and 3    lt  include   sys CURRENTDIR  Config wxi  gt   lt Product      gt     lt Package InstallerVersion  200  InstallPrivileges  elevated             InstallScope  perMachine  Platform    var Platform              Compressed  yes  Description    var ProductName     gt    and   lt Directory Id  TARGETDIR  Name  SourceDir  gt     lt Directory Id    var PlatformProgramFilesFolder   gt       lt Directory Id  INSTALLLOCATION  Name    var InstallName   gt   The simplest approach is always do major upgrades  since it allows both new installs and upgrades in the single MSI  UpgradeCode is fixed to a unique Guid and will never change  unless we don t want to upgrade existing product   Note  In WiX 3 5 there is a new MajorUpgrade element which makes life even easier  Creating an icon in Add Remove Programs   lt Icon Id  Company ico  SourceFile     Tools Company Images Company ico    gt   lt Property Id  ARPPRODUCTICON  Value  Company ico    gt   lt Property Id  ARPHELPLINK  Value  http   www example com     gt   On release builds we version our installers  copying the msi file to a deployment directory  An example of this using a wixproj target called from AfterBuild target    lt Target Name  CopyToDeploy  Condition     Configuration       Release   gt     lt  -- Note we append AssemblyFileVersion  changing MSI file name only works with Major Upgrades -- gt     lt Copy SourceFiles    OutputPath   OutputName  msi           DestinationFiles     Deploy Setup   OutputName    AssemblyFileVersion    Platform  msi    gt   lt  Target gt   Use heat to harvest files with wildcard     Guid  Useful if you want to reuse WXS files across multiple projects  see my answer on multiple versions of the same product   For example  this batch file automatically harvests RoboHelp output    echo off   robocopy    WebHelp   TEMP  WebHelpTemp WebHelp   E  NP  PURGE  XD  svn     WIX bin heat  dir   TEMP  WebHelp  -nologo -sfrag -suid -ag -srd -dir WebHelp -out WebHelp wxs -cg WebHelpComponent -dr INSTALLLOCATION -var var WebDeploySourceDir    There s a bit going on  robocopy is stripping out Subversion working copy metadata before harvesting  the -dr root directory reference is set to our installation location rather than default TARGETDIR  -var is used to create a variable to specify the source directory  web deployment output   Easy way to include the product version in the welcome dialog title by using Strings wxl for localization   Credit  saschabeaumont  Added as this great tip is hidden in a comment    lt WixLocalization Culture  en-US  xmlns  http   schemas microsoft com wix 2006 localization  gt       lt String Id  WelcomeDlgTitle  gt   WixUI Font Bigger Welcome to the  ProductName   ProductVersion  Setup Wizard lt  String gt   lt  WixLocalization gt   Save yourself some pain and follow Wim Coehen s advice of one component per file  This also allows you to leave out  or wild-card    the component GUID  Rob Mensching has a neat way to quickly track down problems in MSI log files by searching for value 3  Note the comments regarding internationalization  When adding conditional features  it s more intuitive to set the default feature level to 0  disabled  and then set the condition level to your desired value  If you set the default feature level    1  the condition level has to be 0 to disable it  meaning the condition logic has to be the opposite to what you d expect  which can be confusing      lt Feature Id  NewInstallFeature  Level  0  Description  New installation feature  Absent  allow  gt     lt Condition Level  1  gt NOT UPGRADEFOUND lt  Condition gt   lt  Feature gt   lt Feature Id  UpgradeFeature  Level  0  Description  Upgrade feature  Absent  allow  gt     lt Condition Level  1  gt UPGRADEFOUND lt  Condition gt   lt  Feature gt

User · Answer

Using the Msi Diagnostic logging to get detailed failure Information  msiexec  i Package msi  l v c  Package log    Where Package msi is the name of your package  and c  Package log is where you want the output of the log  Msi Error Codes Wix Intro Video Oh and Random Wix intro video featuring  quot Mr  WiX quot  Rob Mensching is  quot conceptual big picture quot  helpful

User · Answer

Editing Dialogs  One good ability to edit dialogs is using SharpDevelop in a version 4 0 1 7090  or higher   With help of this tool a standalone dialog  wxs files from WiX sources like e g  InstallDirDlg wxs  can be opened  previewed and edited in Design view

User · Answer

Setting the IIS enable32BitAppOnWin64 flag http   trycatchfail com blog post WiX-Snippet-change-enable32BitAppOnWin64 aspx   lt InstallExecuteSequence gt      lt RemoveExistingProducts After  InstallFinalize    gt      lt Custom Action  ConfigureAppPool  After  InstallFinalize   gt        lt   CDATA NOT Installed AND VersionNT64  gt   600   gt               lt  Custom gt   lt  InstallExecuteSequence gt    lt CustomAction Id  ConfigureAppPool  Return  check  Directory  TARGETDIR  ExeCommand   SystemFolder inetsrv appcmd set apppool  apppool name  APPPOOLNAME   enable32BitAppOnWin64 false    gt

User · Answer

Performing a forced reinstall when an install doesn t allow uninstall or reinstall and doesn t roll back    VBscript script used for overriding an install that isn t uninstalling for whatever reason    Dim objShell set objShell   wscript createObject  wscript shell    iReturn   objShell Run  CMD  K MsiExec exe  I   C  Users TheUser Documents Visual Studio 2010 Projects InstallationTarget HelloInstaller bin Debug HelloInstaller msi   REINSTALLMODE vomus REINSTALL ALL   True

User · Answer

Fantastic question   I d love to see some best practices shown   I ve got a lot of files that I distribute  so I ve set up my project into several wxs source files   I have a top level source file which I call Product wxs which basically contains the structure for the installation  but not the actual components   This file has several sections    lt Product     gt     lt Package     gt       lt Media gt          lt Condition gt s         lt Upgrade    gt      lt Directory gt                   lt  Directory gt      lt Feature gt         lt ComponentGroupRef      gt  A bunch of these that     lt  Feature gt      lt UI     gt      lt Property    gt      lt Custom Actions    gt      lt Install Sequences        lt  Package gt   lt  Product gt    The rest of the  wix files are composed of Fragments that contain ComponentGroups which are referenced in the Feature tag in the Product wxs   My project contains a nice logical grouping of the files that I distribute   lt Fragment gt      lt ComponentGroup gt        lt ComponentRef gt                 lt  ComponentGroup gt       lt DirectoryRef gt         lt Component    for each file                  lt  DirectoryRef gt   lt  Fragment gt    This isn t perfect  my OO spider sense tingles a bit because the fragments have to reference names in the Product wxs file  e g  the DirectoryRef  but I find it easier to maintain that a single large source file   I d love to hear comments on this  or if anyone has any good tips too

User · Answer

Keep all IDs in separate namespaces   Features begin with F   Examples   F Documentation  F Binaries  F SampleCode   Components begin with C   Ex   C ChmFile  C ReleaseNotes  C LicenseFile  C IniFile  C Registry CustomActions are CA   Ex   CA LaunchHelp  CA UpdateReadyDlg  CA SetPropertyX Files are Fi    Directories are Di  and so on    I find this helps immensely in keeping track of all the various id s in all the various categories

User · Answer

Add a checkbox to the exit dialog to launch the app  or the helpfile           lt  -- CA to launch the exe after install -- gt   lt CustomAction Id            CA StartAppOnExit                FileKey       YourAppExeId                ExeCommand                    Execute       immediate                Impersonate   yes                Return        asyncNoWait    gt    lt  -- CA to launch the help file -- gt   lt CustomAction Id           CA LaunchHelp                Directory    INSTALLDIR                ExeCommand    WindowsFolder hh exe IirfGuide chm                Execute      immediate                Return       asyncNoWait    gt    lt Property Id  WIXUI EXITDIALOGOPTIONALCHECKBOXTEXT            Value  Launch MyApp when setup exits     gt    lt UI gt     lt Publish Dialog    ExitDialog             Control   Finish             Order     1             Event     DoAction             Value     CA StartAppOnExit  gt WIXUI EXITDIALOGOPTIONALCHECKBOXTEXT lt  Publish gt   lt  UI gt      If you do it this way  the  standard  appearance isn t quite right   The checkbox is always a gray background  while the dialog is white    alt text http   www dizzymonkeydesign com blog misc adding-and-customizing-dlgs-in-wix-3 images exit dlg 1 gif  One way around this is to specify your own custom ExitDialog  with a differently-located checkbox   This works  but seems like a lot of work just to change the color of one control   Another way to solve the same thing is to post-process the generated MSI to change the X Y fields in the Control table for that particular CheckBox control   The javascript code looks like this    var msiOpenDatabaseModeTransact   1  var filespec   WScript Arguments 0   var installer   new ActiveXObject  WindowsInstaller Installer    var database   installer OpenDatabase filespec  msiOpenDatabaseModeTransact   var sql    UPDATE  Control  SET  Control   Height     18    Control   Width     170                   Control   Y   243    Control   X   10                 WHERE  Control   Dialog    ExitDialog  AND                    Control   Control   OptionalCheckBox    var view   database OpenView sql   view Execute    view Close    database Commit        Running this code as a command-line script  using cscript exe  after the MSI is generated  from light exe  will produce an ExitDialog that looks more professional   alt text http   www dizzymonkeydesign com blog misc adding-and-customizing-dlgs-in-wix-3 images exit dlg 2 gif

User · Answer

Creating Custom Action for WIX written in managed code  C   without Votive  http   www codeproject com KB install wixcustomaction aspx

User · Answer

Instead of ORCA use InstEd which is a good tool for viewing MSI tables  Also it has the ability to diff two packages by  Transform -  Compare To     Additionally a Plus version with additional functionality is available  But also the free version offers a good alternative for Orca

User · Answer

It s a nice structure but based on my experience I wonder how you address these conditions   A  Your installs all appear to land in the same destination  If a user needs to install all 3 versions at once will your process allow this   Can they unambiguously tell which version of every executable they are triggering   B  How do you handle new files that exist in TEST and or TRAINING but not yet in LIVE

User · Answer

Keep variables in a separate wxi include file  Enables re-use  variables are faster to find and  if needed  allows for easier manipulation by an external tool  Define Platform variables for x86 and x64 builds   lt  -- Product name as you want it to appear in Add Remove Programs-- gt   lt  if   var Platform    x64   gt     lt  define ProductName    Product Name  64 bit     gt     lt  define Win64    yes    gt     lt  define PlatformProgramFilesFolder    ProgramFiles64Folder    gt   lt  else   gt     lt  define ProductName    Product Name    gt     lt  define Win64    no    gt     lt  define PlatformProgramFilesFolder    ProgramFilesFolder    gt   lt  endif   gt   Store the installation location in the registry  enabling upgrades to find the correct location  For example  if a user sets custom install directory      lt Property Id  INSTALLLOCATION  gt       lt RegistrySearch Id  RegistrySearch  Type  raw  Root  HKLM  Win64    var Win64                 Key  Software Company Product  Name  InstallLocation    gt    lt  Property gt    Note  WiX guru Rob Mensching has posted an excellent blog entry which goes into more detail and fixes an edge case when properties are set from the command line   Examples using 1  2  and 3    lt  include   sys CURRENTDIR  Config wxi  gt   lt Product      gt     lt Package InstallerVersion  200  InstallPrivileges  elevated             InstallScope  perMachine  Platform    var Platform              Compressed  yes  Description    var ProductName     gt    and   lt Directory Id  TARGETDIR  Name  SourceDir  gt     lt Directory Id    var PlatformProgramFilesFolder   gt       lt Directory Id  INSTALLLOCATION  Name    var InstallName   gt   The simplest approach is always do major upgrades  since it allows both new installs and upgrades in the single MSI  UpgradeCode is fixed to a unique Guid and will never change  unless we don t want to upgrade existing product   Note  In WiX 3 5 there is a new MajorUpgrade element which makes life even easier  Creating an icon in Add Remove Programs   lt Icon Id  Company ico  SourceFile     Tools Company Images Company ico    gt   lt Property Id  ARPPRODUCTICON  Value  Company ico    gt   lt Property Id  ARPHELPLINK  Value  http   www example com     gt   On release builds we version our installers  copying the msi file to a deployment directory  An example of this using a wixproj target called from AfterBuild target    lt Target Name  CopyToDeploy  Condition     Configuration       Release   gt     lt  -- Note we append AssemblyFileVersion  changing MSI file name only works with Major Upgrades -- gt     lt Copy SourceFiles    OutputPath   OutputName  msi           DestinationFiles     Deploy Setup   OutputName    AssemblyFileVersion    Platform  msi    gt   lt  Target gt   Use heat to harvest files with wildcard     Guid  Useful if you want to reuse WXS files across multiple projects  see my answer on multiple versions of the same product   For example  this batch file automatically harvests RoboHelp output    echo off   robocopy    WebHelp   TEMP  WebHelpTemp WebHelp   E  NP  PURGE  XD  svn     WIX bin heat  dir   TEMP  WebHelp  -nologo -sfrag -suid -ag -srd -dir WebHelp -out WebHelp wxs -cg WebHelpComponent -dr INSTALLLOCATION -var var WebDeploySourceDir    There s a bit going on  robocopy is stripping out Subversion working copy metadata before harvesting  the -dr root directory reference is set to our installation location rather than default TARGETDIR  -var is used to create a variable to specify the source directory  web deployment output   Easy way to include the product version in the welcome dialog title by using Strings wxl for localization   Credit  saschabeaumont  Added as this great tip is hidden in a comment    lt WixLocalization Culture  en-US  xmlns  http   schemas microsoft com wix 2006 localization  gt       lt String Id  WelcomeDlgTitle  gt   WixUI Font Bigger Welcome to the  ProductName   ProductVersion  Setup Wizard lt  String gt   lt  WixLocalization gt   Save yourself some pain and follow Wim Coehen s advice of one component per file  This also allows you to leave out  or wild-card    the component GUID  Rob Mensching has a neat way to quickly track down problems in MSI log files by searching for value 3  Note the comments regarding internationalization  When adding conditional features  it s more intuitive to set the default feature level to 0  disabled  and then set the condition level to your desired value  If you set the default feature level    1  the condition level has to be 0 to disable it  meaning the condition logic has to be the opposite to what you d expect  which can be confusing      lt Feature Id  NewInstallFeature  Level  0  Description  New installation feature  Absent  allow  gt     lt Condition Level  1  gt NOT UPGRADEFOUND lt  Condition gt   lt  Feature gt   lt Feature Id  UpgradeFeature  Level  0  Description  Upgrade feature  Absent  allow  gt     lt Condition Level  1  gt UPGRADEFOUND lt  Condition gt   lt  Feature gt

User · Answer

Including COM Objects   heat generates all most  if not all  the registry entries and other configuration needed for them   Rejoice   Including Managed COM Objects  aka   NET or C  COM objects   Using heat on a managed COM object will give you an almost complete wix document     If you don t need the library available in the GAC  ie  globally available  MOST of the time you do not need this with your  NET assemblies anyway - you ve probably done something wrong at this point if it s not intended to be a shared library  you will want to make sure to update the CodeBase registry key to be set to   ComponentName    If you ARE planning on installing it to the GAC  eg  you ve made some new awesome common library that everyone will want to use  you must remove this entry  and add two new attributes to the File element  Assembly and KeyPath   Assembly should be set to   net  and KeyPath should be set to  yes    However  some environments  especially anything with managed memory such as scripting languages  will need access to the Typelib as well   Make sure to run heat on your typelib and include it   heat will generate all the needed registry keys   How cool is that

User · Answer

Environmental Variables  When compiling your Wxs documents to wixobj code  you can make use of environmental variables to determine various information   For example  lets say you want to change which files get included in a project   Lets say you have an environmental variable called RELEASE MODE  that you set right before you build your MSI  either with a script or manually  it doesn t matter   In your wix source  you can do something like    lt define FILESOURCE   c  source output bin   env RELEASE MODE   gt    and then later in your code  use it in place to on the fly change your wxs document  eg    lt Icon Id  myicon ico  SourceFile    var FILESOURCE     gt

User · Answer

Put Components which may be patched individually inside their own Fragments  It goes for both making product installers and patches that if you include any component in a fragment  you must include all of the components in that fragment  In the case of building an installer  if you miss any component references  you ll get a linking error from light exe  However  when you make a patch  if you include a single component reference in a fragment  then all changed components from that fragment will show up in your patch   like this    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent1  Guid   C28843DA-EF08-41CC-BA75-D2B99D8A1983   DiskId  1  gt               lt File Id  SampleFile1  Source      var Version f Sample1 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent2  Guid   6CEA5599-E7B0-4D65-93AA-0F2F64402B22   DiskId  1  gt              lt File Id  SampleFile2  Source      var Version f Sample2 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent3  Guid   4030BAC9-FAB3-426B-8D1E-DC1E2F72C2FC   DiskId  1  gt              lt File Id  SampleFile3  Source      var Version f Sample3 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    instead of this    lt Fragment gt       lt DirectoryRef Id  SampleProductFolder  gt           lt Component Id  SampleComponent1  Guid   C28843DA-EF08-41CC-BA75-D2B99D8A1983   DiskId  1  gt               lt File Id  SampleFile1  Source      var Version  Sample1 txt    gt           lt  Component gt            lt Component Id  SampleComponent2  Guid   6CEA5599-E7B0-4D65-93AA-0F2F64402B22   DiskId  1  gt              lt File Id  SampleFile2  Source      var Version  Sample2 txt    gt           lt  Component gt            lt Component Id  SampleComponent3  Guid   4030BAC9-FAB3-426B-8D1E-DC1E2F72C2FC   DiskId  1  gt              lt File Id  SampleFile3  Source      var Version  Sample3 txt    gt           lt  Component gt       lt  DirectoryRef gt   lt  Fragment gt    Also  when patching using the  Using Purely WiX  topic from the WiX chm help file  using this procedure to generate the patch   torch exe -p -xi 1 0 product wixpdb 1 1 product wixpdb -out patch diff wixmst candle exe patch wxs light exe patch wixobj -out patch patch wixmsp pyro exe patch patch wixmsp -out patch patch msp -t RTM patch diff wixmst   it s not enough to just have the 1 1 version of the product wixpdb built using the components in separate fragments  So be sure to correctly fragment your product before shipping

User · Answer

Creating Live  Test  Training      versions using the same source files   In a nutshell  Create unique UpgradeCode for each installer and automagically define the first character of each Guid for each installer  leaving the remaining 31 unique   Prerequisites   MSBuild Community Tasks   Assumptions   WiX variables are used to define UpgradeCode  ProductName  InstallName  You already have a working installer  I wouldn t attempt this until you do  All your Components are kept in one file  Components wxs   This process will work if you have multiple files  there will just be more work to do    Directory Structure   Setup Library   All wxs files  Components  Features  UI Dialogs        Common Config wxi  ProductCode      ProductVersion  PlatformProgramFilesFolder        Setup Live  wixproj    Link all Setup Library files using  Add Existing File  -   Add As Link   the little down arrow button right next to the Add button in Visual Studio  Config wxi  has unique UpgradeCode  ProductName  InstallName        Setup Test        as per live but Config wxi is configured for Test environment     Process   Create Setup Library directory and move all your wxs and wxi files  except Config wxi  from existing project  Create Setup Live  Setup Test  etc as per normal wixproj  Add BeforeBuild target in wixproj in Setup Live  etc to perform MSBuild Community Task FileUpdate to modify Guids  I used A for Live  B for Test and C for training  Add AfterBuild target to revert Components wxs Guids back to 0  Verify with Orca that each component in each MSI has the modified guid  Verify that original guids are restored   Verify that each MSI is installing  and upgrading  correct product and location    Example Config wxi   lt  xml version  1 0  encoding  utf-8   gt   lt Include gt   lt  -- Upgrade code should not change unless you want to install       a new product and have the old product remain installed        that is  both products existing as separate instances  -- gt   lt  define UpgradeCode    YOUR-GUID-HERE    gt    lt  -- Platform specific variables -- gt   lt  if   var Platform    x64   gt     lt  -- Product name as you want it to appear in Add Remove Programs-- gt     lt  define ProductName    Foo 64 Bit  Live     gt   lt  else   gt     lt  define ProductName     Foo  Live     gt   lt  endif   gt    lt  -- Directory name used as default installation location -- gt   lt  define InstallName    Foo  Live     gt    lt  -- Registry key name used to store installation location -- gt   lt  define InstallNameKey    FooLive    gt    lt  define VDirName    FooLive    gt   lt  define AppPoolName    FooLiveAppPool    gt   lt  define DbName    BlahBlahLive    gt   lt  Include gt    Example Config Common wxi   lt  xml version  1 0  encoding  utf-8   gt   lt Include gt   lt  -- Auto-generate ProductCode for each build  release and upgrade -- gt   lt  define ProductCode         gt    lt  -- Note that 4th version  Revision  is ignored by Windows Installer -- gt   lt  define ProductVersion    1 0 0 0    gt    lt  -- Minimum version supported if product already installed and this is an upgrade -- gt   lt  -- Note that 4th version  Revision  is ignored by Windows Installer -- gt   lt  define MinimumUpgradeVersion    0 0 0 0    gt    lt  -- Platform specific variables -- gt   lt  if   var Platform    x64   gt      lt  define Win64    yes    gt      lt  define PlatformProgramFilesFolder    ProgramFiles64Folder    gt   lt  else   gt      lt  define Win64    no    gt      lt  define PlatformProgramFilesFolder    ProgramFilesFolder    gt   lt  endif   gt    lt  define ProductManufacturer    Foo Technologies   gt    lt  -- Decimal Language ID  LCID  for the Product  Used for localization  -- gt   lt  define ProductLanguage    1033    gt    lt  define WebSiteName    DefaultWebSite    gt   lt  define WebSitePort    80    gt    lt  define DbServer     local     gt   lt  Include gt    Example Components wxs   lt  xml version  1 0  encoding  utf-8   gt   lt Wix xmlns  http   schemas microsoft com wix 2006 wi  gt     lt  -- The pre-processor variable which allows the magic to happen    -- gt     lt  include   sys CURRENTDIR  Config wxi  gt     lt  include    Setup Library Config Common wxi  gt     lt Fragment Id  ComponentsFragment  gt       lt Directory Id  TARGETDIR  Name  SourceDir  gt         lt Directory Id    var PlatformProgramFilesFolder   gt           lt Directory Id  INSTALLLOCATION  Name    var InstallName   gt             lt Component Id  ProductComponent  Guid  0XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  KeyPath  yes  gt                  Note  I would now suggest leaving the Guid attribute out of Component  equivalent of     using one file per component and setting the file as the keypath  This removes the need for calling ModifyComponentsGuids and RevertComponentsGuids targets shown below  This might not be possible for all your components though   Example Setup Live wixproj   lt Import Project    MSBuildExtensionsPath  MSBuildCommunityTasks MSBuild Community Tasks Targets    gt   lt Target Name  BeforeBuild  gt     lt CallTarget Targets  ModifyComponentsGuids    gt   lt  Target gt   lt Target Name  AfterBuild  gt     lt CallTarget Targets  RevertComponentsGuids    gt   lt  Target gt   lt  -- Modify the first character of every Guid to create unique value for Live  Test and Training builds -- gt   lt Target Name  ModifyComponentsGuids  gt     lt FileUpdate Files     Setup Library Components wxs  Regex  Guid  amp quot   a-f   A-F   d   ReplacementText  Guid  amp quot A    gt   lt  Target gt   lt  -- Revert the first character of every Guid back to initial value -- gt   lt Target Name  RevertComponentsGuids  gt     lt FileUpdate Files     Setup Library Components wxs  Regex  Guid  amp quot   a-f   A-F   d   ReplacementText  Guid  amp quot 0    gt   lt  Target gt    Final thoughts   This process should also work for creating different installers for different merge modules  Live  Test      as features  for the same installer  I went with different installers as it seemed a safer option  there is more risk that someone might upgrade Live instead of Training if they re on the same box and you just use features for the different merge modules  If you use your MSI to perform upgrades as well as new installs i e  the major upgrade only approach  and you save your installation location in the registry  remember to create a variable for the key name for each install  We also create variables in each Config wxi to enable unique virtual directory names  application pools  database names  et cetera for each installer    UPDATE 1  Auto-generating component Guids removes the need for calling FileUpdate task if you create component with Guid     for each file  setting the file as the keypath   UPDATE 2  One of the issues we ve come up against is if you don t auto-generate your component Guid s and the build fails  then the temp files need to be manually deleted   UPDATE 3  Found a way to remove reliance on svn externals and temporary file creation  This makes the build process more resilient  and is best option if you can t wildcard your Guids  and less brittle if there is a build failure in light or candle   UPDATE 4  Support for Multiple Instances using instance transforms is in WiX 3 0   definitely also worth a look

User · Answer

Use Javascript CustomActions because they re soooo easy  People have said that Javascript is the wrong thing to use for MSI CustomActions   Reasons given   hard to debug  hard to make it reliable   I don t agree   It s not hard to debug  certainly no harder than C     Its just different   I found writing CustomActions in Javascript to be super easy  much easier than using C     Much faster   And just as reliable    There s just one drawback  Javascript CustomActions  can be extracted via Orca  whereas a C C   CA would require reverse-engineering   If you consider your installer magic to be protected intellectual property  you will want to avoid script    If you use script   you just need to start with some structure   Here s some to get you started     Javascript  boilerplate  code for CustomAction          CustomActions js         Template for WIX Custom Actions written in Javascript             Mon  23 Nov 2009  10 54                                                                                 http   msdn microsoft com en-us library sfw6660x VS 85  aspx var Buttons             OkOnly             0          OkCancel           1          AbortRetryIgnore   2          YesNoCancel        3     var Icons             Critical           16          Question           32          Exclamation        48          Information        64     var MsgKind             Error              0x01000000          Warning            0x02000000          User               0x03000000          Log                0x04000000        http   msdn microsoft com en-us library aa371254 VS 85  aspx var MsiActionStatus             None               0          Ok                 1     success         Cancel             2          Abort              3          Retry              4     aka suspend          Ignore             5     skip remaining actions  this is not an error       function MyCustomActionInJavascript CA         try           LogMessage  Hello from MyCustomActionInJavascript                  do work here            LogMessage  Goodbye from MyCustomActionInJavascript              catch  exc1            Session Property  CA EXCEPTION     exc1 message           LogException exc1           return MsiActionStatus Abort            return MsiActionStatus Ok        Pop a message box   also spool a message into the MSI log  if it is enabled   function LogException exc        var record   Session Installer CreateRecord 0       record StringData 0     CustomAction  Exception  0x    decimalToHexString exc number            exc message      Session Message MsgKind Error   Icons Critical   Buttons btnOkOnly  record          spool an informational message into the MSI log  if it is enabled   function LogMessage msg        var record   Session Installer CreateRecord 0       record StringData 0     CustomAction       msg      Session Message MsgKind Log  record          http   msdn microsoft com en-us library d5fk67ky VS 85  aspx var WindowStyle         Hidden   0      Minimized   1      Maximized   2        http   msdn microsoft com en-us library 314cz14s v VS 85  aspx var OpenMode         ForReading   1      ForWriting   2      ForAppending   8        http   msdn microsoft com en-us library a72y2t1c v VS 85  aspx var SpecialFolders         WindowsFolder   0       SystemFolder    1       TemporaryFolder   2        Run a command via cmd exe from within the MSI function RunCmd command        var wshell   new ActiveXObject  WScript Shell        var fso   new ActiveXObject  Scripting FileSystemObject        var tmpdir   fso GetSpecialFolder SpecialFolders TemporaryFolder       var tmpFileName   fso BuildPath tmpdir  fso GetTempName          LogMessage  shell Run   command               use cmd exe to redirect the output     var rc   wshell Run   comspec   c     command     gt      tmpFileName  WindowStyle Hidden  true       LogMessage  shell Run rc        rc           here  optionally parse the output of the command      if  parseOutput            var textStream   fso OpenTextFile tmpFileName  OpenMode ForReading           while   textStream AtEndOfStream                var oneLine   textStream ReadLine                var line   ParseOneLine oneLine                                         textStream Close               if  deleteOutput            fso DeleteFile tmpFileName              return           rc   rc          outputfile    deleteOutput    null   tmpFileName              Then  register the custom action with something like this     lt Fragment gt     lt Binary Id  IisScript CA  SourceFile  CustomActions js    gt      lt CustomAction Id  CA MyCustomAction                BinaryKey  IisScript CA                JScriptCall  MyCustomActionInJavascript CA                Execute  immediate                Return  check    gt   lt  Fragmemt gt      You can  of course  insert as many Javascript functions as you like  for multiple custom actions   One example  I used Javascript to do a WMI query on IIS  to get a list of existing websites  to which an ISAPI filter could be installed   This list was then used to populate a listbox shown later in the UI sequence   All very easy    On IIS7  there is no WMI provider for IIS  so I used the shell Run   approach to invoke appcmd exe to perform the work   Easy   Related question  About Javascript CustomActions

User · Answer

Before deploying an install package I always control the content of it   It s just a simple call at the command line  according to Terrences post  open command line and enter  msiexec  a Package msi  qb TARGETDIR   CD  Extract   l vx   CD install log     This will extract package contents to an subdir  Extract  with the current path

User · Answer

Using the RobM special  Remember Property  pattern  http   robmensching com blog posts 2010 5 2 The-WiX-toolsets-Remember-Property-pattern

User · Answer

Using the RobM special  Remember Property  pattern  http   robmensching com blog posts 2010 5 2 The-WiX-toolsets-Remember-Property-pattern

User · Answer

Add a checkbox to the exit dialog to launch the app  or the helpfile           lt  -- CA to launch the exe after install -- gt   lt CustomAction Id            CA StartAppOnExit                FileKey       YourAppExeId                ExeCommand                    Execute       immediate                Impersonate   yes                Return        asyncNoWait    gt    lt  -- CA to launch the help file -- gt   lt CustomAction Id           CA LaunchHelp                Directory    INSTALLDIR                ExeCommand    WindowsFolder hh exe IirfGuide chm                Execute      immediate                Return       asyncNoWait    gt    lt Property Id  WIXUI EXITDIALOGOPTIONALCHECKBOXTEXT            Value  Launch MyApp when setup exits     gt    lt UI gt     lt Publish Dialog    ExitDialog             Control   Finish             Order     1             Event     DoAction             Value     CA StartAppOnExit  gt WIXUI EXITDIALOGOPTIONALCHECKBOXTEXT lt  Publish gt   lt  UI gt      If you do it this way  the  standard  appearance isn t quite right   The checkbox is always a gray background  while the dialog is white    alt text http   www dizzymonkeydesign com blog misc adding-and-customizing-dlgs-in-wix-3 images exit dlg 1 gif  One way around this is to specify your own custom ExitDialog  with a differently-located checkbox   This works  but seems like a lot of work just to change the color of one control   Another way to solve the same thing is to post-process the generated MSI to change the X Y fields in the Control table for that particular CheckBox control   The javascript code looks like this    var msiOpenDatabaseModeTransact   1  var filespec   WScript Arguments 0   var installer   new ActiveXObject  WindowsInstaller Installer    var database   installer OpenDatabase filespec  msiOpenDatabaseModeTransact   var sql    UPDATE  Control  SET  Control   Height     18    Control   Width     170                   Control   Y   243    Control   X   10                 WHERE  Control   Dialog    ExitDialog  AND                    Control   Control   OptionalCheckBox    var view   database OpenView sql   view Execute    view Close    database Commit        Running this code as a command-line script  using cscript exe  after the MSI is generated  from light exe  will produce an ExitDialog that looks more professional   alt text http   www dizzymonkeydesign com blog misc adding-and-customizing-dlgs-in-wix-3 images exit dlg 2 gif

User · Answer

We display the product version somewhere  tiny  in the first screen of the GUI  Because people tend to make mistakes in picking the right version every time   And keep us developers searching for ages    We ve set up TFSBuild to also generate transforms   mst files  with the configuration for our different environments   We know about all environments we need to deploy to      Since the original weblog post by Grant Holliday is down  I copy pasted its contents here     MSBuild task to generate MSI Transform files from XMLMarch 11 2008  In my previous post I described how you can use MSI Transform    mst  files to separate environment-specific configuration settings from a generic MSI package   Although this provides a level of flexibility in your configuration  there are two down-sides of Transform files    They   re a binary format You can   t    edit    or    view    a transform file  You have to apply it or re-create it to see what changes it includes    Fortunately we can use the Microsoft Windows Installer Object Library  c windowssystem32msi dll  to open MSI    databases    and create transform files   Credits go again to Alex Shevchuk     From MSI to WiX     Part 7     Customising installation using Transforms for showing us how to achieve this with VbScript  Essentially all I   ve done is taken Alex   s example and using Interop WindowsInstaller dll I   ve implemented an MSBuild task  The  MSBuild Task  Download the source code  amp  example transforms xml here   7Kb Zipped VS2008 Solution

User · Answer

Fix the ProgressDlg so that it displays properly   I ve increased the font size for my installer from 8 to 10  to make the font a more human  usable scale on high-res monitors  I do this with this XML magic     lt UI Id  MyCustomUI  gt     lt TextStyle Id  WixUI Font Normal  FaceName  Tahoma  Size  10    gt     lt TextStyle Id  WixUI Font Big     FaceName  Tahoma  Size  12    gt     lt TextStyle Id  WixUI Font Bigger  FaceName  Tahoma  Size  14    gt     lt TextStyle Id  WixUI Font Title   FaceName  Tahoma  Size  12  Bold  yes    gt      lt Property Id  DefaultUIFont  Value  WixUI Font Normal    gt   lt  UI gt    But this means the ProgressDlg doesn t display properly any longer   This is the one that displays the progress of the install  right at the very end   The ActionText gets clipped  so descenders on letters like g and j do not display   Fix this by adjusting the size and position of the various controls on the Progressdialog  in a post-processing Javascript  Run this script after generating the MSI     var msiOpenDatabaseModeTransact   1  var filespec   WScript Arguments 0   var installer   new ActiveXObject  WindowsInstaller Installer    var database   installer OpenDatabase filespec  msiOpenDatabaseModeTransact       The text on the exit dialog is too close to the title   This     step moves the text down from Y 70 to Y 90  about one line   sql    UPDATE  Control  SET  Control   Y     90           WHERE  Control   Dialog    ExitDialog  AND  Control   Control   Description    view   database OpenView sql   view Execute    view Close        The progressbar is too close to the status text on the Progress dialog      This step moves the progressbar down from Y 115 to Y 118  about 1 3 line   sql    UPDATE  Control  SET  Control   Y     118           WHERE  Control   Dialog    ProgressDlg  AND  Control   Control   ProgressBar    view   database OpenView sql   view Execute    view Close        The StatusLabel and ActionText controls are too short on the Progress dialog     which means the bottom of the text is cut off   This step    increases the height from 10 to 16  sql    UPDATE  Control  SET  Control   Height     16           WHERE  Control   Dialog    ProgressDlg  AND  Control   Control   StatusLabel    view   database OpenView sql   view Execute    view Close    sql    UPDATE  Control  SET  Control   Height     16           WHERE  Control   Dialog    ProgressDlg  AND  Control   Control   ActionText    view   database OpenView sql   view Execute    view Close     database Commit

[wix] WiX tricks and tips

Printing EULA from Wix3.0 and later

Examples related to wix

Examples related to wix3.5

Examples related to wix3