I read and run sample from here.
Some questions:
How I can get actions names during the install/uninstall/remove process?
How I can pass variables and parameters to embedded MSI?
Is any way to get additional information from the embedded MSI (product version, company name etc) as it is done in WixSharp (WpfSetup sample)?
4. How I can get (set) from MSI file INSTALLFOLDER, TARGETDIR and other values?
I'm not sure you can or not. Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplication will tell you what msi package it is planning or executing, you may also be able to get information about which install action it is executing, check the events that get raised by this during your install process.
2.
In your bootstapper WPF app
//ba is an instance of BootstrapperApplication
this.ba.Engine.StringVariables["ServerInstallLoc"] = "YOUR DATA"
Bundle.wxs
<!-- Install paths provided by the managed bootstrapper interface -->
<Variable Name="ServerInstallLoc" bal:Overridable="yes" Type="string" Value=""></Variable>
And later reference this variable
<MsiPackage Id="MyInstaller" SourceFile="$(var.MyInstallerMsiProjectName.TargetPath)" Compressed="yes" DisplayInternalUI="no">
<!-- Pass wix bundle variable to MSI property -->
<MsiProperty Name="SERVER_INSTALL_OVERRIDE" Value="[ServerInstallLoc]"/>
</MsiPackage>
In your bootstrapper, you can reference properties of the bundled installers. the syntax is: !(bind.packageVersion.PackageName) assuming one of your <MsiPackage> elements is called PackageName. Binder variables reference
For question 4 look at this:
http://www.wrightfully.com/allowing-the-user-to-select-the-install-folder/
You can also look at the Wix managed bootstrapper as I believe it does this as well. You can download the source code here:
https://github.com/wixtoolset/wix3
Related
In my Managed Bootstrapper Application I want to give the user the option to select which packages to install. Therefore I want to set a variable and pass it to the Wix Bootstrapper.
My approach was to do it similar like it is possible with the installfolder (described here) and check the value with the InstallCondition of the MsiPackage.
<Chain>
<MsiPackage ...
InstallCondition="[VariableName] = 1"
...>
</MsiPackage>
</Chain>
<Variable Name="VariableName" Type="numeric" Value="1"/>
Is this the right approach? If yes, has someone an example that works? If no, what is the best way to achieve that goal?
In our managed bootstrapper we provide the user UI to make a selection of the package they want to install.
Then this information from the model is propagated and handled in the OnPlanPackageBegin and OnPlanPackageComplete.
The package request state can be set to handle this.
I have a merge module which searches for some registry locations to read values and save to Properties. Here is the code segment:
<Fragment Id="RegSearch">
<Property Id="HOST_APP_PATH" >
<RegistrySearch Id="HOST_App"
Root="HKLM"
Key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\HOST.exe"
Name="Path"
Type="raw"
/>
</Property>
<Property Id="HOST_ROOT_PATH" >
<RegistrySearch Id="HOST_Root"
Root="HKLM"
Key="SOFTWARE\HostApplication\Installation Info"
Name="HOST_Root"
Type="raw"
/>
</Property>
Windows Installer puts this search in AppSearch custom action.
Problem: AppSearch executes this search very early, before WriteRegistryValues of Host Installer, it won't get any values and properties with this search won't be defined, because registry to search was never written there.
Question 1: Can we reschedule this registry search from merge module after WriteRegistryValues of Host Installer?
Question 2: Is there any other way to search registry after Host Installer executes WriteRegistryValues? Probably with some custom action?
AppSearch is a standard action provided by the windows installer and by design is intended to run very early. This is because it's frequently used by the LaunchConditions standard action to decide if an installation can continue or not. It's also useful for deciding whether features and components should be installed.
MSI is a very opinionated framework. I suspect that there is something wrong with your current design that is going to be incompatible with MSI.
Is host installer the same MSI or a different MSI? Assuming it's the same, why couldn't you just put your data in some MSI properties and use those properties to write to the registry? Then you wouldn't need to read the values back in because you'd already have them in properties.
What do you need these properties for after writing them to the registry? Usually writing them to the registry would be the end game. I'm not sure what else you are doing next.
If host.msi is a different MSI, why are you having one MSI install another MSI? That's not MSI design. In this case you would need a bootstrapper. Host MSI would run first then this MSI. But even then it's kinda strange that a second MSI would depend on properties set by a first MSI. I'd think the bootstrapper UI and Application would gather this information and pass it as secure custom public properties to both MSIs.
To answer question 1: No a merge module can only insert actions into the sequence. It can't reschedule actions. 2: You would have to use a custom action. But as I said above, this feels like the wrong path to me.
I've got following problem: With WiX 3.7 I have built an installer which creates several localized MSI files, for example:
..\bin\x86\Release\en-us\myProject.msi
..\bin\x86\Release\fr-fr\myProject.msi
..\bin\x86\Release\de-de\myProject.msi
Furthermore, I created a Burn bootstrapper project which should ensure that .NET 4.5 is installed:
...
<Chain>
<PackageGroupRef Id="NetFx45Web"/>
<MsiPackage SourceFile="$(var.myProject.TargetPath)"></MsiPackage>
</Chain>
...
Now I have expected that the Burn bootstrapper project creates:
..\bin\x86\Release\en-us\myProject.exe
..\bin\x86\Release\fr-fr\myProject.exe
..\bin\x86\Release\de-de\myProject.exe
but MsiPackage expects a single file.
Is it generally possible to make the Burn project work as I expect?
If this is not the case, is it possible to get to know how the exact name of the created MSI file? I can not hard code the MSI file name, because the output name can vary.
I don't think that this is possible... If you are using MSBuild or something similar you can build it as you're building your MSI packages.
Or you can use a simple script which will call candle.exe with parameter -dYOUR_VARIABLE=myProject.msi.
See Working with MSBuild for more information.
I have written a managed wix bootstrapper using WPF. The actual installation steps requires chaining of multiple msi's/exe's and batch files.
<Chain>
<MsiPackage SourceFile="xxx"/>
<ExePackage Id="Test" SourceFile="..\TestBatch.bat" Vital="yes"/>
<MsiPackage SourceFile="yyy"/>
</Chain>
During the execution of each package, a message should be displayed (preferably from the bootstrapper UI) indicating which msi/exe package/ batch file is being executed currently.
In short, a ProgressText is needed in the bootstrapper How can I make this happen?
Another question: I do not want all the msi's to be packaged into the bootstrapper exe. This is because: Each time an msi is changed we would like to ship only the updated/modified msi and not the entire bootstrapper exe. Is there a way to do this?
Two answers, one suggestion:
To get messages back during the MsiPackages being installed, handle the BootstrapperCore.ExecuteMsiMessage event. The event args there will contain a Message that contains the data you are looking for.
To configure how the packages are compressed or not, use the Compress attribute. You can either mark the entire Bundle/#Compress='no' or mark each package Compress='no' (or 'yes' if you want to go that way).
--
Suggestion: Be sure to add DetectCondition to the ExePackages so Burn will know if the ExePackages are already present or not.
I am using WiX Burn to make my installer, i am bundling one exe and one msi.
And the exe needs an properties file at the time of install.
Is there a way to copy the file using burn, i tried Payload but it is not working.
Can i know the location throguh any Bundle variable where my file is copied.
Thanks
Ravi S
Make sure you are specifying the properties file as the payload for the exe and not for the bootstrapper. For example, in your bundle, your chain may look something like this:
<Chain>
<MsiPackage SourceFile="MyInstaller.msi" Id="MyInstaller" Cache="yes"/>
<ExePackage SourceFile="MyExe.exe" Id="MyExe" Cache="yes">
<Payload SourceFile="OtherFile.properties" Id="Properties"/>
</ExePackage>
</Chain>
Also, as a sanity check, which version of WiX are you using? If you are using an older build (such as RC0), you could try updating to the latest weekly build.
Update:
In WiX 3.6 it does not appear that you can get the absolute path of a payload file. There are two bugs/feature request open right now regarding the issue that are deferred to WiX 3.7:
Add burn variable to cache path - ID: 3557446
Change working folder to the cache folder - ID: 3538846
One workaround would be to use burn to write your own bootstrapper application and then programmatically determine the working directory and set the appropriate parameters, but that would be a lot of work for this one issue.