Sadly, the Windows Installer doesn’t support that. Some process outside your package (a bootstrapper/chainer?) will have to manage the upgrade from per-user to per-machine.
Per the docs on DoAction ControlEvent, MsiProcessMessage (the API behind session.Log) cannot be used from a ControlEvent. This prevents your message from showing up in the log. If you need to log some information from a ControlEvent (especially for debugging), your best bet is a hack like changing a property’s value to contain your desired … Read more
This is what I have, hope it helps: <?define ServerInstall=”SomeCondition” ?> <?define InstanceName = “YOUR_INSTANCE” ?> <?define SqlWebLink = http://download.microsoft.com/download/5/2/9/529FEF7B-2EFB-439E-A2D1-A1533227CD69/SQLEXPR_x86_ENU.exe ?> <Variable Name=”SqlVariable” Type=”string” Value=”/SAPWD=some_password” Hidden=”yes” /> <!– Read SQL Server keys to find current instance and version –> <util:RegistrySearch Id=”SqlInstanceKeyFound” Root=”HKLM” Key=”SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL” Value=”$(var.InstanceName)” Result=”exists” Variable=”SqlInstanceKeyFound” /> <util:RegistrySearch Id=”SqlInstanceKey” Root=”HKLM” Key=”SOFTWARE\Microsoft\Microsoft SQL … Read more
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers. We also have a dedicated build machine which runs Cruise Control. Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks. To deploy to development, the code is … Read more
After doing more digging, it looks like my previous experience is a result of behavior specific to VSDPROJ’s (and possibly InstallShield), wheras WiX is conforming to the Windows Installer. As I discovered at this link, TARGETDIR is actually supposed to represent the root of the drive with the most free space available (assuming there’s more … Read more
The Isaiah4110 answer is not the best way if you don´t need a UI. The simplest way to execute the exe file target you are installing through the MSI file produced by Wix is with a custom action type 18 (identifying the action by FileKey), here you are a complete example: <Fragment> <ComponentGroup Id=”ProductComponents” Directory=”INSTALLFOLDER”> … Read more
Product/@Id=”*” randomly generates a new GUID, which is sufficient for product codes. Component/@Guid=”*” calculates a GUID that stays the same as long as your target path stays the same, which is necessary to comply with component rules.
<Target Name=”UsesFrameworkSdk”> <GetFrameworkSdkPath> <Output TaskParameter=”Path” PropertyName=”FrameworkSdkPath” /> </GetFrameworkSdkPath> <PropertyGroup> <Win8SDK>$(registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0@InstallationFolder)</Win8SDK> </PropertyGroup> </Target> <Target Name=”UsesSignTool” DependsOnTargets=”UsesFrameworkSdk”> <PropertyGroup> <SignToolPath Condition=”(‘@(SignToolPath)’==”) and Exists(‘$(FrameworkSdkPath)bin\signtool.exe’)”>$(FrameworkSdkPath)bin\signtool.exe</SignToolPath> <SignToolPath Condition=”(‘@(SignToolPath)’==”) and Exists(‘$(Win8SDK)\bin\x86\signtool.exe’)”>$(Win8SDK)\bin\x86\signtool.exe</SignToolPath> </PropertyGroup> </Target> <Target Name=”SignBundleEngine” DependsOnTargets=”UsesSignTool”> <Exec Command=”"$(SignToolPath)" sign /d "App Setup" /t http://timestamp.digicert.com /a "@(SignBundleEngine)"” /> </Target> <Target Name=”SignBundle” DependsOnTargets=”UsesSignTool”> <Exec Command=”"$(SignToolPath)" sign /d "App Setup" /t http://timestamp.digicert.com /a "@(SignBundle)"” … Read more
Debugging Results: Following a lot of debugging (by original poster – OP) this turned out to be a known MSI issue described here: https://wix-users.narkive.com/EMfQPDrM/a-bug-get-reg-sz-when-using-type-integer. Nice search work. What is in a DWORD? (a REG_SZ apparently): Essentially MSI “converts” a DWORD value found via a RegistrySearch operation to a formatted string – REG_SZ – during upgrade … Read more
Ignoring the debug strings, it’s easier to see that the buffer handling is incorrect. I would suggest also outputting the return values from MsiGetPropertyA() and the value in dwValue to confirm, but here’s what I think is happening (comments refer to dwValue): char szBuff[1024]; DWORD dwValue = 0; MsiGetPropertyA(hInstall, “UPGRADINGPRODUCTCODE”, szBuff, &dwValue); // passes 0, … Read more