Entry for WiX bundle is not removed from the ARP list when uninstalled via UpgradeVersion element - wix

Our application is installed using a WiX bootstrapper. Consequently, the Windows 10 Apps and Features list (a.k.a. ARP) shows an entry for the bundle, and another entry for the .msi which is contained within it.
On my system, I have OurApp v.9.0 installed, as well as v.9.1 Beta. When I install the upgrade, v.9.1 Full Release, it is seen as an upgrade to v.9.0, which is automatically uninstalled. v.9.1 Beta is also uninstalled by use of the following code:
<!-- Uninstall Beta Version [only use this for Full Release] -->
<?if Not $(var.Phase) = "Beta" ?>
<Upgrade Id='233E450E-182F-4823-9C24-2F28A93A52A8'>
<UpgradeVersion OnlyDetect='no' Property='OLDINSTALLER' Minimum='0.0.0' />
</Upgrade>
<?endif?>
Unfortunately, the entry for OurApp 9.1 Beta bundle is sometimes left behind in the ARP list after uninstalling. (The OurApp 9.1 Beta .msi package was successfully removed from the ARP list.) If I try to uninstall the Beta bundle again, it simply disappears without really doing anything. Usually, uninstalling the app from ARP will cause some uninstallation dialogs to appear, but in this case, they don't appear, the entry is simply removed from ARP.
I have looked at the following posts for guidance:
WiX upgrade didn't remove the earlier product from ARP
MSI uninstall does not remove product entry in program features
After using msiexec to uninstall a program it remains in the control panel (add/remove programs)
Unfortunately, these don't seem to be describing quite the same situation as I'm seeing, and I don't understand the suggestions well enough to determine what to do in our case. I did happen to see this comment:
"Duplicate installations are very common in such cases as a by-product of rapid test cycles."
Since "rapid test cycles" would describe well our situation, I'm wondering if this might be the case for us. However, I have 2 difficulties:
I don't understand how to confirm that this is happening or what to do about it.
I get the impression that this would be unlikely to occur on an end-user's system, since they are not participating in these "rapid test cycles". Do we actually need to do anything?
I would appreciate any input / advice on dealing with this situation.
UPDATE:
Here is the WiX code for building our bundle:
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension"
xmlns:dep="http://schemas.microsoft.com/wix/DependencyExtension">
<Bundle
Name='UsefulApp $(var.TruncatedVersion) $(var.Phase)'
Version='$(var.VersionNumber)'
UpgradeCode='$(var.UpgradeCode)'
Tag='UsefulFrmwrkBndl'
IconSourceFile='$(var.UsefulInstallIcon)'
Copyright="Copyright ©$(var.CurrentYear), $(var.ProducedBy). All Rights Reserved."
Manufacturer='$(var.ProducedBy)'>
<bal:Condition Message="32-bit Windows is no longer supported."> (VersionNT64 >= v6.0) </bal:Condition>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
<Payload SourceFile="UsefulLicense.htm" />
</BootstrapperApplicationRef>
<!--<RelatedBundle Id='$(var.UpgradeCode)' Action='Detect'/>-->
<WixVariable Id="WixStdbaLicenseUrl" Value="UsefulLicense.htm" />
<WixVariable Id="WixStdbaLogo" Value=".\resources\image_option_1.bmp" />
<WixVariable Id="WixStdbaThemeXml" Value="UsefulHyperlinkTheme.xml" />
<WixVariable Id="WixStdbaThemeWxl" Value="UsefulHyperlinkTheme.wxl" />
<Chain>
<PackageGroupRef Id="NetFx48" />
<PackageGroupRef Id="redist_vc14" />
<RollbackBoundary />
<PackageGroupRef Id='UsefulFrameworkPackGroup'/>
</Chain>
</Bundle>
<Fragment Id='UsefulFrag'>
<PackageGroup Id='UsefulFrameworkPackGroup'>
<MsiPackage Id='UsefulMsiPack'
DisplayName='UsefulApp $(var.VersionNumber)'
DisplayInternalUI='yes'
ForcePerMachine='yes'
InstallCondition='1'
SourceFile='UsefulApp_$(var.VersionNumber)_Installer.msi'
Visible='yes'
Vital='yes'>
</MsiPackage>
</PackageGroup>
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full"
Value="Version" Variable="Netfx48FullVersion" />
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full"
Value="Version" Variable="Netfx48x64FullVersion" Win64="yes" />
</Fragment>
</Wix>

Related

WiX Bundle not displaying MSIs in Programs and Features

I've got new, weird behavior in my bundle installation: the MSIs -- which used to appear in Programs and Features -- have stopped appearing in Programs and Features (hereafter referred to as P&F).
The behavior that I'd like to happen is for the programs that I install as MSIs to appear in P&F, giving the user the chance to uninstall them discretely.
What I've tried/noticed:
If I install the MSIs without bundling them:
they appear in P&F, and are able to be uninstalled
moreover, I can control whether they appear in P&F by setting the ARPSYSTEMCOMPONENT property to either 1 (default is 0, meaning "do appear in P*F), that is:
<Property Id="ARPSYSTEMCOMPONENT" Value="1"/>
these changes are reflected in the registry. When examining the key HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall/{GUID}, if I set the property to 1 it shows up (it doesn't show up when I set it to 0, but I think that's because defaults don't show up).
However, when I put the MSIs into a Bundle, bingo-bango-bongo they disappear from P&F! And, if I check the registry, the SystemComponent property is set to 1 for each MSI.
I'm reaching the conclusion that somehow, in my bootstrapper, the SystemComponent properties for my MSIs are being set to 1. But where could these properties be set? Needless to say, I never set them in my WiX XML (at least, I don't think I do). I don't have any special UI for the bootstrapper (just a license), and the MSIs themselves install quietly, with no UI.
I'm stuck! Can anyone shed some light on this?
I'm using Visual Studio 2015, WiX version 3.10. Here's the entirety of my Bootstrapper code:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension">
<Bundle Name="****"
Version="1.0.5.0"
Manufacturer="****"
UpgradeCode="7be91f26-93f8-400c-9eac-e69383454e03"
IconSourceFile="src\****.ico" DisableModify="yes" DisableRemove="yes"
AboutUrl="****.com"
Copyright="Copyright 2017, ****">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication LicenseFile="src\****_License.rtf"
SuppressOptionsUI="yes"/>
</BootstrapperApplicationRef>
<!-- The two registry serarches provide a variable, what version of .NET is installed on the target machine. One search
is for x86, the other for x64. -->
<util:RegistrySearch Root="HKLM"
Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full"
Value="Version"
Variable="Net452FullVersion"/>
<util:RegistrySearch Root="HKLM"
Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full"
Value="Version"
Variable="Net452x64FullVersion"
Win64="yes"/>
<Chain>
<ExePackage
Id="Microsoft_dot_Net_4.5.2"
Name="Microsoft 4.5.2 Setup"
Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
SourceFile="executables\NDP452-KB2901907-x86-x64-AllOS-ENU.exe"
InstallCommand="/q"
DetectCondition="(Net452FullVersion = "4.5.51209") AND (NOT VersionNT64 OR (Net4x64FullVersion = "4.5.51209"))"
InstallCondition="(VersionNT >= v6.0 OR VersionNT64 >= v6.0) AND (NOT (Net452FullVersion = "4.5.51209" OR Net452x64FullVersion = "4.5.51209"))"/>
<ExePackage Id="Microsoft_Visual_C_plus_plus_Redistributable_2015"
InstallCommand="/q"
SourceFile="executables\vc_redist.x86.exe"/>
<RollbackBoundary/>
<MsiPackage SourceFile="$(var.****.TargetPath)"/>
<MsiPackage SourceFile="$(var.****.TargetPath)"/>
<ExePackage SourceFile="executables\****.exe" InstallCommand="/S"/>
<ExePackage SourceFile="executables\****.exe"/>
</Chain>
</Bundle>
</Wix>
The MsiPackage/#Visible attribute controls whether MSI packages are shown in ARP.

WiX Bundle bal:condition - util:RegistrySearch - Not working

A similar post is up here but I cant get mine working
WiX Bundle bal:condition - util:RegistrySearch variable always false
Sir, I am struggling get this exact thing working. "Version" is set to 0 when Registry key is absent and to 1 when key is present. Either cases my bundle still gets installed.
I am using VS 2015 and Wix 3.10. Pls can you help.
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="XXX"
Version="XXX"
Manufacturer="XXX"
UpgradeCode="XXX"
IconSourceFile="XXX"
Copyright="XXX" >
<util:RegistrySearchRef Id='SearchForMyIns' />
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost">
...
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id='NetFx40Web' />
<MsiPackage SourceFile="$(var.DummyInstaller.TargetDir)\DummyInstaller.msi" DisplayName="Dummy Conditioning" />
</Chain>
</Bundle>
<Fragment>
<util:RegistrySearch
Id='SearchForMyInst'
Variable="Version"
Result="exists"
Root="HKLM"
Key="SOFTWARE\MyInst"
Win64="yes" />
<bal:Condition Message="ThirdParty Application Required.">Version</bal:Condition>
</Fragment>
</Wix>
The Bal:Condition doesn't evaluate if you are using MBA. Check the following link
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Burn-Bundle-condition-does-not-work-if-using-MBA-td7581757.html
Change
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost">
to
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
You will see Bal:Condition working
The reason this is always installing for you is that
<bal:Condition Message="messagehere">Version</bal:Condition>
will evaluate the existance of Version not the value of Version. Since your registry search is on exists, Version is always defined and thus the condition always passes. (I believe this is because all registry search variables are implicitly string variables)
If you add "Version = 1" then your installation should only continue when your registry search does find what you're looking for.
I would also like to point out a particularly nasty pitfall of this type of condition. What happens if a user installs your bundle then decides they don't need your bundle or the third party program anymore and they uninstall them both but they uninstall the third party program first?
Your installer will be unable to uninstall because when it tries to run it will fail the bal:Condition every time since the third party program is no longer present on the system.
To solve this behaviour you should add "OR WixBundleInstalled" to your bal:Condition.

WIX - How to selectively uninstall the <Bundle>

I want to retain the previous versions of my Bootstrapper App, how to achieve this?
I know that we can use the Upgrade tag in MSI where we can identify the different versions and perform uninstall operations base on those.
Now, I have a Bundle Application that has one or more MSI which use some UpgradeCode. Each time I create a new build I just version up the MSI and this Bundle Application. When I proceed with installing of later version of Bundle App, it uninstall the previous Bundle version, which is not what I want. I want to retain the previous versions of my Bundle Application.
Is there anything like UpgradeVersion in Bundle as well, where we would be able to identify the diferent versions and do selectively uninstall.
My Bundle file code snippet :
<Bundle Name="myApp"
Version="1.0.0.0"
Manufacturer="Myself"
UpgradeCode="SOME-GUID">
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost" >
...
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id= 'WindowsInstaller45'/>
<PackageGroupRef Id ='NetFx45Offline'/>
<PackageGroupRef Id ='MY_MSI'/>
</Chain>
</Bundle>
<Fragment Id ='PkgFragments'>
<PackageGroup Id ="MY_MSI">
<MsiPackage SourceFile= "$(var.Installer.TargetPath)"
Id="MYAPP"
Cache ="yes"
Visible ="no"
DisplayInternalUI ="no"
Permanent="no">
<MsiProperty Name='INSTALLLOCATION' Value='[InstallFolder]' />
<MsiProperty Name='SELECT_UNINST' Value='[UninstallPrevVersion]' />
</MsiPackage>
</PackageGroup>
</Fragment>
My Product WIX file code snippet
<Product Id="*"
Name="$(var.ProductName)"
Version="$(var.ProductVersion)"
Manufacturer="$(var.ManufacturerName)"
UpgradeCode="$(var.UpgradeCode)">
<Property Id="SELECT_UNINST" Secure="yes">1</Property>
<Upgrade Id="SOME-GUID2">
<UpgradeVersion Minimum="0.0.0.0" Maximum="$(var.ProductVersion)" IncludeMinimum="yes" IncludeMaximum="yes" Property="UNINSTALL_PREV_VERSION" />
</Upgrade>
<CustomAction Id="UninstPrev" Property="UNINSTALL_PREV_VERSION" Value="0" />
<InstallExecuteSequence>
<Custom Action="UninstPrev" Before="InstallInitialize"><![CDATA[SELECT_UNINST <> 1]]></Custom>
<RemoveExistingProducts Overridable="no" After="UninstPrev"></RemoveExistingProducts>
</InstallExecuteSequence>
</Product>
I'll put this as an answer too.
If you don't want to remove your previous versions don't treat the new version as an upgrade to the old one. This means change the upgrade GUID and change the product GUID. If you need to remove a specific version, add the bundle as a <RelatedBundle> in your Bundle definition and properly handle OnPlanRelatedBundle in your Bootstrapper Application.
<RelatedBundle Action="Detect" Id="$(var.ProductVersion622UpgradeGUID)"/>
Additionally, any msi packages you install also would need to employ the same behaviour of new upgrade GUIDs if you don't want removal between "upgrades". Keep a list of which GUIDs are with which released versions. If you want to remove specific versions in a release of your msi you need to add
<Upgrade Id="$(var.Version6InstallerUpgradeGUID)" >
<UpgradeVersion
IncludeMaximum ="no"
IncludeMinimum="yes"
Maximum="6.0.0.1"
Minimum="6.0.0.0"
MigrateFeatures="no"
Property="V6FOUND"
OnlyDetect="no" />
</Upgrade>
I would consider this requirement very odd and would suggest you really think upon whether or not you really want to support this kind of behaviour.
Also to note, the entry in the ARP for the bootstrapper existing doesn't necessarily mean the products it installed are still on the system. You can test this by always setting pRequestedState = RequestState.Present; in OnPlanRelatedBundle and setting your msi packages to visible="yes". You will have the old bundle listed in the ARP but the packages it installs were probably upgraded by the newer version so it's just an entry that doesn't mean anything.

how to manually purge an malformed wix-burn package?

I am in the process of learning how to develop a custom managed bootstrapper for wix-burn. Up to my knowlege there are no official tutorials, unofficial tutorials are always filled with WPF stuff which I'm not interested in and most people on forums do not do much more than saying that you must create a class that inherits from BootstrapperApplication and overrides the Run() method.
I did that, created the config file, added the payloads to the xml markup. The resulting installer did nothing, actually it ran forever, only killing it stopped it. I sincerely expected that calling base.Run() would give me some basic default GUI-less behavior. But that is only an abstract method. Eventually I learned that I must call some Engine.functions() to actually do some work. So I wrote this to test:
protected override void Run()
{
Engine.Detect();
Engine.Plan(LaunchAction.Install);
Engine.Apply(IntPtr.Zero);
Engine.Quit(0);
}
I successfully compiled a package that actually installed, the problem is that it can not be uninstalled. My question is, what can I do to purge it from my system? What registry keys must I erase, what cached packages must I delete, and what else must I do to get rid of it?
First, the registry key will be in one of the two locations listed below -- and it's probably the first one since the second is for 32-bit applications installed on a 64-bit OS.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninst‌​all
Second, you can use the registry key to determine where the executable is cached for uninstall, which is probably in a folder that looks like C:\ProgramData\Package Cache.
If this were an .msi installation, there's another registry key and the file is cached in a different location as mentioned here.
Other links:
https://superuser.com/questions/401511/how-to-remove-a-broken-program-from-the-programs-and-features-list-in-windows-7
https://support.microsoft.com/en-us/kb/247501
Ufff, you've got yourself into a hell. :) I'll help you as much as I can.
How did you installed that package?
dlls that you can find interesting:
BootstrapperCore.dll (included with the WiX SDK)
Microsoft.Deployment.WindowsInstaller.dll (included with the WiX SDK)
WindowsBase.dll (for threading)
And, one of XML files should be like this, so you can see what exactly is up there.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="My Test Application" Version="1.0.0.0" Manufacturer="Bryan" UpgradeCode="PUT-GUID-HERE">
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost">
<Payload SourceFile="..\TestBA\BootstrapperCore.config"/>
<Payload SourceFile="..\TestBA\bin\Release\TestBA.dll"/>
<Payload SourceFile="..\TestBA\bin\Release\GalaSoft.MvvmLight.WPF4.dll"/>
<Payload SourceFile="C:\Program Files\WiX Toolset v3.6\SDK\Microsoft.Deployment.WindowsInstaller.dll"/>
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id='Netfx4Full' />
<MsiPackage SourceFile="..\DummyInstaller\bin\Release\DummyInstaller.msi" Id="DummyInstallationPackageId" Cache="yes" Visible="no"/>
</Chain>
</Bundle>
<Fragment>
<!-- Managed bootstrapper requires .NET as a dependency, since it was written in .NET.
WiX provides a Bootstrapper for the bootstrapper. The fragment below includes .NET.
For more information or examples see Heath Stewart's blog or the WiX source:
http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx
-->
<WixVariable Id="WixMbaPrereqPackageId" Value="Netfx4Full" />
<WixVariable Id="WixMbaPrereqLicenseUrl" Value="NetfxLicense.rtf" />
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full" Value="Version" Variable="Netfx4FullVersion" />
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full" Value="Version" Variable="Netfx4x64FullVersion" Win64="yes" />
<PackageGroup Id="Netfx4Full">
<ExePackage Id="Netfx4Full" Cache="no" Compressed="yes" PerMachine="yes" Permanent="yes" Vital="yes"
SourceFile="C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40\dotNetFx40_Full_x86_x64.exe"
DownloadUrl="http://go.microsoft.com/fwlink/?LinkId=164193"
DetectCondition="Netfx4FullVersion AND (NOT VersionNT64 OR Netfx4x64FullVersion)" />
</PackageGroup>
</Fragment>
</Wix>
Note: your registry search and conditions are a little different from
what is used in the WiX toolset to detect NETFX. The following is the
detection for NETFX the WiX toolset uses:
<util:RegistrySearch
Id="NETFRAMEWORK40"
Variable="NETFRAMEWORK40"
Root="HKLM"
Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"
Value="Install"
Result="value" />
Next solution can be this:
Include a PackageGroupRef element in your Chain:
<Bundle>
<Chain>
<PackageGroupRef Id="NetFx452" />
<MsiPackage ... />
</Chain>
</Bundle>
Download the Microsoft .NET Framework 4.5.2 (Offline Installer), and add it to your Bootstrapper Project. (I put it in a folder called "Resource".)
Add the following Fragment:
<Fragment>
<util:RegistrySearchRef Id="NETFRAMEWORK45"/>
<PackageGroup Id="NetFx452">
<ExePackage Id="NetFx452"
Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
Name="NDP452-KB2901907-x86-x64-AllOS-ENU.exe"
SourceFile="Resource\NDP452-KB2901907-x86-x64-AllOS-ENU.exe"
DetectCondition="NETFRAMEWORK45"
InstallCommand="/q /norestart" />
</PackageGroup>
</Fragment>

Wix util:registrysearch unrecognized

I am using Sharp Develop 4.4.1 to create a wix installer package for my application. The WIX version is the one that came with Sharp Develop, namely version 3.8.
My MSI project builds just fine.
Now I want to include the MSI in a bundle. In the bundle, I want to check if .net 4.5 and ghostscript are installed (otherwise install it). The .net package check is a breeze using packagegroupref.
So far so good.
However, I also want to check if Ghostscript is installed and intend to do this by doing a registry search. Since I am working in a Bundle, I am trying to use <util:RegistrySearch....., but I get an error stating: The Fragment element contains an unhandled extension element 'util:RegistrySearch'. Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/UtilExtension' namespace has been provided. (CNDL0200) - d:\SharpDev Projects\NREOutlookTest1\AIFBundle\Setup.wxs:20
This is my bundle code:
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Bundle UpgradeCode="ae0120aa-0ba8-45ac-b3e5-fce0f6b05de6"
Name="!(bind.packageName.AIF)"
Version="!(bind.packageVersion.AIF)"
Manufacturer="!(bind.packageManufacturer.AIF)"
IconSourceFile=".\images\stamp.ico">
<WixVariable Id="WixStdbaLicenseUrl" Value="myurl" />
<WixVariable Id="WixStdbaLogoFile" Value="..\NREOutlookTest1\images\stamp.jpg" />
<WixVariable Id="WixStdbaLogoSideFile" Value="..\NREOutlookTest1\images\stamp.jpg" />
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkSidebarLicense" />
<Chain>
<PackageGroupRef Id="NetFx45Web" />
<PackageGroupRef Id="Ghostscript" />
<MsiPackage Id="AIF" SourceFile="..\AIFSetup\bin\Release\AIFSetup.msi" Visible="no" />
</Chain>
</Bundle>
<Fragment>
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\GPL Ghostscript\9.14" Value="GS_DLL" Variable="GhostScriptDetect" />
<PackageGroup Id="Ghostscript">
<ExePackage
Id="gs914"
DisplayName="GPL Ghostscript"
Cache="no"
Compressed="no"
Permanent="no"
Vital="yes"
DetectCondition="GhostScriptDetect >> "gsdll32.dll""
InstallCommand="/S"
SourceFile="gs914w32.exe"
DownloadUrl="http://downloads.ghostscript.com/public/gs914w32.exe" />
</PackageGroup>
</Fragment>
</Wix>
I have included the Wix Extension WixUtilExtension.dll in the project:
OK. I am officially an idiot. I have a post compile script running in sharpdevelop that is doing a candle and light action. I forgot to include the extension in the candle command, which gave me the error. DOH!!