Wix

Resolving Special Folders in WiX 3.0

EltonStoneman — Tue, 29 Sep 2009 18:09:43 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

One of the frustrations of working with WiX is that when you want to do something out of the ordinary, chances are it's provided somewhere in a WiX extension, but unless you trawl through the XSDs you're not likely to find it. I had this issue when I wanted to resolve the special folder My Music through WiX, so I could put the full path into a config file.

Various special folders are already available as properties to the installer, including My Documents and My Pictures, but not My Music. Adding an extension to expose Environment.GetSpecialFolder() to WiX is a trivial implementation in a couple of classes (comments omitted for brevity):

public class EnvironmentExtension : WiXExtension

{

private EnvironmentPreprocessorExtension preprocessorExtension;

public override PreprocessorExtension PreprocessorExtension

{

get

{

if (this.preprocessorExtension == null)

{

this.preprocessorExtension = new EnvironmentPreprocessorExtension();

}

return this.preprocessorExtension;

}

public class EnvironmentPreprocessorExtension : PreprocessorExtension

{

private const string SPECIALFOLDER = "specialFolder";

public override string[] Prefixes { get { return new string[] { SPECIALFOLDER }; } }

private List<string> _specialFolders;

private List<string> SpecialFolders

{

get

{

if (_specialFolders == null)

{

_specialFolders = new List<string>(Enum.GetNames(typeof(Environment.SpecialFolder)));

}

return _specialFolders;

}

public override string GetVariableValue(string prefix, string name)

{

string result = null;

if (prefix == SPECIALFOLDER && SpecialFolders.Contains(name))

{

Environment.SpecialFolder specialFolder = (Environment.SpecialFolder)Enum.Parse(typeof(Environment.SpecialFolder), name, true);

result = Environment.GetFolderPath(specialFolder);

}

return result;

}

Reference the folder you want from the Environment.SpecialFolders enum as a property in your WiX script:

- and add the extension assembly to your light and candle calls, making sure the DLL is available at runtime :

candle -out x.y.z.WiXobj x.y.z.wxs -ext EnvironmentExtension

light -out x.y.z.msi x.y.z.WiXobj -ext EnvironmentExtension -cultures:en-us

But I suspect it's already available somewhere in WiX.

Wix Errors ICE50 and ICE64

EltonStoneman — Sat, 13 Dec 2008 02:18:46 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

If you're creating shortcuts in a Wix package, Alex Shevchuk's post From MSI to WiX, Part 10 – Shortcuts is a great resource to follow. As it does, Wix has moved on, and Alex's scripts don't build in the current version (3.0.4318.0 on my box) – the LongName attribute has been deprecated, so remove any instances you find and put the full name in the Name attribute (Wix now takes care of generating a short name).

You may also find a couple of Internal Consistency Evaluator errors:

ICE50 - shortcut icon extension doesn't match shortcut file's extension, so the shortcut icon won't be correct
ICE64 - shortcut folders not being tagged in a RemoveFolder element so they're removed on uninstall

I couldn't fix ICE50 as I was pointing to a .htm file and didn't fancy hacking its extension to .exe to keep Wix happy, and although ICE64 is easy to fix (Alex describes how to do this), I'm generating the Wix script with T4 and it proved fiddly to inject the RemoveFolder elements under the correct Component element. So I tried linking and ignoring the errors, just to confirm my shortcuts were creating correctly. The error suppression syntax is:

light -out <outputMsiPath> <inputWixobjPath> -cultures:en-us -sice:ICE50 -sice:ICE64

This built the MSI, and the installer ran correctly. The interesting thing is that the .htm shortcut did have the right icon, and when I uninstalled the package, my shortcut folders were removed too. So it seems ICE50 and ICE64 can be safely suppressed without affecting the user experience.

T4 template to generate Wix scripts to generate WCF MSIs in MSBuild

EltonStoneman — Thu, 04 Sep 2008 19:55:11 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Snappy title. We have a project which contains lots of WCF Service projects, and we want to generate MSIs so we can deploy them to IIS. The gaps between the projects are minimal as they all use the same structure, so instead of having separate Setup or Wix files in each of the solutions, generating the WXS files on the fly was an option.

The installer steps we wanted were reasonably simple:

install WCF artifacts to the chosen directory (.svc and web.config files)
install WCF binaries to the chosen directory\bin
install dependencies to the GAC
create a virtual directory in IIS pointing to the install directory

The only UI we particularly needed was the choice of install directory, so the Wix for this fits into a fairly straightforward T4 template:

<#@ template language="C#" #>

<#@ output extension=".xml" #>

<#@ assembly name="System.dll" #>

<#@ import namespace="System.IO" #>

<#@ import namespace="System.Security.Cryptography" #>

<#@ import namespace="System.Text" #>

<?xml version="1.0" encoding="UTF-8"?>

<Product Id="<#= this.GetProductId() #>"

Name="<#= ServiceName #>"

Language="1033"

Version="<#= VersionNumber #>"

Manufacturer="Company"

UpgradeCode="<#= this.GetUpgradeCode() #>">

<Media Id="1" Cabinet="<#= ServiceName #>.Install.cab" EmbedCab="yes" />

<# foreach (string filePath in this.WcfArtifacts.Split(';'))

{

this.AddFile(filePath);

}#>

</Component>

<# int index = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<Component Id="GACComponent_<#= index++ #>" Guid="<#= this.GetNewGuid() #>" SharedDllRefCount="yes">

<# this.AddAssemblyToGAC(assemblyPath); #>

</Component>

<#}#>

<# this.AddAssembly(this.WcfAssembly); #>

</Component>

</Directory>

<iis:WebVirtualDir Id="WcfVirtualDir" Alias="<#= ServiceName.TrimEnd(".Wcf".ToCharArray()) #>" Directory="INSTALLLOCATION" WebSite="DefaultWebSite">

<iis:WebApplication Id="WcfApplication" Name="<#= ServiceName #>" />

</iis:WebVirtualDir>

</Component>

</Directory>

<iis:WebSite Id="DefaultWebSite" Description="Default Web Site">

<iis:WebAddress Id="AllUnassigned" Port="80" />

</iis:WebSite>

<Feature Id="ProductFeature" Title="<#= ServiceName #>" Level="1">

<# int i = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<# } #>

</Feature>

</Product>

</Wix>

<#+

private string ServiceName

{ get{ return "$(ProjectName).$(ProjectFilter)"; }}

private string VersionNumber

{ get{ return "$(Version)"; }}

private string WcfArtifacts

{ get{ return @"@(WcfArtifacts)"; }}

private string WcfAssembly

{ get{ return @"@(WcfAssembly)"; }}

private string WcfDependencies

{ get{ return @"@(WcfDependencies)"; }}

…

- the full template is here: WCF Service Wix template.

A couple of interesting things here – the Guids are generated from the name of the elements (see Generating Deterministic Guids), so multiple versions will have the same Guid and will operate as updates, provided the name of the service doesn't change; the tags for MSBuild properties in the template get resolved using the ExecuteT4Template MSBuild task; the GACd assemblies flag themselves as SharedDllRefCount so if you uninstall this package, the files will be left in the GAC if any other packages use them, but removed if this is the only package that uses them.

Another custom task is needed to resolve the dependencies of the WCF assembly (sample version here: MSBuild ResolveDependencies task), and the MSBuild snippet to run it together with the Wix commands looks like this:

<ResolveDependencies AssemblyList="@(WcfAssembly)"

Filter="$(CompanyName).$(ProductName)">

</ResolveDependencies>

</Target>

<ExecuteT4Template ToolPath="$(MSBuildProjectDirectory)\$(BuildBinDir)"

TemplatePath="$(TemplateRoot)\Services.Wcf.wxs.tt"

OutputPath="$(ArtefactWixDir)\$(ProductName).$(ProjectName).Wcf.wxs">

</ExecuteT4Template>

</Target>

- we store all the intermediate files (the T4 template with resolved property values, WXS and WIXOBJ files) to help with debugging.

Wix error -532459699

EltonStoneman — Fri, 25 Jul 2008 20:43:14 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Running Wix 3.0.2420.0 I got an "object reference not set" and this error message when calling light.exe from an Exec MSBuild task:

The command ""..\bin\Wix\light" -out "c:\x\y\z\x.y.z.msi" "c:\x\y\z\x.y.z.wixobj" -ext WixIIsExtension -ext WixUiExtension -cultures:en-us" exited with code -532459699.

Annoyingly, I could run the exact same command in a command prompt immediately after the build failed, and it worked fine - and this error only happened on the build server and not on the dev boxes.

Before diving into it too much, I updated to the latest version of Wix (currently 3.0.4318.0) and the problem went away. So that solved that issue and just left me with "should we be using beta software even if it works for everything we need at the moment"…