I am looking to insert a custom page into the burn Bootstrapper sequence that collects data, via a checkbox, and lets the user choose whether they want to install SqlExpress as part of the install process.
The research that I have done suggests that this is not possible without modifying the Wix Sources.
Is this correct?
Kind Regards
Scott
WiX Toolset provides two (well, actually three) Bootstrapper Applications:
A repurposed BA that has minimal functionality, which uses "theme files" (which are "overridable") to style each "page". It can be "extended" with a "BA Functions" dll you can include, but there's no hook to allow that dll to "find" or "sequence" any additional pages you add to your theme, or additional controls you try adding to existing pages, for that matter, that I know of.
A managed code "host" that calls your BA written in managed code. This will call the BA mentioned above with a specific theme to provide UI for installing the Net Framework needed by your BA if your BA fails to load.
The installer for WiX v3 itself (which is a BA written in managed code).
Alternately, you can write your own BA, in either C/C++ (or any "compatible" language) or managed code, and use it instead of the one provided by WiX (e.g. for a client I helped develop a BA written using WTL that used the built-in Wizard dialog in the Win32 API). Other than including a header file from the WiX sources, no code from WiX was used.
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 want to make a MSI installation using WiX and EmbeddedGUI. I really want to make it highly modular - ie the main MSI will contain only the basic files (the required ones), and all other features will be split into separate MSI files, which will be downloaded from internet if not present on hard drive and installed only if selected in my EmbeddedGUI.
But I am totally new to WiX, and I can't find a way to actually how to make that modules? MS Office and MS Visual Studio seems to be using this scheme, by using the modules which it downloads over internet and installs them in case of need - something like this:
It seems that Fragments is mostly like "static libraries", not "dynamic libraries" which would be more useful in such a situation. There is also the Chaining mechanism, but I'm not sure I will be able to bundle the features as the same application (only one entry in "Install/Delete" window) because it seems to be calling external MSIs completely separately (more like invoking "separate exes" instead of loading "dynamic libraries").
So, what is the way to go for making a highly modular setup package with WiX?
Use a bundle (chain). The Burn engine, which manages bundles, will show only the bundle in Add/Remove Programs and can download any packages that aren't already present -- for example, using the MsiPackage/#DownloadURL attribute.
We are currently using WiX with the standard bootstrapper application. In the past this has worked well for our needs, however now we would like to add some additional functionality, such as validation of database details entered in the bootstrapper UI.
I know that this would be possible by modifying the standard bootstrapper application, however this requires coding in C which I would like to avoid. (I can write in C, but I'm far more competent and less error prone in .Net)
Is there a .Net port of the standard bootstrapper application so that we can implement these actions in .Net code, or would I need to write a .Net bootstrapper from scratch?
No, WixStandardBootstrapperApplication is only available in native code. The BA for WiX itself is open source like the rest of WiX: https://github.com/wixtoolset/wix3/tree/develop/src/Setup/WixBA
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. :)
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.