I am trying to create a custom UI for WiX and Burn.
I'm almost done except one thing. In the end of installation which is upgrading(for exaple 1.0.0 to 1.1.0) uninstall for the previous version starts and the UI of it shows.
My question is how should I handle this so the user doesn't see uninstall UI in the end.
When performing an upgrade of a Burn-based installer, the process will upgrade each of the MSIs bundled inside the installer, then it will uninstall the previous version's bundle using the commandline arguments -uninstall -quiet -burn.related.upgrade -burn.embedded (and a bunch of other stuff). If you're writing a your custom UI in .NET, that will present itself in the WiX BootstrapperApplication base class with these property values:
Command.Action property as LaunchAction.Uninstall
Command.Display property of None or Embedded
When the Command.Display is set to None or Embedded, your custom UI will need to hide itself (ie: don't display a UI). My guess is that you're currently not hiding the UI in this scenario, which is why it's displaying during the upgrade.
Related
I need to add the Change button to my WiX (burn) Bootstrapper, so that it invoked the change action from the MSI that it's wrapping:
What markup do I need for that?
In WiX v3.x, you have to set the DisplayInternalUI attribute to yes to show the MSI UI. But the only time that the bundle can show the MSI's internal UI is during Install. The engine is hardcoded to force any other operation (modify, repair, uninstall, etc) to run silently. You'll have to write your own custom BootstrapperApplication in v3.x if you want the bundle to be able to modify an MSI, and the BA will have to have its own UI to do so.
In v4 (which isn't released yet), you can use wixstdba to show the MSI's internal UI for all operations but there isn't currently support for a Change button like you're asking for. It only supports Repair and Uninstall like in v3.x. No one has asked for that yet, so you might want to create a feature request at https://github.com/wixtoolset/issues/issues. Otherwise, you'd have to create a BAFunctions.dll to customize wixstdba.
The general recommendation for bundles is to use separate MSI's for different features instead of one MSI with all of the features.
I'm struggling with my Custom Bootstrapper Upgrade issue. By following this thread, I'm using LaunchAction.Install.
This does Upgrade the Product as well as Boostrapper, but older Bootstrapper remains there, as shown in following screen shot.
If I invoke ver 1.0.0.0 from here, it would display Dialog to Install, but would do nothing. However, invoking ver 1.0.1.0 would give me the option to Uninstall the product. However, upon Uninstall, it would only remove itself, and "My Product" is left behind.
I also tried with
_bootstrapper.Engine.Plan(LaunchAction.UpdateReplace);
and
_bootstrapper.Engine.Plan(LaunchAction.UpdateReplaceEmbedded);
but it has no effect.
Question: How to upgrade older installation without falling in above situation? Can anyone please provide a working example of CustomBA upgrade?
Regards
Check the PlanRelatedBundle event. Its where you can tell the Engine what to do with the old bundles.
If you want a Bundle to replace the old one the UpgradeCode should be the same for both. In this case it will uninstall the old bundle as default.
Also the old bundle needs to support quiet uninstallation since it will be called with the argument /quit after installing the new one.
You can check it in the BootstrapperApplication.Command.Display property. It should be "Embedded" if its called from another Bundle. The BootstrapperApplication.Command.Action is set to "Uninstall" in this case.
If nothing of this works check the logs that are created in the AppData\Temp folder.
I also experienced this problem. I had to write my own managed bootstrap application. I had a bug where I was kicking off the Plan() phase before the Detect() phase finished.
Hence the old bundle was not uninstalling as it should have.
It is good practice to implement a handler for every event that the Bootstrapper offers. Write a log entry in every handler listing out the arguments supplied to the handler. It makes chasing down errors a lot easier.
In my case I was migrating from InstallShield 2009 to WiX 3.10 and I had to write my own managed bootstrapper because I had to conditionally install SQL Server express based on user inputs from a fancy WPF boostrapper.
I maintain two flavors of an application. Only one should be installed on each machine.
Let's say that I got application A installed on a machine. Now the user wants to install application B. The installer should replace A and install B.
Is it possible to tell the windows installer via WIX to silently replace another application?
You can actually do this via the same mechanism that supports a major upgrade. Give each MSI a unique UpgradeCode. Then add an Upgrade element that detects the other MSIs UpgradeCode. Then add an UpgradeVersion element that will detect the other MSIs version correctly (could be the version number). You can use the Property attribute from the UpgradeVersion element to display special UI or otherwise condition stuff in your MSI to say, "Hey, I detected the other application".
I would suggest using the WiX bootstrapper functionality called Burn. You can create a bootstrapper (setup.exe) containing the logic for what packages need installed/removed.
I have already made a MSI installer with WiX using a custom WPF UI with the EmbeddedUI element. It is similar to the sample found in src/DTF/Samples/EmbeddedUI.
I would now like to have a bootstrapper that checks if .NET 4 is installed and install it if it's not, and then launch my MSI.
It looks like Burn would override my WPF EmbeddedUI in order to chain the .NET 4 and MSI installations into a single installation with a single progress bar. I know that I could have a managed application to change the UI of Burn then pass parameters to my MSI but the problem is that I would like my UI to be in WPF which relies on .NET, and if the whole bootstrapper relies on .NET then the user couldn't even open the bootstrapper if he doesn't have it installed in the first place.
What I would like is the bootstrapper to install .NET if needed with a simple UI like Wixstdba, and then launch my MSI as it is, with its own WPF EmbeddedUI, without chaining it with the .NET installation. I don't mind that both installations would have their own progress bar, I would just like to be able to use my WPF EmbeddedUI for the installation of the main application.
Would that be possible. How? Thanks!
If you want your WiX bootstrapper to display the UI of your installer, set the DisplayInternalUI attrible of the MsiPackage to true. That solution does have the downside of displaying two UIs during install though.
You can also create a managed bootstrapper application using WPF and .NET. Burn provides a way to basically bootstrap itself and install .NET before displaying your custom UI.
I have been using InstallShield LE in Visual Studio 2010, but it is heavily limited and sometimes buggy. I looked at paid InstallShield versions, but these also have too many limitations for that price tag.
So I decided to switch to WiX. I have had some experience with it some years ago. It was pretty easy to build a simple installer using SharpDevelop with WiX tools.
Now I am trying to collect solutions and tools for WiX. Basically, I need to get the following functionality (requested by my client):
when I launch the installer, it should check a text file on the server and see if a newer version is available. If it's the case, then the installer should be able to download the updated installer package and launch it (are there any downloader utilities in WiX?)
solving dependencies. Major dependency of my app is .NET 4 (which itself depends on Windows Installer 3). The installer should offer the user to download and install them automatically
logging the installation process, also collecting the log file of the dependencies' installation process. I don't want the user to hunt various .log files in case .NET4 or WindowsInstaller3 installation fails. All the information should be collected in one place and if something fails, I should show the user a custom popup dialog with an option to save the complete install log file and send it to me
installer should be able to detect if there is a newer version of my app already installed, and show a meaningful customized error message before it exits
installer should be able to detect if there is an older version of my app already installed. and offer the user to exit installation or uninstall the previous version and install the new version. BTW, there are no minor component upgrades planned, I prefer to reinstall everything fresh (I guess, this is a major upgrade in the terms of WindowsInstaller). Installshield LE failed on me for this, it just showed an error box with the message about another product, but did not offer to uninstall it
in case of an upgrade, installer should be able to detect if some of application components are in use (running application processes) and show a custom error message and not just some cryptic "Installation failed"
I have read that it may be a bit painful to manage upgrades even if I keep my UpgradeCode intact, because this code is stored in the Windows Registry in a compressed way and also if the user renames the downloaded file, it might get detected as a completely new product by WindowsInstaller ... or maybe this is only the case with WindowsInstaller .msi files and WiX has some trick to avoid this issue?
About update downloading - I need this functionality also in my application itself. I am not sure how to implement it efficiently, so I can reuse the same update downloader code/utility in both WiX installer and in my app.
Is it possible to satisfy all these requirements using currently existing WiX tools, or maybe I'll need to code some components from scratch?
WiX is definitely the way to go in my opinion.
when I launch the installer, it should check a text file on the server and see if a newer version is available. If it's the case,
then the installer should be able to download the updated installer
package and launch it (are there any downloader utilities in WiX?)
In my opinion, this type of functionality is best handled by the application. However you can implement such functionality in a custom bootstrapper. The latest development of WiX includes a bootstrapper engine Burn that allows you to write your own custom bootstrapper on top of it.
solving dependencies. Major dependency of my app is .NET 4 (which itself depends on Windows Installer 3). The installer should offer
the user to download and install them automatically
You can use the standard WiX bootstrapper to install .NET as a prereq. Or if you create your own custom managed bootstrapper application, you can install .NET a prereq to your bootstrapper as in this example
logging the installation process, also collecting the log file of the dependencies' installation process. I don't want the user to
hunt various .log files in case .NET4 or WindowsInstaller3
installation fails. All the information should be collected in one
place and if something fails, I should show the user a custom popup
dialog with an option to save the complete install log file and send
it to me
Using the two bootstrapping methods above, when you launch your msi you can specify parameters for logging. In my own custom managed bootstrapper I created a button to open the log files created during installation.
installer should be able to detect if there is a newer version of my app already installed, and show a meaningful customized error
message before it exits
You can do this using launch conditions
installer should be able to detect if there is an older version of my app already installed. and offer the user to exit installation or
uninstall the previous version and install the new version. BTW,
there are no minor component upgrades planned, I prefer to reinstall
everything fresh (I guess, this is a major upgrade in the terms of
WindowsInstaller). Installshield LE failed on me for this, it just
showed an error box with the message about another product, but did
not offer to uninstall it
In my experience this major upgrades are the least complicated
approach.
in case of an upgrade, installer should be able to detect if some of
application components are in use (running application processes) and
show a custom error message and not just some cryptic "Installation
failed"
I think WiX/Windows Installer are generally good at handling these
scenarios and automatically notifying the user that
files/applications need shutdown without you having to author
anything extra in your installer.
All that said, you may want to look into creating your own custom managed bootstrapper using WiX and Burn. That is not trivial however. The best place to go is to download the source code to the WiX Weekly Releases and checkout the project src\Setup\WixBA. It is the custom BA that they wrote to install WiX. There isn't much documentation out there yet because WiX 3.6 is not released (although it is pretty stable). However you don't have to create your own BA to make a solid WiX installer that can handle upgrades and logging.