WiX Bundle bal:condition - util:RegistrySearch variable always false - installation

I want my install to fail if a third-party software element is not installed. I added a Fragment with a util:RegistrySearch and a bal:Condition to the Bundle, but I can't get it to work. ThirdPartyCOMLibraryInstalled never evaluates to true. I've confirmed that the key exists, and the value I use for Key is correct - I copy/pasted the name from the selected key in regedit. There aren't any errors in the log.
I'm building the installer with WiXTools 3.7 in Visual Studio 2012 on Windows 7 64-bit and testing on both Windows XP SP3 and Windows 7 64-bit.
Searching online for other examples for util:RegistrySearch I ran across the following alternative forms for the condition test expression.
ThirdPartyCOMLibraryInstalled = 0 - always False
ThirdPartyCOMLibraryInstalled <> 1 - always True
Here is the Bundle code:
<?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:netfx="http://schemas.microsoft.com/wix/NetFxExtension"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="!(bind.packageName.MyApp)"
Version="!(bind.packageVersion.MyApp)"
Manufacturer="!(bind.packageManufacturer.MyApp)"
UpgradeCode="a07ce1d5-a7ed-4d89-a7ee-fb13a5dd69ba"
Copyright="Copyright (c) 2013 [Bundle/#Manufacturer]. All rights reserved."
IconSourceFile="$(var.My_Application1.ProjectDir)MyCo.ico">
<bal:Condition Message="ThirdParty Application COM Library Required. Please (re)install ThirdParty Application and ensure 'Windows API' and '.NET Components' are installed."
>ThirdPartyCOMLibraryInstalled</bal:Condition>
<Variable Name="InstallFolder"
Type="string"
Value="[ProgramFilesFolder]MyCo Systems\My_Application\"/>
<BootstrapperApplicationRef
Id="WixStandardBootstrapperApplication.HyperlinkLicense" >
<bal:WixStandardBootstrapperApplication
ThemeFile="Resources\HyperlinkTheme.xml"
LaunchTarget="[InstallFolder]My_Application.exe"
LocalizationFile="Resources\HyperlinkTheme.wxl"
SuppressRepair="yes"
SuppressOptionsUI="yes"
LicenseUrl=""
LogoFile="Resources/MyCoLogoWt64.png"
/>
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="NetFx40Redist"/>
<MsiPackage Id ="MyApp"
Vital="yes"
Name="My Application"
SourceFile="$(var.MyApp_Install.TargetDir)MyApp_Install.msi">
<MsiProperty Name="INSTALLLOCATION"
Value="[InstallFolder]" />
</MsiPackage>
</Chain>
</Bundle>
<Fragment>
<util:RegistrySearch
Variable="ThirdPartyCOMLibraryInstalled"
Result="exists"
Root="HKLM"
Key="SOFTWARE\Classes\ThirdPartyId.Server\CLSID"/>
</Fragment>
</Wix>

The root issue is that the RegistrySearch is in a separate Fragment that never gets referenced. Because nothing in the Fragment gets referenced the linker "optimizes away" the contents of the Fragment and the search is not included in your Bundle.
Aside: you could argue that the fact that there is a reference to the variable mentioned in the search in the Condition that the linker should be able to figure out that the search is necessary. However, that doesn't work out in all cases.
Fortunately, the solution is quite simple! You even have to choose from one of two:
Move the RegistrySearch element to the Bundle element.
Add a RegistrySearchRef element in the Bundle element to reference the RegistrySearch in the Fragment. You will also need to give the RegistrySearch and Id attribute.
Personally, I like option two and I would probably even move the Condition into the Fragment as well to group all that stuff together. Something akin to:
<Bundle ...>
<util:RegistrySearchRef Id='SearchForThirdParty' />
...
</Bundle>
<Fragment>
<util:RegistrySearch
Id='SearchForThirdParty'
Variable="ThirdPartyCOMLibraryInstalled"
Result="exists"
Root="HKLM"
Key="SOFTWARE\Classes\ThirdPartyId.Server\CLSID"/>
<bal:Condition Message="ThirdParty Application COM Library Required. Please (re)install ThirdParty Application and ensure 'Windows API' and '.Net Components' are installed.">ThirdPartyCOMLibraryInstalled</bal:Condition>
</Fragment>
</Wix>
That should do it.

Related

Denial of installation WIX Installer

I made a bootstrapper (bootstrapper is an installer that contains other installers to put all together, in this case will be my app and SQL Express database installer). When I start the bootstrapper, the SQL Express installation window is being displayed on the screen and if I close the window, my app is still set, and I need if user closes SQL Express installation window then my program won't be installed.
<?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">
<Bundle Name="Bootstrapper" Version="1.0.0.0" Manufacturer="MyCompany AboutUrl="https://mycompany.ru/"
Copyright="ol raits rezervit" UpgradeCode="1788BF21-18BD-49E8-A572-DD38F9B67A88">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense"/>
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Microsoft SQL Server"
Result="exists" Variable="SQLExpressInstalled_x64" Win64="yes"/>
<Chain>
<ExePackage SourceFile="SQL2019-SSEI-Expr.exe" DetectCondition="SQLExpressInstalled_x64" Permanent="no"></ExePackage>
<MsiPackage SourceFile="MyProgram.msi"></MsiPackage>
</Chain>
</Bundle>
</Wix>
Would adding "Vital" be a usable suggestion for you?
I have added this suggestion in your provided code example as the last argument for the ExePackage.
"Vital"
Specifies whether the package must succeed for the chain to continue. The default "yes" indicates that if the package fails then the chain will fail and rollback or stop. If "no" is specified then the chain will continue even if the package reports failure.
<?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">
<Bundle Name="Bootstrapper" Version="1.0.0.0" Manufacturer="MyCompany AboutUrl="https://mycompany.ru/ "Copyright="ol raits rezervit" UpgradeCode="1788BF21-18BD-49E8-A572-DD38F9B67A88">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense"/>
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Microsoft SQL Server"
Result="exists" Variable="SQLExpressInstalled_x64" Win64="yes"/>
<Chain>
<ExePackage SourceFile="SQL2019-SSEI-Expr.exe" DetectCondition="SQLExpressInstalled_x64" Permanent="no" Vital="yes"></ExePackage>
<MsiPackage SourceFile="MyProgram.msi"></MsiPackage>
</Chain>
</Bundle>
</Wix>
Ref - https://wixtoolset.org/documentation/manual/v3/xsd/wix/exepackage.html

Problem with Wix uninstall using CustomAction

I've created a very simple MSI which copies some files to the ProgramFiles directory and while installing calling to custom actions found in a binary written in C#.
While installing, I can easily call any custom action I want. For example I've created an installation step where the user should enter a license, and after confirming the license it is checked against a server using logic written inside C# custom action.
But, when uninstalling, every time I add a custom action (even if it does nothing but returning Success), I get error that the installation failed.
This is how I use the uninstalling step:
<InstallExecuteSequence>
<Custom Action='TestUninstallation' After='MsiUnpublishAssemblies'>REMOVE="ALL"</Custom>
</InstallExecuteSequence>
where TestUninstallation is defined as following:
<CustomAction Id="TestUninstallation" Return="check" Execute="deferred" Impersonate="no" BinaryKey="TestCustomAction" DllEntry="Uninstall" />
The property DllEntry equals Uninstall which is a C# method which only returns Success.
After installation is completed, I'm trying to uninstall and I'm getting the UserExit dialog defined inside the AdminUISequence with the property OnExit.
Any idea what am I missing?
Debugging: Managed code is relatively easy to debug (native code is actually even easier). Here are some pointers:
Debug C# Custom Actions (Advanced Installer)
Different debugging methods / aspects
Suggestions: I think you just have a broken reference to the dll export function - in other words an erroneous dll function name / reference:
<CustomAction Id="TestUninstallation" Return="check" Execute="deferred" Impersonate="no"
BinaryKey="CustomActions" DllEntry="__ERRONEOUS FUNCTION REFERENCE__" />
Just check what the dll actually exports and match like this:
<CustomAction Id="CustomAction1" BinaryKey="CustomActions" DllEntry="CustomAction1"/>
As always the real McCoy is the check of the dll itself to see if you have the right function name (the below screen shot from this prior answer, recommended read).
This is a native code C++ dll:
This is a DTF-packaged managed code dll:
Notice that this is a native dll with the managed code stuff embedded. It yields a very different functions list, but you still have to find the function name in there that you refer to.
This is a straight-up managed code dll (no native wrapping):
And finally: this is the straight-up managed code DLL without being wrapped in a native dll shell.
Un-Uninstallable Setup: When a custom action crashes or fails during uninstallation, you will have problems getting rid of the installation (it just rolls-back and you are stuck with it installed). There are several fixes or workarounds.
The overall fix - in my view - is to not fail custom actions on uninstall, or at least condition them so you can force an uninstall by setting a property via the command line:
Set in MSI property table: SUPPRESSERROR = 0. Then - when needed - on the command line set:
msiexec.exe /x {PRODUCT-GUID} SUPPRESSERROR="1"
Inside the MSI you condition the uninstall custom action with:
REMOVE="ALL" AND SUPPRESSERROR="0"
Now the custom action will not run if SUPPRESSERROR is anything but 0.
There is an older answer with several further options: I screwed up, how can I uninstall my program? (courtesy of Wim Coenen, with me messing up his answer with more suggestions).
Boilerplate: For quick use, let me just dump a boilerplate ad-hoc custom action test project here. This assumes a C# managed code custom action project called "CustomAction1" in the same Visual Studio solution and a reference added to it in your WiX source - like you already have obviously (this is for later when we have all forgotten what the problem was and need to test again):
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="WiXCustomActionsTesting" Language="1033" Version="1.0.0.0"
Manufacturer="test" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<UIRef Id="WixUI_Mondo" />
<Property Id="SUPPRESSERROR" Value="0" Secure="yes" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes" />
<Feature Id="ProductFeature" Title="WiXCustomActionsTesting" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<!--BEGIN CUSTOM ACTION SECTION-->
<Binary Id="CustomActions" SourceFile="$(var.CustomAction1.TargetDir)\$(var.CustomAction1.TargetName).CA.dll" />
<CustomAction Id="TestUninstallation" Return="check" Execute="deferred" Impersonate="no" BinaryKey="CustomActions" DllEntry="CustomAction1" />
<InstallUISequence></InstallUISequence>
<InstallExecuteSequence>
<Custom Action='TestUninstallation' After='InstallInitialize'></Custom>
</InstallExecuteSequence>
<!--END CUSTOM ACTION SECTION-->
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="WiXCustomActionsTesting" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component>
<File Source="C:\Projects\MySetup\MyApp.exe">
</File>
</Component>
</ComponentGroup>
</Fragment>
</Wix>
Create WiX project
Copy paste the code, set a new Upgrade GUID
Create CustomAction project, default name
Add reference to custom action project from wix project
Add reference to WiXUIExtension.dll
Adjust path to file in component
Compile

collision in wix extension: NetFxExtension

I am trying to create a bootstrapper project in Visual Studio 2015 using Wix.
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="..." Version="1.0.0.0" Manufacturer="..." UpgradeCode="...">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication LicenseFile="mtel-eula-free.rtf"/>
</BootstrapperApplicationRef>
<BootstrapperApplicationRef Id="WixBootstrapperApplication:WixNetFxExtension" />
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost">
<Payload
Name="BootstrapperCore.config"
SourceFile="$(var.TargetDir)\BootstrapperCore.config"/>
<Payload
SourceFile="$(var.TargetPath)"/>
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="NetFx45Web"/>
<MsiPackage Id="MTESetup" SourceFile="$(var.MTESetup.TargetPath)"/>
</Chain>
</Bundle>
</Wix>
The project name for the bootstrapper is MTEBootstrapper and the project name for the wix project for the MSI is MTESetup. For MTEBootstrapper, I added a reference to WixNetFxExtension.dll from Wix 3.10; In the properties of MTEBootstrapper, I added -ext WixNetFxExtension.dll. Now I am getting this error when I try to build MTEBootstrapper:
Error The extension 'Microsoft.Tools.WindowsInstallerXml.Extensions.NetFxExtension' contains a defintion for table 'NetFxNativeImage' that collides with a previously loaded table definition. Please remove one of the conflicting extensions or rename one of the tables to avoid the collision. MTEBootstrapper light.exe 0
I have no idea what is causing this. How do I fix it?
It looks like this error surfaces when I have both the reference to WixNetFxExtension added to MTEBootstrapper and the -ext option for the linker. I removed the -ext option for the linker and collision error disappeared.
(Separately I am getting an unresolved symbol WixNetFxExtension, which I will file a separate question for.)

WiX localization - Desktop/Program menu short cut not replaced in Upgrade

We have recently included localization support for simplified Chiense (zh-cn) in Windows Installer using WIX 3.5. The current version of our product is 1.3.0 and in old version (1.2.0) we do not have any localization support.
We have also changed the product code for 1.3.0 in order to perform major upgrade. And used MSI transform (using Wisubstg.vbs and Wilangid.vbs ) to integrate the localization support into single MSI without using Bootstrapper.
When we test this in Simplified Chinese build in upgrade mode the desktop and prpogram menu short cuts were not replaced but duplicated with Chinese text.
WiX Short cut code is here.
<Shortcut Id="StartServiceShortcut" Icon="StartServiceIcon"
Name="!(loc.STR_StartServiceName)"
Description="!(loc.STR_StartServiceDesc)"
Target="[INSTALLLOCATION]bin\myapp.exe" Arguments="-s"
WorkingDirectory="INSTALLLOCATION"/>
product.Wxl
<String Id="STR_StartServiceName">Start Service</String>
<String Id="STR_StartServiceDesc">Start Services</String>
Installed 1.2 build with Windows 7 English version
Changed the Regional settings to Simplified Chinese and then run the 1.3 Installer.
Seen the Windows Installer Wizard showiing the contents in simplified Chinese.
Installation was successful. But Desktop/Program menus are duplicated with new Chinese text.
Both shorcuts are working with out any issues. But uninstall did not remove both shourt cuts.
Uninstall product does not remove the short cuts. I have also seen that two entries in the Programs/Features list. Also seen there are two different registry entries. The product name and Publisher values are localized all other properties are same in these to Registry keys.
Where am I missing?
Thanks in Advance for any help!
Update:
After changing the upgrade language to '0', I am still getting the same issue. It seems like this new version 1.3 has been installed as totally a new product. Any help!
After changing the upgrade language to '0' I am still getting the same issue. It seems like this new version 1.3 has been installed as totally a new product. Any Help!
<Package InstallerVersion="300" Compressed="yes" InstallPrivileges="elevated" />
<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion Minimum="$(var.ProductVersion)"
IncludeMinimum="no"
OnlyDetect="yes"
Language="0"
Property="NEWPRODUCTFOUND" />
<UpgradeVersion Minimum="$(var.RTMProductVersion)"
IncludeMinimum="yes"
Maximum="$(var.ProductVersion)"
IncludeMaximum="no"
Language="0"
Property="UPGRADEFOUND" />
</Upgrade>
<Product Id="$(var.ProductID)" Name="!(loc.STR_ProductName)" Language="!loc.STR_Language)" Version="$(var.ProductVersion)" Manufacturer="!(loc.STR_Manufacturer)" UpgradeCode="$(var.UpgradeCode)" >
Finally I got it. Thanks to Alex Shevchuk's Blog From MSI to WiX, Part 8 - Major Upgrade
.
The FindRelatedProducts action runs through each record of the Upgrade table in sequence and compares the upgrade code, product version, and language in each row to products installed on the system.
So, After changing my code to something like below, upgrade was successful. Could be useful to others.
Any comments are welcome!
<Product Id="$(var.ProductID)"
Name="!(loc.STR_ProductName)"
Language="0"
Version="$(var.ProductVersion)"
Manufacturer="!(loc.STR_Manufacturer)"
UpgradeCode="$(var.UpgradeCode)">
<Package InstallerVersion="300" Compressed="yes" InstallPrivileges="elevated" Languages="0" Manufacturer="!(loc.STR_Manufacturer)" />
<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion Minimum="$(var.ProductVersion)"
IncludeMinimum="no"
OnlyDetect="yes"
Language="0"
Property="NEWPRODUCTFOUND" />
<!-- For UPGRADEFOUND Property, the Language attribute should be set to 1033 as previous version supports only English -->
<UpgradeVersion Minimum="$(var.RTMProductVersion)"
IncludeMinimum="yes"
Maximum="$(var.ProductVersion)"
IncludeMaximum="no"
Language="1033"
Property="UPGRADEFOUND" />
</Upgrade>

WIX 3 : Using HEAT for Visual Basic 6 COM Dlls

I am using WIX 3. I have used heat to create a wxs file for a VB6 dll. The msi creates without any errors, and the installation is successful as well.
All seems to be fine, and I can invoke the component successfully from a VB client.
However, if I invoke the component from an ASP page, I get 0x800401f3.
If instead of the installer, I use self registration (regsvr32), both work fine.
I did a registry difference to figure out what was the difference between self registration (regsvr32) and the installer, and I see the following
All entries in HKCR match - all well here
regsvr32 adds entries in HKLM, while the installer does not touch HKLM
I am wondering if this is the issue, or am I completely on a wrong track.
MSDN (http://msdn.microsoft.com/en-us/library/ms694355(VS.85).aspx) mentions that registry entries are required in HKLM, wondering what am I missing here.
Following is the file created by heat.
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<DirectoryRef Id="TARGETDIR">
<Directory Id="dirAD70B10292EAB7CAC7171859FBB23AA9" Name="vbdll" />
</DirectoryRef>
</Fragment>
<Fragment>
<DirectoryRef Id="dirAD70B10292EAB7CAC7171859FBB23AA9">
<Component Id="cmp9D818C62A6239E8B51E971A0048D0C05" Guid="PUT-GUID-HERE">
<File Id="filDD6F51EC5018EF4A9A312FFA6AC4257D" KeyPath="yes" Source="SourceDir\vbdll\act.dll">
<TypeLib Id="{80D8DA04-72C9-4D36-B269-57D989187ACF}" Description="act" HelpDirectory="dirAD70B10292EAB7CAC7171859FBB23AA9" Language="0" MajorVersion="1" MinorVersion="0">
<Class Id="{31BD65B6-9479-40EB-83C0-E717CD4793DD}" Context="InprocServer32" Description="act.def" ThreadingModel="apartment" Version="1.0" Programmable="yes">
<ProgId Id="act.def" Description="act.def" />
</Class>
<Interface Id="{C6D46026-CD7E-4AB0-B3B6-810FBF435BEF}" Name="def" ProxyStubClassId="{00020424-0000-0000-C000-000000000046}" ProxyStubClassId32="{00020424-0000-0000-C000-000000000046}" />
</TypeLib>
</File>
<RegistryValue Root="HKCR" Key="CLSID\{31BD65B6-9479-40EB-83C0-E717CD4793DD}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}" Value="" Type="string" Action="write" />
</Component>
</DirectoryRef>
</Fragment>
</Wix>
Update : Using the "SelfReg" option for the File makes the ASP client work as well. I read from other posts that this is not to be used. Can someone tell me what's to be done?
To get the installer to put entries under HKLM, the installation has to be marked as perMachine, the default seems to be perUser, as done below.
<Package InstallScope="perMachine" InstallerVersion="200" Languages="1033" Compressed="yes" SummaryCodepage="1252" />
Once this is done, the entries come in HKCR and also HKLM.
I hope somebody finds this useful, took me a good 6 hours..

Resources