I'm new to WiX and inherited several WiX projects from a previous employee. There is a 'Full' installer that bundles several .msi packages for installation. The Full installer consists of a project with a Bundle.wxs file and another project with a .xaml UI screen and a bootstrapper class. The UI simply lets the user performing the install choose which components to install.
I'm seeing a really odd issue where if I kick off one of the components and then cancel out of the .msi installation process for that component previous versions of the .xaml UI screen display. I end up having to close out several of these UI screens before I get back to the one I kicked off for my install. The behavior differs on our different test servers and it seems like there are old installers cached on the servers or something. The .xaml UI screens that pop up after trying to cancel include fields that are not part of my current .xaml UI.
Related
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!
Currently I have made custom UI botstrapper and have embedded three exes into it.
when i cancel installation after successfully installing one exe , the bootstrapper is not rolling back.Instead it will stop the process and user machine is installed with some components of bundle packages.
Can anyone suggest to roll back whole process so that user machine will be in default stage ie without any components of bundle package when i cancel installation.
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.
I created an installer based upon the code I found here. If a previous version of the app exists, I want the installer to delete it before installing the new one.
If it's a clean install, everything goes well.
If it's an upgrade, a weird thing happens. As expected, the old version is removed, the registry is changed, and shortcuts are placed on the desktop. Oddly, the primary file doesn't exist in the application folder when the installer completes.
Upon launch after an upgrade, a small installer message box pops up and states "Please wait while Windows configures -app name-..". After this quick message, the file exists as it should in the app folder, and the app launches.
Prior to launch though, it's not there. I even tried a reboot before launching the app to see if that would place the file if it's stuck in a some kind of cache.
Anyone ever see this behavior? It's a bit like this questiom, but it happens on every upgrade.
Oddly, the primary file doesn't exist in the application folder when the installer completes.
This is a common problem with windows installer upgrades if components are not managed correctly. You'll typically see that the missing file re-appears if you launch the installer into maintenance mode from the control panel and do a "repair". In this case, windows repaired the application automatically when you launched it.
A few possible explanations of the top of my head:
the new version of your installer installs this file in a component with a new GUID. This causes problems because Component GUIDs should remain stable.
your installer installs multiple files per component. This causes problems because whether a component should be installed is determined by the keypath, and only one file can be the keypath. Stick to one file per component.
The "new version" of the file actually has a lower version number. Such an "upgrade" doesn't work correctly.
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.