Using WiX 3.7 and .NET 4.0.
How does one set burn variables when running a WiX bootstrapper EXE from the command line?
First of all, the burn variables that you wish to set need to be set as Overridable. To do this you must include the follow namespace in your WXS: xmlns:bal="http://schemas.microsoft.com/wix/BalExtension" and if you're using Visual Studio like me you need to include WixBalExtension.dll in your project references. Next you need to add the following attribute to all of the burn variables that you want to set via the command line: bal:Overridable="yes".
Now you can set the variables via the command line in this fashion:
BootstrapperSetup.exe /i /passive MyBurnVariable1=1 MyBurnVariable2=2
Below is an example of a WXS file that satifies all of the conditions described above:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="MyProduct" Version="1.0.0" Manufacturer="MyManufacturer" UpgradeCode="PUT-UPGRADE-CODE-HERE">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
<bal:WixStandardBootstrapperApplication LicenseUrl="MyLicense.htm" ThemeFile="MyThemeFile.xml" LocalizationFile="MyLocFile.wxl" />
</BootstrapperApplicationRef>
<Variable Name="MyBurnVariable1" bal:Overridable="yes" Type="numeric" Value="0" />
<Variable Name="MyBurnVariable2" bal:Overridable="yes" Type="numeric" Value="0" />
<Chain>
<MsiPackage Id="MyFirstMsiPackage"
SourceFile="first.msi"
InstallCondition="MyBurnVariable1 = 1" />
<MsiPackage Id="MySecondMsiPackage"
SourceFile="second.msi">
<MsiProperty Name="MY_PROPERTY" Value="[MyBurnVariable2]" />
</MsiPackage>
</Chain>
</Bundle>
</Wix>
Related
I am creating a Microsoft Installer (.msi file) using the Wixtoolset (Windows Installer XML). This installer must automate the installation of an existing .exe program (named installer.exe below) and copy a custom configuration file (named settings.conf below) to the target directory. In addition the installer must modify the configuration file using the InstallFiles command below. But the timing of events is critical. If the executable installer runs too early, it fails or exhibits strange behavior. And if the executable installer run too late in the install sequence, it overwrites my modified configuration file with the generic values. I believe this can be done by assigning a string to the Before or After property value. What Before or After property assignment will allow the executable to run properly but not overwrite the configuration file I moved by the CopyFile element? Here is my Wixtoolset XML code.
<Property Id="CONFIGFOLDER" Value="C:\acme\config" >
<Feature
Id="ConfigurationFile"
Title="Configuration File"
Level="1"
<ComponentRef Id="CMP_ACME_Config_File" />
</Feature>
<DirectoryRef Id="TARGETDIR">
<Component Id="CMP_ACME_Config_File" Guid="">
<File
Id="ACME_Config"
Source="MySettings.conf"
KeyPath="yes"
<CopyFile Id="Copy_ACME_Config"
DestinationProperty="CONFIGFOLDER"
DestinationName="settings.conf" />
</File>
</Component>
</DirectoryRef>
<Binary
Id="InstallerEXE"
SourceFile="installer.exe" />
<CustomAction
Id="Launch_Installer"
BinaryKey="InstallerEXE"
Impersonate="yes"
Execute="deferred"
ExeCommand=""
Return="check" />
<InstallExecuteSequence>
<Custom Action="Launch_Installer"
Before="InstallFiles">
</Custom>
</InstallExecuteSequence>
</Property>
I can't explain exactly why this works but assigning "InstallFiles" to the "After" property in the "Custom" element seems to do the trick.
<InstallExecuteSequence>
<Custom Action="Launch_Installer"
After="InstallFiles">
</Custom>
</InstallExecuteSequence>
I am using wix burn for my bootstrapper and every time I have upgrade to my application Crystal Reports runtime gets uninstalled. Can someone please help me fix this?
Bundle.wxs
<?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">
<?include Variables.wxi ?>
<Bundle Name="!(loc.BundleName)"
Version="$(var.Version)"
Manufacturer="!(loc.Manufacturer)"
HelpTelephone="!(loc.HelpPhone)"
Copyright="!(loc.Copyright)"
UpgradeCode="$(var.UpgradeCode)"
IconSourceFile="$(var.MainApplicationImagesFolder)\Car_Count_Report_Flat.ico" >
<!--SplashScreenSourceFile="$(var.MainApplicationImagesFolder)\BurnSplashScreen.bmp" >-->
<bal:Condition Message="This install requires Windows 7 Service Pack 1 or Higher">
((VersionNT >= v6.1) AND (ServicePackLevel >= 1) OR (VersionNT >= v6.3))
</bal:Condition>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<WixVariable Id="WixStdbaLicenseRtf" Value="$(var.EULAFolder)\EULA_en-US.rtf" />
<WixVariable Id="WixStdbaLogo" Value="$(var.MainApplicationImagesFolder)\car_counter_report_icon_64.png" />
<!-- Checks the Crystal Reports Registry Values -->
<!--<util:RegistrySearch Root="HKLM" Key="SOFTWARE\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Crystal Reports"
Value="CRRuntime64Version" Format="raw" Variable="CRRuntime64Version" Result="value" Win64="yes"/>-->
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Crystal Reports"
Value="CRRuntime32Version" Format="raw" Variable="CRRuntime32Version" Result="value"/>
<!-- Checks the Main Application Registry Values -->
<!--<util:RegistrySearch Root="HKLM" Key="Software\Saunders Creative Strategies\Kaady\Car Count Report"
Value="Version" Format="raw" Variable="x64Version" Result="value" Win64="yes"/>-->
<util:RegistrySearch Root="HKLM" Key="Software\Saunders Creative Strategies\Kaady\Car Count Report"
Value="Version" Format="raw" Variable="x86Version" Result="value"/>
<!-- Adds Local Variables -->
<Variable Name="CRRUNTIMEUPGRADE" bal:Overridable="yes" Type="numeric" Value="1" />
<Chain>
<!-- TODO: Define the list of chained packages. -->
<!-- <MsiPackage SourceFile="path\to\your.msi" /> -->
<PackageGroupRef Id="NetFx45Redist"/>
<PackageGroupRef Id ="CrystalReportsRuntime"/>
<PackageGroupRef Id="MainApplicationFile"/>
</Chain>
</Bundle>
</Wix>
InstallationFiles.wxs
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<?include Variables.wxi ?>
<Fragment>
<!-- Crystal Reports Runtime -->
<PackageGroup Id="CrystalReportsRuntime">
<!--<?if $(var.Platform) = x64 ?>--><!--
--><!--<MsiPackage Id ="CRRuntime64"
DownloadUrl="$(var.CRHttp)/$(var.CRx64Msi)"
SourceFile="$(var.3rdPartyApplicationFiles)\$(var.CRx64Msi)"
Name="$(var.CRx64Msi)"
Vital ="yes"
Compressed="no"
ForcePerMachine="yes"
InstallCondition="NOT CRRuntime64Version OR (CRRuntime64Version < "$(var.CRVersion)")" >
<MsiProperty Name="UPGRADE" Value="[CRRUNTIMEUPGRADE]" />
</MsiPackage>--><!--
--><!--<?else ?>-->
<MsiPackage Id ="CRRuntime32"
DownloadUrl="$(var.CRHttp)/$(var.CRx86Msi)"
SourceFile="$(var.3rdPartyApplicationFiles)\$(var.CRx86Msi)"
Name="$(var.CRx86Msi)"
Vital ="yes"
Compressed="no"
ForcePerMachine="yes"
Visible="yes"
Permanent="yes"
InstallCondition="NOT CRRuntime32Version AND (NOT (CRRuntime32Version = "$(var.CRVersion)"))" >
<MsiProperty Name="UPGRADE" Value="[CRRUNTIMEUPGRADE]" />
</MsiPackage>
<!--<?endif ?>-->
</PackageGroup>
<PackageGroup Id="MainApplicationFile">
<!--<MsiPackage Id="MainApplicationx64Msi" Vital="yes" Compressed="yes" ForcePerMachine="yes" Cache="yes"
Name="$(var.Mainx64Msi)"
InstallCondition="NOT x64Version OR (x64Version < "$(var.Version)")"
SourceFile="$(var.MainApplicationx64MsiFile)\$(var.Mainx64Msi)"/>-->
<MsiPackage Id="MainApplicationx86Msi" Vital="yes" Compressed="yes" ForcePerMachine="yes" Cache="yes"
Name="$(var.Mainx86Msi)"
Visible="no"
InstallCondition="NOT x86Version OR (x86Version < "$(var.Version)")"
SourceFile="$(var.MainApplicationx86MsiFile)\$(var.Mainx86Msi)"/>
</PackageGroup>
</Fragment>
</Wix>
Thank you
Shane
If you look at the install log in the user's temp directory, you would see that the upgrade bundle doesn't think it should install the CRRuntime32 because the InstallCondition is false. Burn uses the MSI's upgrade table to do the same logic that you're trying to do. If the Crystal Reports MSI is authored correctly, you should be able to just drop your install condition and let Burn decide whether it needs to be installed.
You should use DetectCondition instead of InstallCondition. The first answers: Is it installed?; The second: For a bundle installation, is it wanted?
The way you have it, burn removes CR when it is present during installation because the logic says it's not wanted.
I have found a couple of examples showing how to run a PowerShell script from WiX but have not been successful running either of them. So, I'd like to post what I have with the hope that someone can point out what I am doing wrong.
<!--Install the PowerShell script-->
<DirectoryRef Id="INSTALLFOLDER">
<Component Id="cmp_ShutdownIExplore" Guid="{4AFAACBC-97BB-416f-9946-68E2A795EA20}" KeyPath="yes">
<File Id="ShutdownIExplore" Name="ShutdownIExplore.ps1" Source="$(var.ProjectDir)Source\PowerShell\ShutdownIExplore.ps1" Vital="yes" />
</Component>
</DirectoryRef>
<!--Define the CustomAction for running the PowerShell script-->
<CustomAction Id="RunPowerShellScript" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="yes" />
<InstallExecuteSequence>
<!--Invoke PowerShell script -->
<Custom Action="RunPowerShellScript" After="InstallFiles"><![CDATA[NOT Installed]]></Custom>
</InstallExecuteSequence>
<!-- Define custom action to run a PowerShell script-->
<Fragment>
<!-- Ensure PowerShell is installed and obtain the PowerShell executable location -->
<Property Id="POWERSHELLEXE">
<RegistrySearch Id="POWERSHELLEXE"
Type="raw"
Root="HKLM"
Key="SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell"
Name="Path" />
</Property>
<Condition Message="This application requires Windows PowerShell.">
<![CDATA[Installed OR POWERSHELLEXE]]>
</Condition>
<!-- Define the PowerShell command invocation -->
<SetProperty Id="RunPowerShellScript"
Before ="InstallFiles"
Sequence="execute"
Value =""[POWERSHELLEXE]" -Version 2.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy Bypass -Command "& '[#ShutdownIExplore.ps1]' ; exit $$($Error.Count)"" />
</Fragment>
When I run the installer I have created I get the following error (from log):
MSI (s) (DC:F8) [11:21:46:424]: Executing op: ActionStart(Name=RunPowerShellScript,,)
Action 11:21:46: RunPowerShellScript.
MSI (s) (DC:F8) [11:21:46:425]: Executing op: CustomActionSchedule(Action=RunPowerShellScript,ActionType=1025,Source=BinaryData,Target=CAQuietExec,)
MSI (s) (DC:9C) [11:21:46:459]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI8228.tmp, Entrypoint: CAQuietExec
CAQuietExec: Error 0x80070057: failed to get command line data
CAQuietExec: Error 0x80070057: failed to get Command Line
CustomAction RunPowerShellScript returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 11:21:46: InstallFinalize. Return value 3.
I am not at all clear what this error is trying to say. Are my internal references bad? Is the command to execute the script bad? Something else?
Any help is most appreciated and thanks in advance.
Looks like you have scheduled the CAQuietExec action as deferred. In this case you have to pass the command line to be executed via a CustomActionData property called QtExecDeferred which is written to the execution script. The deferred action can then access the property from the script.
More details at http://wixtoolset.org/documentation/manual/v3/customactions/qtexec.html
I didn't understand Stephen's answer, however I eventually got it working with the help of this blog post.
Here's a summary of the change I made to Greg's code to get it to work:
I changed CAQuietExec to WixQuietExec (I'm not sure if this was necessary).
In SetProperty I changed the value of the Before attribute from InstallFiles to the Id of the custom action; in Greg's case it would be RunPowerShellScript.
Although unrelated to the question, I ended up needing to change the -Version of powershell to 3.0 from 2.0 to prevent an error when running my script.
Here was my actual working code:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:iis="http://schemas.microsoft.com/wix/IIsExtension" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Product Id="*" Name="..." Language="1033" Version="..." Manufacturer="..." UpgradeCode="...">
<Property Id="POWERSHELLEXE">
<RegistrySearch Id="POWERSHELLEXE"
Type="raw"
Root="HKLM"
Key="SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell"
Name="Path" />
</Property>
<Condition Message="This application requires Windows PowerShell.">
<![CDATA[Installed OR POWERSHELLEXE]]>
</Condition>
<SetProperty Id="InstallMongoDB"
Before ="InstallMongoDB"
Sequence="execute"
Value=""[POWERSHELLEXE]" -Version 3.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy Bypass -Command "& '[#MONGODB_INSTALL.PS1]' ; exit $$($Error.Count)"" />
<CustomAction Id="InstallMongoDB" BinaryKey="WixCA" DllEntry="WixQuietExec" Execute="deferred" Return="check" Impersonate="yes" />
<InstallExecuteSequence>
<Custom Action="InstallMongoDB" Before="InstallFinalize"><![CDATA[NOT Installed]]></Custom>
</InstallExecuteSequence>
<Component Id="MONGODB_INSTALL.PS1" Guid="..." DiskId="1">
<File Id="MONGODB_INSTALL.PS1" Name="mongodb-install.ps1" Source="mongodb-install.ps1"/>
</Component>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="APPLICATIONFOLDER" Name="...">
<Directory Id="InstallScripts" Name="InstallScripts">
<Component Id="MONGODB_INSTALL.PS1" Guid="..." DiskId="1">
<File Id="MONGODB_INSTALL.PS1" Name="mongodb-install.ps1" Source="mongodb-install.ps1"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
</Fragment>
</Wix>
Only the following example helped me
https://github.com/damienbod/WiXPowerShellExample/blob/master/SetupWithPowerShellScripts/Product.wxs
you need to add smth similar into your 'Product.wxs'. the 'Value' property of the first 'CustomAction' contains a ps script (create and run a windows service in my case).
<!-- assign the string (ps command) to RegisterPowerShellProperty -->
<CustomAction Id="RegisterWindowsService"
Property="RegisterPowerShellProperty"
Value=""C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NonInteractive -InputFormat None -NoProfile sc.exe create MyService binpath= 'C:\Program Files (x86)\My service\MyService.exe';sc.exe start MyService"
Execute="immediate" />
<!-- Deferred execution of the above script -->
<CustomAction Id="RegisterPowerShellProperty"
BinaryKey="WixCA"
DllEntry="CAQuietExec64"
Execute="deferred"
Return="check"
Impersonate="no" />
<InstallExecuteSequence>
<!-- On installation we register and start a windows service -->
<Custom Action="RegisterWindowsService" After="CostFinalize">NOT Installed</Custom>
<Custom Action="RegisterPowerShellProperty" After="InstallFiles">NOT Installed</Custom>
</InstallExecuteSequence>
you will need to add a reference to 'WixUtilExtension' in order to run the script.
I' deploying a Word Add in using WiX, regarding x84 target Platforms (at least the Office installation has to be x86, never the less which OS Platform is used) everything is working well, my COM Interop registration of the Word Add In works and the add in auto-starts the first time I start word afer I installed the Add In.
I'm doing following registration stuff to the registry (cut from output of heat.exe)
I've created an intermediate file, helping me out for the COM Interop registration using this heat command:
"C:\Program Files\Windows Installer XML v3.5\bin\heat.exe" file MyAddin.dll -ag -template fragment -out MyAddin.wxs
The output of interesst looks like: (I know using RegistryValue this way has been deprecated)
<Class Id="{10BC65F1-32C0-3ED4-98A0-17661A8C4455}" Context="InprocServer32" Description="MyAddin.MyAddinClass" ThreadingModel="both" ForeignServer="mscoree.dll">
<ProgId Id="MyAddin.MyAddinClass" Description="MyAddin.MyAddinClass" />
</Class>
<File Id="filCC4172BEC1312562EDEF49648E45AE0D" KeyPath="yes" Source="..\MyAddin\bin\Debug\MyAddin.dll" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}" Value="" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="Class" Value="MyAddin.MyAddinClass" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="Assembly" Value="MyAddin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="RuntimeVersion" Value="v4.0.30319" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="CodeBase" Value="file:///[#filCC4172BEC1312562EDEF49648E45AE0D]" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="Class" Value="MyAddin.MyAddinClass" Type="string"Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="Assembly" Value="MyAddin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="RuntimeVersion" Value="v4.0.30319" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="CodeBase" Value="file:///[#filCC4172BEC1312562EDEF49648E45AE0D]" Type="string" Action="write" />
The component including this stuff has the Win64Flag tag set to yes. Therefore I thought things will be written to the x64 part of the registry. Until this, i read following article about registry reflection telling this:
For example, the 32-bit InprocServer32 key is not relevant for 64-bit applications, so the InprocServer32 key is not reflected to the 64-bit registry view.
Furthermore:
However, 64-bit applications can use the 32-bit LocalServer32 key and the LocalServer32 key gets reflected.
But I already tried to use LocalServer32 instead of InprocServer32, but doing this, won't let my add in start on both platforms.
Will I have to use a call to RegAsm Tool or I'm missing a some tag or Interop registration option for x64 Platforms? Can anybody help?
With wix you need to do two things to disable registry reflection:
Mark your component as 64 bit component (attribute Win64="yes") (as you did)
Build your package as 64 bit package (Platform = x64)
This package won't be usable on x86 systems. So you will need two packages, one for x86 and one for x64. You can use the same source file for both packages as the Win64 attribute is ignored by the x86 package.
If I want to create the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyApp
with the string value
EventMessageFile : C:\Path\To\File.dll
how do I define this in my WiX 3.0 WXS file? Examples of what the XML should look like is much appreciated.
You seem to want to create an event log source. If that is the case, you should take a look at the <EventSource> element in the util extension.
Check out this page. An example would be:
<registry action="write"
root"HKLM" key="SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyApp"
type="string" value="EventMessageFile : C:\Path\To\File.dll" />
I went with this:
<Component Id="EventLogRegKeys" Guid="{my guid}">
<RegistryKey Id="Registry_EventLog" Root="HKLM" Key="SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyApp" Action="create">
<RegistryValue Id="Registry_EventLog_EventSourceDll" Action="write" KeyPath="yes" Name="EventMessageFile" Type="string" Value="C:\Path\To\File.dll" />
</RegistryKey>
</Component>
It would be better to refer to File.dll using file reference syntax, to ensure that the actual path it's installed to is used. Use [#filekey], where filekey is the Id of the File element describing the file.
Use the following under DirectoryRef --> Directory...
<Component Id="RegisterAddReferencesTab32" Guid="D9D01248-8F19-45FC-B807-093CD6765A60"> <RegistryValue Action="write" Id="RegInstallDir32" Key="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyApp" Root="HKLM" Type="string" Value="C:\Path\To\File.dll" /></Component>