My build system creates a MSI using Wix, it then uses WIX to bundle that into another EXE that acts as a bootstrapper. The bootstrapper makes sure all the dependencies are installed (.NET and so forth).
I would like to change some properties inside the MSI depending on who downloads it. I won't know the settings until long after the build is complete.
I am able to do that with the MSI by editing the properties DB. However when I try the same technique with the bundle, it (WIX interop libarary) says it can't open the file.
So, how can I do one of these things:
Edit a property inside the WIX bundle EXE (that I can then pass to the bundled package)
Extract and re-insert the bundled MSI
You can pass properties using commandline to wix bundle. The bundle then can pass the property to MSI.
WiX Bootstrapper: How do I set burn variables from the command line?
Pass parameters from bootstrapper to msi bundle package
The other solution I can think of: If you write your own custom bootstrapper, you'll have access to IBootstrapperEngine::SetVariable, and you can do whatever you want with that, including setting properties that MSI can read. https://wixwpf.codeplex.com/ should be pretty easy.
If you are asking if there is such tool like orca.exe for Wix burn, then I would say no.
Potential options:
Generate wix burn installer on the fly (including compilation)
Split up executable: set the Compressed attribute to "no". You'll have access to *.msi then.
Related
I am trying to find any information how the Windows installer cache is working for Wix Bootstrappers.
For MSIs you do not follow any special rules to be sure a MSI will be cached by Windows. For Bootstrappers (Burns) it looks the same, but I had several issues trying to uninstall the package without original installer.
For me several points are not clear:
how to uninstall a product without original .exe installer?
will .exe installer be cached by default during installation?
does custom user interface affects Windows caching rules for .exe installers?
If you go into your registry and find "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall", you should be able to find a registry key corresponding to your installer package. There should be one for the bundle itself and one for each .msi installed as part of the bundle. If you find the correct key for the bundle, it will have a value called "UninstallString". This is the string you should use to manually uninstall the package via the command line.
For your second point, Windows automatically caches installed burn bundles. The same registry key you found in the step above will have another value called "BundleCachePath", which should point you to the location of the cached .exe file. This should be under "C:\ProgramData\PackageCache{GUID}", where {GUID} is the package GUID of the bundle.
I can't see why having a custom UI would change the caching location, unless you manually add a dialogue to do so.
Copying of license files using Wix 3.10.2? We have a requirement where we need copy some license files after the installation of the webapplication to IIS. Copying of license files will be the last in the sequence. The license files will reside next to the burn (bootstrapper) setup.exe. This way we can control what license file need to be installed based on the user. I am trying to understand if there will be an issue with number of license files reside along with .exe? Is there a custom action to pick files that are not part of the msi or exe?
1) There will not be an issue with number of license files residing along with exe
2) Using the Media element without a Cabinet name you can specify that certain files will neither be inside a cab or embedded into the msi, no custom action needed. See http://wixtoolset.org/documentation/manual/v3/xsd/wix/media.html
You may need to be more precise about exactly when you want the copy to occur. Your original question says "after the installation" which implies that the install has finished and that your generated MSI is no longer running. but in a later comment you say "during the install".
If after the install is what you want, then you could add a custom executable to your Burn bundle that will do whatever you want. In many of these kinds of situations the application that needs the file just goes and gets it with help from the MSI saying where it was installed from, or by using the SourceList capabilities of Windows Installer to get the location.
If you want to copy files during the install then the CopyFile element is probably what you need. It has wildcard capability to define the files you want to copy. Your source location will be the SourceDir property and the destination will be one of your defined directories. Note that the files will not be uninstalled when the product is uninstalled.
WiX Copyfile:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
I had to use native bootstrap that comes with Visual Studio SDK. With the bootstrap you can also create pre-requisite like installing .net. This worked for my requirement. Also there is a msbuild task so that you can automate it. Used setup project to create msi and VS bootstrap to create setup.exe
I'm a bit confused about how wix burn and the main installer are expected to interact with each other. I'm new to wix and windows installer technology in general.
Based on the examples I've seen I was under the impression the burn application would install prereqs then switch to the main installer. However I've seen comments from searches that when using the burn application the main installer becomes secondary and the burn UI should be used instead. This is reinforced by the behavior of the burn application. What I mean is the burn application has it's own license agreement, ARP entry, hides the main installer by default, and has it's own change/repair entry.
This has me confused because the burn application is lacking a lot of functionality the main installer has through MSI. Some functionality I would consider essential such as feature selection, directory selection, and changing features. But this is absent from the burn application.
I feel if I used the burn application as the primary I'd have to recreate the UI, while if I used the main installer for prereqs (if possible) I'd have to recreate the functionality burn provides. Neither approach is desired, so I am wondering how other users of wix handle large projects. Is it standard to write your own custom burn UI? Any help that might clear up this confusion would be greatly appreciated.
Common practice would be to use the Wix bootstrapper (burn) specifically for installing software that is necessary to run your main application, first and automatically.
You would indeed use the main MSI produced by Wix to install your main application. You would use one of the UI (dialog set) sequences already available in Wix. The dialog set will be applicable only for the main MSI, because again, the bootstrapper's main responsibility is to install pre-requisite software for your application to be able to run.
The whole installation process involving your application MSI in conjunction with the bootstrapper executable would be as follows:
Pre-installation
You would build your application MSI.
You would make sure your MSI is specified in your bootstrapper .wxs file.
You would build a Wix bootstrapper executable file which, if correctly set, would
include your appplication MSI.
Installation
You simply run the bootstrapper executable file.
All pre-requisite software will be installed first.
Your main application MSI will now be executed. The user will now be able to set e.q. the installation directory of your application through the dialog sequence of your main MSI (including the other points you've mentioned, if the correct dialog sequence set has been selected before building).
Hope this helps to clear out things a little bit!
Is there a reason that the bootstrapper is an exe as opposed to an MSI? And, is there a way to instead generate a MSI?
I need to have multiple localizations of the bootstrapper and would like to apply transforms like can be done for a WiX MSI. And, since the bootstrapper uses the same localization files it'd be nice to be able to use the same approach for the bootstrapper as for an installer.
Many of the things being bootstrapped are MSI based, and you can't really run an MSI from within an MSI install. Bootstrappers are typically executables that contain one or more embedded MSI files - the executable checks if the prerequisite is installed or not, and if not launches the appropriate MSI installs, patches, whatever else is in there.
I have a hand-crafted MSBuild script that build my WiX based installer. The installer contains a custom action DLL as a <Binary> element. MSBuild thinks the MSI is still up to date when this DLL changes, although it rebuilds correctly when I change other files that are part of components. Is there some way to tell the Light task to look at additional dependencies?
Thanks.
Create a ProjectReference from your .wixproj to your custom action project and MSBuild will correctly detect the dependency and should cause the installer project to build again. Additionally, WiX v3.6+ has improved the rebuild checks so ensure you are using a new version of the WiX toolset as well. If you still see problems it could be a bug in the WiX toolset that would be great to fix.