I am working with WIX 3.6, it has some great features to create managed bootstrapper application. I have managed to create a WPF ui for that. But, I dont want to create and handle all the events for the installer, our requirement is only to get an initial parameter like language selection from the user and proceed to the MSI. MSI already handles upgrade / uninstall and install checks.
Bootstrapper.Engine.Plan(LaunchAction.Install);
Is it possible to just launch the MSI without specifying the install / uninstall action codes?
Thanks!
Unfortunately, not today. The interface provided today is very powerful and you can control just about everything. That also means that you need to control a lot to get the core scenarios working. As we progress in the WiX toolset, we'll build up additional abstraction layers so that a custom BA is easier to write. The Burn functionality is still rather new and just needs time to have more code contributed.
If you want to look on the bright side, be glad that you'll be able to accomplish just about any required UI task because the interface provided is so expressive. :)
Related
If you add ActionData to the Subscribe event in Edit Control on Wix,
the line is written and erased. I want the ActionData log to continue to be written as a scroll.
Burn: WiX Burn allows you to write your own GUI to run your installer. You should be able to implement whatever you want in terms of GUI if you go down that path. However: installers run quicker and quicker as IO becomes better, are you sure this is time well spent? I'd say just use logging and be done with it? See my comments above for your question.
Burn Bootstrapper Appliation: There are not that many samples I know about for Custom WiX Burn Bootstrapper applications. Here are two:
Write your own WiX Burn setup GUI application (advanced)
https://github.com/rstropek/Samples/tree/master/WiXSamples/CustomBurnUI
Documentation: For documentation go online, or better yet open WiX.chm and locate section "Building Installation Package Bundles".
Here are two past answers that I would suggest you at least skim:
Ways to customize your WiX GUI (do read this one for overall understanding of MSI GUI)
Custom GUI - WiX Burn, Installshield Suite Project, Advanced Installer - their options
The Implementation of a custom GUI for an MSI depends on the core MSI API function MsiSetExternalUI function. It allows what Burn is doing - making a custom GUI. Throwing in an SDK sample too:
MSI SDK Sample: Some details on the MsiSetExternalUI function (serverfault answer). Concrete code sample to handle Windows Installer messages: https://learn.microsoft.com/en-us/windows/desktop/Msi/handling-progress-messages-using-msisetexternalui. This is MSI API calls direct - nothing to do with Burn as such, Burn makes use of these calls.
Links: Link overload - as usual - but here is an example of a custom Burn theme - as opposed to a custom bootstrapper application. This changes the look of the standard Burn bundle.
https://github.com/frederiksen/Classic-WiX-Burn-Theme
SQL Server named instance with Visual Studio 2017 Installer project (just for inclusion)
Native Windows Installer UI doesn't support this. You would need to create a custom UI handler to display it the way you want.
I am trying to add a delay to an installer. The reason for this is the installer must run a third party driver, but windows does not give "the device is ready to use" notification in time.
This leads to issues for the software as the version to be installed is determined by the device the driver is used for.
What I would like to do is generate a UI that will count down from say 10 to 1 before allowing the user to then proceed.
I have searched through documentation but haven't found anything in Wix that is capable of dong this.
Is this possible in Wix or how can I implement this?
The general answer is that you do a publish event from the dialog, as in this tutorial:
http://wix.tramontana.co.hu/tutorial/events-and-actions/control-your-controls
It sounds like this driver package is a prerequisite to installing your MSI. Therefore I'd create a burn bootstrapper bundle to install it before installing your MSI. I'd have to know more about this package but I suspect the thing to do is create a custom EXE to encapsulate the process and then wait up to 10 seconds while confirming the package is fully committed. Then it can return and burn will carry on to your MSI installation.
You shouldn't be installing drivers (or making any configuration changes to the machine) during the UI phase of your MSI.
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 am using WiX for make installer for any product. But I don't want to use default UI dialog which is using in WiX. How to improvise UI of a installer ? Is there any tool for designing UI for a installer with highly customize ?
Rich GUI is done in bootstrapper (aka. chainer). Chainers are made in tool called Burn (B is for bootstrap). I'm not all that familiar with it, but it was supposed to replace all the GUI available by Windows Installer that you can set in .msi files. This GUI is restrictive, and suitable only for simplest tasks, so the idea is to build .msi only as a database file that is to be consumed by Windows Installer to actually install something, and transfer all the GUI to bootstrapper.
The only thing I've come across is WixEdit, although it seems buggy and may have been abandoned. Still, it allows you to do basic UI design of the WiX dialogs.
I recently came across something called Wix#. It lets you make custom dialogs using a Winforms-like designer.
I know it's 9 years later, but if it helps, great.
I have an existing (C# based) windows service that is derived from the Installer class and I currently use the MS supplied, command line InstallUtil to install it and uninstall it. This works fine and as part of my system I have attached event handlers to the AfterUninstallEventHandler and CommittedEventHandler events. In my case I simply use them to log messages to a custom event log - showing the install and uninstall dates and times and program versions.
At the moment I am experimenting with Wix v3.5 Beta 1 to package up a bunch of my stuff including this service and I am using the Wix ServiceInstall and ServiceControl to replace what I manually did with InstallUtil.
However it seems that Wix uses a totally different mechanism to InstallUtil for installing services. This is seen in the name and description of the service being controlled by Wix (as opposed to what was embedded in the service program) and that my events no longer fire (which, if a different install mechanism is being used I doubt that they would).
So is it possible for Wix to perform a service installation in the same manner as InstallUtil or am I just going to put up with the differences?
Edit
Christopher has suggested factoring out the service related definitions from my code and moving them into the Wix installer project. This makes me uneasy as now I either have to find a way to share information between two separate systems (which I have no idea how to share between the code and Wix projects) or put up with defining the information in two separate locations (very bad software practice).
From a windows installer perspective, InstallUtil is an evil antipattern because it injects fragile out of process code into a declarative programming model. The Windows Installer has long had the ServiceInstall and ServiceControl tables and this works really well. The same applies to Regasm and Regserver. We prefer to extract the COM data and author it into the installer and have MSI take care of applying the registry value rather then loading assemblies and calling entry points in the hope that it works. When it fails, you have no idea why and you can't roll the state of the machine back.
What kind of stuff are you doing in your events? I would either eliminate and/or refactor each of them into something MSI can do for you. If it's still not enough, write a DTF custom action and schedule it between InstallServices and StartServices.