Wix SqlDatabase creation of 2014 LocalDb Error - wix

I have a Wix Toolset project that needs to install a database into an existing install of SqlServer 2014 LocalDb and I've not been successful at all. I've searched extensively on SO as well as other sites for examples or suggestions that might be applicable. So far, I've found nothing that works in my project.
SqlServer Local DB was already installed on the system and can be access from SQL Mgmt Studio. All of the system databases appear as expected and I'm able to create a new database in Mgmt Studio.
The text file that I include as a test does install correctly in the expected folder.
The error that I am receiving varies depending on which options I define within the SqlDatabase element.
From the installer log:
Action 11:46:34: CreateFolders. Creating folders
CreateFolders: Folder: C:\Check\Database\
CreateFolders: Folder: C:\Check\Database\
Action 11:46:34: InstallFiles. Copying new files
InstallFiles: File: TestFile.txt, Directory: C:\Check\Database\, Size: 19
Action 11:46:34: CreateDatabase. Creating Databases
CreateDatabase: Error 0x80004005: failed to create SQL database but continuing error: unknown error, Database: Check
Action 11:46:51: RegisterProduct. Registering product
The wxs file for this installation:
<?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:sql='http://schemas.microsoft.com/wix/SqlExtension'>
<Product Id="*" Name="Ach Check Database Installation" Language="1033" Version="1.0.0.0" Manufacturer="ACH Solutions" UpgradeCode="3828eaf7-528f-4006-9169-27bed44e79fe">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes"/>
<Feature Id="CheckDb" Title="Check Database" Description="The Check Database" ConfigurableDirectory="INSTALLDIR" Level="1">
<ComponentGroupRef Id="DatabaseComponents" />
</Feature>
<UIRef Id="WixUI_Mondo" />
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="INSTALLDIR" Name="CheckDir" >
<Directory Id="DatabaseFolder" Name="Database" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="DatabaseComponents" Directory="DatabaseFolder">
<Component Id='SqlComponent' Guid='53234257-65F1-4D58-B2CA-90308EC102FF'>
<CreateFolder />
<File Id="file_TestFile.txt" Source="E:\TestFile.txt"/>
</Component>
<Component Id="sql_SqlDatabase" Guid="B4D9CB63-B740-4860-89B6-1209D9A1A18E">
<CreateFolder/>
<sql:SqlDatabase Id='SqlDatabase'
Database='Check'
CreateOnInstall='yes'
Server='localhost\(localdb)\MsSqlLocalDb'
DropOnUninstall='no'
ContinueOnError='yes'>
<sql:SqlFileSpec Id='sql_CheckDatabase' Filename='CheckDatabase.mdb' Name='CheckDatabase' Size='30MB' />
<sql:SqlLogFileSpec Id='sql_CheckDatabase_Log' Filename='CheckDatabase_Log.ldb' Name='CheckDatabaseLog' Size='3MB' />
</sql:SqlDatabase>
</Component>
</ComponentGroup>
</Fragment>
</Wix>
Has anyone run into this problem or something similar before? What was the solution?
I welcome any suggestions that might assist in this.
Thanks,
Eugene

I believe the Server attribute should be just '(localdb)\MsSqlLocalDb'.
Also make sure the LocalDB instance exists by the time you run the installer and that it's shared with the user under which the installer is running.
For testing purposes you can also try to use named pipe instead of server name. To get the name of the instance's pipe run the following command in the command line:
sqllocaldb info MsSqlLocalDb

WiX doesn't support localdb connections.
https://github.com/wixtoolset/issues/issues/4957
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/b5c9a1fa-75fc-41f2-a5d3-4b2b6ed4ebde/localdb-problem-unable-to-connection-via-localdbv110-but-can-via-named-paipes
Someone would have to update dutil to use the latest SQL Server Native Client and it seems in 7 years no one has.
The alternative is to write your own custom actions for SQL processing. I have some that I can provide if you email me a request.

Related

Simple Default Wix MSIX Project Throws a FgExcludeDarwinFeatures Error On Build

I'm testing out the MSIX features of the WiX framework. When I attempt to build I receive the following error:
light.exe(0,0): error LGHT0221: The definition for the
'FgExcludeDarwinFeatures' table's 'Feature_' column is a foreign key
relationship to the 'Feature' table's column number 1. The
modularization types of the two column definitions differ: one is
Column and the other is None. Change one of the modularization types
so that they match.
My setup:
Followed installation instructions from: https://www.firegiant.com/wix/wep-documentation/getting-started
Created a default wix setup project in visual studio 2019. Included FgMsixExtension.wixext.dll, included the fgmsix.xsd property on Wix element.
I'm running toolset v3.11.2.4516 (latest). Expansion Pack v3.11.476 - 2020-12-22 (latest)
Project compiles fine without the MSIX line, and the inclusion of the FgMsixExtension.wixext
Any ideas what I am missing?
Also does anyone have a working WiX msix example I can also compare to?
Just in case it is needed, here is a very quick edit of the default setup project from a wix template:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:fga="http://www.firegiant.com/schemas/v3/wxs/fgmsix.xsd">
<Product Id="*" Name="SetupProject3" Language="1033" Version="1.0.0.0" Manufacturer="test1" UpgradeCode="77c4b832-ed73-4ba2-825c-7eee7837a8f4">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<fga:Msix Id="testy" Publisher="CN=test1" Target="desktop" />
<!--<fga:Application Id="MyApp" ExecutableFile="prodFile" />-->
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<Media Id="1" Cabinet="test.cab" EmbedCab="yes" />
<Feature Id="ProductFeature" Title="SetupProject3" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SetupProject3" />
</Directory>
</Directory>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent">
<File Id="prodFile" Source="C:\Program Files (x86)\WiX Toolset v3.11\bin\FireGiant.LicensingTool.exe" />
</Component>
</ComponentGroup>
</Product>
</Wix>
Just finished a conversation with FireGiant Support. This was due to a bug:
The dev team published the fix in v3.11.479. This should solve the issue you faced.
Let us know if you have any other questions or problems.
Happy packaging!
-- FireGiant Support
v3.11.479 released 01/15/2021

How to avoid having two versions of a product installed with Windows Installer / MSI?

I have written and am maintaining a number of Wix installation source files which I use to build MSI files for distribution of my application.
I have not explicitly programmed for any kind of upgrading, updating, reinstallation or anything of the kind -- there is a single feature that consists of a number of components with stable GUIDs and I have observed that at least a clean installation does what I expect it to.
However, I (and anyone in possession of the MSI files I distribute) may seemingly install distinct versions of my application side-by-side using their respective (distinct) MSI files. Which isn't a problem in itself, except that I obviously use the same folder as installation target -- "%ProgramFiles(x86)%\Foobar" -- to install the application (version regardless) in. Meaning that in effect there is always ever one version that ends up being installed.
I would argue that Windows Installer behaves correctly in so far that it updates files from whichever MSI package it installed last. One interesting side-effect of this is that if the last MSI was of earlier version, the files in the application folders would be overwritten with the copies from that earlier version.
But none of that seems to be the actual problem to me. I want to fix the disparity between what is actually installed (a single application version) and what Windows tracks as installed -- in my case two records of two distinct application versions.
Since I install the application in a folder that doesn't depend on the version being installed, tracking multiple application versions by Windows is a mistake.
So I guess my question is, how do I fix this so that only one version is shown (reflecting reality) or what's the idiomatic approach in these kind of cases? I deliberately did not overspecify my Wix source code, hoping in return that Windows Installer would use some built-in intelligence to figure everything out on its own. But I may need to add some explicit upgrade or uninstall-previous-version-first instructions, I suppose.
My minified Wix source code (file "foobar.wxs") would look like this:
<?xml version="1.0" encoding="utf-8" ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Product Name="Foobar" Manufacturer="ACME Inc." Id="*" UpgradeCode="ae9a7d6d-6c2d-446a-97d9-9dbe829d2ea8" Language="1033" Codepage="1252" Version="!(wix.PRODUCT_VERSION)">
<Package Id="*" Languages="1033" SummaryCodepage="1252" Compressed="yes" InstallerVersion="200" />
<Icon Id="foobar" SourceFile="!(wix.APPPATH)/foobar.ico" />
<Property Id="ARPPRODUCTICON" Value="foobar" />
<Property Id="ARPCOMMENTS" Value="Gives you full foobar powers" />
<MediaTemplate EmbedCab="yes" CompressionLevel="high" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="DesktopFolder" />
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLDIR" Name="Foobar" FileSource="!(wix.APPPATH)">
<Component>
<File Id="foobar.exe" Name="foobar.exe" />
</Component>
<!-- There are other components like above (assets) -->
</Directory>
</Directory>
<Directory Id="ProgramMenuFolder">
<Directory Id="foobar_menu" Name="Foobar">
<Component Id="foobar_shortcut" Guid="e80a6b95-a145-453a-b327-65a977e741fe">
<Shortcut Icon="foobar" Id="foobar_shortcut" Name="Foobar" Target="[foobar]foobar.exe" />
<Shortcut Directory="DesktopFolder" Icon="foobar" Id="foobar_desktop_shortcut" Name="Foobar" Target="[foobar]foobar.exe" />
<RegistryValue KeyPath="yes" Root="HKMU" Key="Software\[Manufacturer]\[ProductName]" Type="string" Value="" />
<RemoveFolder Id="remove_foobar_menu" On="uninstall" />
</Component>
</Directory>
</Directory>
<Directory Id="CommonAppDataFolder">
<Directory Id="app_data_foobar" Name="foobar">
<Component Guid="" Id="app_data_config_folder">
<CreateFolder />
</Component>
<Component Guid="" Id="app_data_config_folder_log_file">
<File Name="foobar.log" Source="foobar.log.template">
<!-- Add write access permission to the log file to members of "Users" group. -->
<!-- PermissionEx Sddl="D:AR(A;;GWGR;;;BU)" / -->
<!-- Bug with Windows Installer, can't use PermissionEx/MsiLockPermissionsEx table. See https://stackoverflow.com/questions/55145282/how-to-include-inherited-permissions-when-specifying-permissions-for-a-file-inst -->
<util:PermissionEx Append="yes" GenericWrite="yes" User="Users" />
</File>
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="foobar">
<ComponentGroupRef Id="foobar" />
<ComponentRef Id="foobar_shortcut" />
<ComponentRef Id="app_data_config_folder" />
<ComponentRef Id="app_data_config_folder_log_file" />
</Feature>
</Product>
</Wix>
I am compiling the object file with the following Windows Command Prompt line:
candle.exe -ext WixUtilExtension -out %TEMP% foobar.wxs
And then generating the MSI file with:
light.exe -ext WixUtilExtension -spdb "-dAPPPATH=%apppath%" "-dPRODUCT_VERSION=%version%" -out %TEMP%\foobar-%version%.msi %TEMP%\foobar.wixobj
(using Wix 3.11.1.2318)
Upgrade Code: As long as you have set an upgrade code (which identifies a bunch of related products) you can use a major upgrade element to indicate products that are to be uninstalled as part of a new MSI's installation.
MajorUpgrade Element: Just inject a MajorUpgrade element for default treatment of major upgrades into your existing WiX source. It is a sort of "magic element" doing a lot for you making a number of (usually good) assumptions. There are older and more flexible ways to do it - if you need more detailed control (for legacy purposes usually - auto-magic does not cover all bases):
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
The above is the standard use for all WiX files created in Visual Studio.
Note: I will try to tune up this answer shortly with more links, but give that a go first?
First link: Using Visual Studio to make WiX files. The Hello WiX and Visual Studio-type of scenario.
Major Upgrade Suggested Reading: A few things to know about major upgrades. All WiX markup essentially revolves around the compiled MSI's Upgrade table. It is there that major upgrade logic is configured. Custom actions could also affect things, and a few other things such as launch conditions perhaps.
WiX Documentation: How To: Implement a Major Upgrade In Your Installer
Major Upgrade - Common Problems: WIX does not uninstall older version
Major Upgrade - Manual Configuration: Adding entries to MSI UpgradeTable to remove related products (using old-style Upgrade elements)
Further:
Major Upgrades - How-To & Concept: Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs

Unable to uninstall program from WiX created MSI

After installing osquery with an MSI made with WiXToolSet (Using the script provided by osquery), I tried uninstalling it which failed.
Also it didn't show as a program in the appwiz.
(Link to the script - https://github.com/osquery/osquery/blob/master/tools/deployment/make_windows_package.ps1)
I've tried using both the MSI itself - osquery.msi /uninstall and the unsintall string - msiexec /I{'uninstallstring'}.
I also tried repairing using the /fv option.
The code the script used with WiX to create the MSI:
#'
<?xml version='1.0' encoding='windows-1252'?>
<?define OsqueryVersion = 'OSQUERY_VERSION'?>
<?define OsqueryUpgradeCode = 'ea6c7327-461e-4033-847c-acdf2b85dede'?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Product
Name='osquery'
Manufacturer='Facebook'
'#
$wix += "`n Id='$(New-Guid)'`n"
$wix +=
#'
UpgradeCode='$(var.OsqueryUpgradeCode)'
Language='1033'
Codepage='1252'
Version='$(var.OsqueryVersion)'>
<Package Id='*'
Keywords='Installer'
Description='osquery standalone installer'
Comments='Facebooks opensource host intrusion detection agent'
Manufacturer='Facebook'
InstallerVersion='200'
Platform='x64'
Languages='1033'
Compressed='yes'
SummaryCodepage='1252' />
<MediaTemplate EmbedCab="yes" />
<MajorUpgrade
DowngradeErrorMessage="A later version of osquery is already installed. Setup will now exit." />
<Condition Message='A newer version of osquery is already installed.'>
NOT NEWERVERSIONDETECTED
</Condition>
<Condition Message="You need to be an administrator to install this product.">
Privileged
</Condition>
<Property Id='SOURCEDIRECTORY' Value='packs'/>
<PropertyRef Id="WIX_ACCOUNT_LOCALSYSTEM" />
<PropertyRef Id="WIX_ACCOUNT_USERS" />
<PropertyRef Id="WIX_ACCOUNT_ADMINISTRATORS" />
<Directory Id='TARGETDIR' Name='SourceDir'>
<Directory Id='ProgramFiles64Folder'>
<Directory Id='INSTALLFOLDER' Name='osquery'>
<Directory Id='DaemonFolder' Name='osqueryd'>
<Component Id='osqueryd'
Guid='41c9910d-bded-45dc-8f82-3cd00a24fa2f'>
<CreateFolder>
<Permission User="[WIX_ACCOUNT_USERS]" Read="yes"
ReadExtendedAttributes="yes" Traverse="yes"
ReadAttributes="yes" ReadPermission="yes" Synchronize="yes"
GenericWrite="no" WriteAttributes="no"/>
<Permission User="[WIX_ACCOUNT_ADMINISTRATORS]" GenericAll="yes"/>
<Permission User="[WIX_ACCOUNT_LOCALSYSTEM]" GenericAll="yes"/>
</CreateFolder>
<File Id='osqueryd'
Name='osqueryd.exe'
Source='OSQUERY_DAEMON_PATH'
KeyPath='yes'/>
<ServiceInstall Id='osqueryd'
Name='osqueryd'
Account='NT AUTHORITY\SYSTEM'
Arguments='--flagfile="C:\Program Files\osquery\osquery.flags"'
Start='auto'
Type='ownProcess'
Vital='yes'
ErrorControl='normal'/>
<ServiceControl Id='osqueryd'
Name='osqueryd'
Stop='both'
Start='install'
Remove='uninstall'
Wait='no'/>
</Component>
</Directory>
<Component Id='osqueryi' Guid='6a49524e-52b0-4e99-876f-ec50c0082a04'>
<File Id='osqueryi'
Name='osqueryi.exe'
Source='OSQUERY_SHELL_PATH'
KeyPath='yes'/>
</Component>
<Component Id='extras' Guid='3f435561-8fe7-4725-975a-95930c44d063'>
<File Id='osquery.conf'
Name='osquery.conf'
Source='OSQUERY_CONF_PATH'
KeyPath='yes'/>
<File Id='osquery.flags'
Name='osquery.flags'
Source='OSQUERY_FLAGS_PATH'/>
<File Id='osquery.man'
Name='osquery.man'
Source='OSQUERY_MAN_PATH'/>
<File Id='osquery_utils.ps1'
Name='osquery_utils.ps1'
Source='OSQUERY_UTILS_PATH'/>
<File Id='manage_osqueryd.ps1'
Name='manage-osqueryd.ps1'
Source='OSQUERY_MGMT_PATH'/>
'#
When trying to use the MSI to uninstall I saw the following message :
This patch package could not be opened. Verify that the patch package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer patch package
When trying to use the uninstall string I see this message:
This action is only valid for products that are currently installed
Upgrade Code Retrieval: How can I find the Upgrade Code for an
installed MSI file? (if you want to test the below with another package family, find upgrade code via methods described here).
Debugging: To find the product code (provided it is actually defined), maybe try to run this code:
Set installer = CreateObject("WindowsInstaller.Installer")
Set upgrades = installer.RelatedProducts("ea6c7327-461e-4033-847c-acdf2b85dede")
For Each u In upgrades
MsgBox u, vbOKOnly, "Product Code: "
Next
Procedure: 1) copy & paste the script into notepad, 2) save as ANSI file: "Find Related Products.vbs" on desktop, 3) double click script file to run. Make a note of the product codes shown by the message boxes (if any). Hit CTRL + C to copy content of the actual VBScript dialog.
Uninstall: From the cmd.exe using the product code you found by running the script above:
msiexec.exe /x {Product-Code}
Alternative: Browse through %SystemRoot%\Installer manually if you can't get the above to work, and follow the advice in section 4 here. Locate the right MSI, right click and go "Uninstall".
Links:
Powershell: Uninstall application by UpgradeCode

WiX Bootstrapper

I am trying to create an installer for a simple .NET WPF C# app. I am using VS 2013, and WiX 3.10.2. Following the steps in the Wix Tutotial/ .NET/ Bootstrapping I have created a Boostrap.exe which chains .NET web installer and the app Setup.msi.
EDIT: My goal is to understand how to configure the WiX Bootstrap and Setup projects for small updates, minor upgrades, and major upgrades scenarios.
Out of the box, everything seems to work nice when I run a fresh install. However, when I run a fresh built Bootstrap.exe over an already existing installation a duplicate entry appears in the Apps & features and no file is changed in the app target location - contrary to the expectation that the same entry should remain in the Apps & features and the target location should be updated. EDIT: Looks like there may not be a way to change REINSTALLMODE?
If I add a Product Id and then change the version of the Setup (minor upgrade), the Bootstrap fails with User cancelled installation? The log file shows "Error 0x80070642: Failed to perform minor upgrade of MSI package." EDIT: Inside the MSI log a SecureRepair fails with error code 39439E438 (?) probably because the stored hash value does not match the current... but that should be expected in a minor upgrade MSI, right?
Are there recommended configurations between the Boostrapper and Setup WiX projects such that the small update, minor upgrade, and major upgrade use cases can be handled properly, or does the WiX Bootstrapper support ONLY major upgrades?
I will continue to investigate and I'll post updates to my findings;
Any hints are greatly appreciated,
Thanks!
Here are the source files which I barely changed from the WiX wizard generated code:
--- Product.wxs ---
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="SetupProject1 1.0.0.0" Language="1033" Version="1.0.0.0" Manufacturer="Acme" UpgradeCode="4c8a8cbf-e3d0-410c-8a8d-7e67eb4e7ff7">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perUser" InstallPrivileges="limited" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="SetupProject1" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="LocalAppDataFolder">
<Directory Id="AcmeFolder" Name="Acme">
<Directory Id="INSTALLFOLDER" Name="WpfApplication1" />
</Directory>
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="ProductComponent" Guid="8CA0B70F-39DA-4B4B-9104-46C58E26FCF4">
<CreateFolder/>
<RemoveFolder Id="RemoveAcmeFolder" Directory="AcmeFolder" On="uninstall"/>
<RemoveFolder Id="RemoveINSTALLFOLDER" On="uninstall" />
<RegistryValue Root="HKCU" Key="Software\Acme\WpfApplication1" Name="Version" Type="string" Value="[ProductVersion]" KeyPath="yes" />
<File Source="$(var.WpfApplication1.TargetPath)" KeyPath="no" />
</Component>
</ComponentGroup>
</Fragment>
--- Bundle.wxs ---
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="Bootstrapper1 1.0.0.0" Version="1.0.0.0" Manufacturer="Acme" UpgradeCode="e1092cbb-9134-42fc-a9f2-652f95f361fd">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage Name="Acme Setup" SourceFile="$(var.SetupProject1.TargetPath)" Vital="yes" />
</Chain>
</Bundle>
If you change your executables, increase their version numbers. Windows Installer assumes files with the same versions are the same.
To upgrade an .msi package, increase its version number either as part of a major upgrade (typical) or minor upgrade.
To upgrade a bundle, increase its version number. By default, Burn keeps bundles with the same version installed.

WiX retrieve path from registry confusion

I am trying to create a WiX installer for a plugin of one of my applications but have come across something I find strange; perhaps it is the expected behavior but then I would like to know why.
My application saves its installation path in the following registry location:
HKEY_CURRENT_USER\SOFTWARE\MyCompany\MyApp\Installed
As default my application is installed to C:\Program Files\MyApp if x64 and C:\Program Files (x86)\MyApp if x86.
In my plugin installer I have the following in Product.wxs to retrieve the install path of my application:
<Property Id="MY_APP_DIR">
<RegistrySearch Id='my_app_dir' Type='raw' Root='HKCU' Key='SOFTWARE\MyCompany\MyApp' Name='Installed' />
</Property>
I then added the following just to see what is actually retrieved when I run the installer:
<Condition Message="[MY_APP_DIR]">
0
</Condition>
In the case where "C:\Program Files\MyApp\" is stored in the registry I got the following when I run the plugin installer:
Plugin installer (x86): C:\Program Files (x86)\MyApp\
Plugin installer (x64): C:\Program Files\MyApp\
Why is not the value stored in the registry retrieved independently of which platform the msi was built for?
On a x64 machine only the x64 versions of my installers will be used so this should not cause any problems it just confuses me.
EDIT: As requested I have included my entire Product.wxs:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="TestInstaller" Language="1033" Version="1.0.0.0" Manufacturer="MyCompany" UpgradeCode="SOME_GUID">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes" />
<Property Id="MY_APP_DIR">
<RegistrySearch Id="my_app_dir" Root="HKCU" Key="SOFTWARE\MyCompany\MyApp" Name="Installed" Type="raw" />
</Property>
<Condition Message="[MY_APP_DIR]">
0
</Condition>
<Feature Id="ProductFeature" Title="TestInstaller" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="INSTALLFOLDER" Name="TestInstaller">
<Directory Id="MY_APP_DIR" Name="MyAppInstallPath">
<Directory Id="MyAppBinFolder" Name="bin" />
</Directory>
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents">
<Component Id="ProductComponent" Guid="SOME_GUID" Directory="MyAppBinFolder">
<File Id="Foo.Bar" Source="Foo.Bar" KeyPath="yes" />
</Component>
</ComponentGroup>
</Fragment>
</Wix>
Windows Installer has a rule called WIN64DUALFOLDERS which does not allow 32 bit installers to write to 64 bit locations. If you run your 32 bit installer on a 64 bit computer with diagnostic logging enabled you should see a section in the log file like this:
AppSearch: Property: MY_APP_DIR, Signature: my_app_dir
MSI (c) (BC:F4) [10:00:47:953]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (c) (BC:F4) [10:00:47:953]: WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in 'C:\Program Files\MyCompany\MyApp' folder path. (mask argument = 0, the folder pair's iSwapAttrib member = 0).
MSI (c) (BC:F4) [10:00:47:953]: PROPERTY CHANGE: Adding MY_APP_DIR property. Its value is 'C:\Program Files (x86)\MyCompany\MyApp'.
Action ended 10:00:47: AppSearch. Return value 1.
Even though the path in the registry is C:\Program Files\, Windows Installer automatically redirects it to C:\Program Files (x86)\.
For more information see Disable WIN64DUALFOLDERS substitution in WIX.
Note: I deleted my previous answer because with the benefit of hindsight it wasn't useful.