I'm currently planning an installation and update scenario, using MSIs created using Wix.
Initial installation will include third-party drivers as merge modules, which will require elevated permissions.
We want to automate software updates as much as possible, so will make updated MSI packages available on a regular basis. These will be downloaded in the background and installed the next time the user opens the application. We will implement processes to ensure changes to the driver modules will not be included in automatic updates.
Will Windows Installer execute these merge modules if they are not changed? What impact will this have on the overall installer? Would I be better off creating a separate MSI for these drivers, to isolate them completely from the core application package?
Here's some background to help clear things up. Merge modules are not "executed". In fact, once you build an installer they don't exist anymore. A merge module is merely a database containing MSI table data that gets merged into your MSI at build time. Think of it as an encapsulation of a collection of components and related metadata. It's like a C/C++ .LIB file that is statically linked inside an EXE.
So if you have components ( from an MSI or from an MSM ) that require elevated permissions to install then the final MSI requires elevated permissions to intall.
I've done this autoupdate process in the past. You want that process to have elevated rights and after it downloads the MSI "advertise" it as a managed per-machine (what I call "blessed" MSI ). This is done using the msiexec /jm foo.msi command. Then signal a user side process to install the MSI. If authored correctly the MSI will auto elevate without ever exposing admin rights to the user.
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!
Background
I'm currently triaging migrating an existing non-MSI setup to a Windows Installer based solution. The current solution is written in InnoSetup and I very much like it, however, customer IT departments start to require MSI, and where they do so, it is often the case, that many/some of the prerequisites and scripts we include in our setup.exe are not needed for their automated tasks (but, then, some are).
Therefore it seems a pure MSI wrapper doesn't make too much sense here, so I'm looking at (multiple?) MSI files plus a boostrapper.
Prior knowledge
I'm good an InnoSetup, but I'm just starting to read into the Windows Installer technology.
Question
As far as I can tell, for any multistep / "complicated" setup requirements including prerequisites and stuff, using just a bare MSI file is a no-go. (As evidenced by the existence of all the different boostrappers, including the one bundled with WiX, Burn)
Therefore, I would need to split our existing monolithic setup into several steps, some of which (mostly those that install our files) bundled into MSI databases and some of the steps just "scripted" in the bootstrapper.
And here is where I really could use some prior experience regarding setup packages: What parts of a (chained) setup go into the MSI package(s) and what part goes into the bootstrapper?
Should all the (normally visible) UI reside in the bootstrapper or do you put some of it into the MSI files?
How "dumb" should each MSI file ultimately be? That is, if using a bootstrapper and multiple MSI files anyway, should any individual MSI file contain any optional parts, or should all the options be factored out into separate MSI files (that just check for the existence of their respective prerequisites, but contain no logic to install them)?
Basically, the application (suite) needs to support a click-through average user scenario where the setup handles everything and for corporate clients needs to be able to be split up into MSI files that only contain our stuff minus dependencies like the .NET runtime, SQL Server, ... that'll be handled by the client's corporate IT and our software MSIs will be deployed by the client IT automagically.
So, should all the glue and dependency scripting go into the bootstrapper and only use very simple MSI files? Or should some "logic" go into (some) MSI files?
Short-ish answer:
When there are multiple MSI files it is normal for the UI to be handled by the Burn bootstrapper because you do want to see combined progress, not all the separate MSI UIs. You also should set up appropriate rollbacks of more than one MSI in the event of a failure of one if you are really packaging several MSIs as a product, so if one fails they all need backing out.
The bootstrapper contains detection logic that determines what needs installing, and can install prerequisites like SQL, NET etc, but must not otherwise change the system.
The MSI files contain all the files, service installation, COM registration and so on that is appropriate for the files being installed. Any custom action code you use that alters the system must be in the execute sequence, deferred, and have a corresponding rollback CA to undo whatever it does. The MSI should be capable of being run independently to install its content - I've found that to be a useful guideline. The MSI files will be installed without their UI, so ensure that they can be installed silently with parameters passed as property values on the command line, including install location.
Hard to answer this in brief. Do use Burn or a similar bootstrapper, and leave runtimes with their own deployment solution as a separate file to run - and run in silent mode by default.
For home users you should install everything without too many questions to avoid confusion.
For corporate deployment you should deploy only what is needed and make it clear what each included deployment file is for:
Write a one page PDF with deployment instructions describing what every file does and what runtime it relates to. Call it "DEPLOYMENT README.TXT" or similar. This is the best way to get your application approved for corporate deployment. It can be tiresome to analyze this.
Application packagers in the corporate environment will analyze the prerequisites and determine if your application will work well with their standard framework packages. These standard packages will be set as a prerequisite in the distribution system.
Document in particular what .NET framework version is needed and other runtime requirements in detail.
Don't install windows hotfixes, msiexec engine updates or .NET framework runtimes automatically. Document them as prerequisites in your text file. These runtimes are tightly controlled in corporate settings and they are deployed by customized corporate packages.
You can include merge modules of simple runtimes in your MSI, they can be easily removed by the application packaging team in the corporate setting.
This answer didn't get terribly good, but I am out of time. Perhaps check this answer as well:
MSI Reference Counting: Two products install the same MSIs
I have a small application that is designed to run under currently logged on, non-administrative workstation user. Application can be installed manually but I also made sure that it is compatible with Group Policy Objects (GPO) software distribution method - I have .msi files for old systems (XP/Vista): separate files for per machine and per user installations as well as .msi file that takes advantage of Windows 7 (and newer) compatibility with WIX Allusers=2 option to allow automatic registry and folder path redirection depending on the installation context.
All is good there, but I am just wondering, is there anything special I need to do to make my installer suitable for installation using Microsoft System Center Configuration Manager? I do not really have resources to just test such a scenario myself and would like to find out about theoretical requirements for installer files for SCCM.
At my day job I'm the Deployment Architect for a Fortune 50 company with an SCCM 2007 environment ( currently migrating to SCCM 2012 ) that has over 300,000 clients. Here's a few tips.
1) We don't do Per-User installs. They are impossible to manage and report on. If an installer must have Per-User resources and we can't get the application (typically vendor provided) we do this using an Active Setup technique where the first time each user logs on the MSI does a repair and populates the Per-User resources. Just realize you'll never get it off... it's essentially forever.
2) SCCM can handle non MSI deployment types but well written MSI's work the best.
3) Use snapshotted VM's to test your install in the SYSTEM context. (PSExec is your friend)
4) Test your install, uninstall, reinstall, upgrade, repair, change. Make sure everything is bulletproof.
5) Don't wrap up prereqs into a setup.exe bootstrapper. Decompose it and allow SCCM to package each of these items. You can then use package chains, task sequences or application model to allow SCCM to manage the chaining. You get better status, reporting and efficient use of the system.
Just a couple of thoughts if I remember these things correctly - the MSI should be capable of silent install, and among other things that means no custom actions exclusively in the UI sequence, because they will not be run at deployment time because you will probably suppress the UI. The execute sequence shouldn't have custom actions that might explicitly display messageboxes requiring acknowledgement unless they are based on calls to the Win32 MsiProcessMessage() API or equivalent.
I created one msi for my product it's working well but I need to install .net 4.0 as a prerequisite. I came across burn and bootstrapper but have a couple of questions:
Should I have a separate project for the main msi and the bootstrapper?
My customer needs an msi (not an exe), so can the bootstrapper be an msi?
The bootstrapper project is a separate project and produces an .exe as its output. It is its own executable, whereas an .msi is essentially a database that gets processed by Windows Installer.
MSI (Windows Installer) does not support "nested" installs, where one .msi package runs for a while, then pauses, runs a separate installer package, then picks up from where it paused. MSI uses some Windows resources that are essentially system-global, so the "inner" install tromps on the "outer" one.
The way to do multiple installs as a single user experience is to run each install in sequence, one at a time. That is the purpose of the bootstrapper, also known as a chainer: to run the chain of installs, link by link. The bootstrapper is not itself an install package; it is a tool for running one or more install packages.
That is why the bootstrapper cannot be an .msi: it is not itself an installer package. A bootstrapper can be as simple as a batch file or script, or you can use an industrial-strength tool such as a WiX burn bundle, Flexera AdminStudio, etc.
Be aware that there are some installer packages that ship as .exe -- for examples, the .NET Framework or SQL Server installers. These are essentially self-extracting archives that contain one or more .msi packages, dump a temporary copy of that payload then run the Windows Installer service on it. In some sense they are "bootstrappers" plus package, all rolled into one. A bootstrapper can run packages (and other bootstrappers), but not vice-versa.
You might think that you could have your outer package run a custom action that launches the inner package. We've all tried it... and found out the hard way that it doesn't work generally, even when you appear to get away with it on some specific target system.
You'll have to persuade your customer that Windows Installer does not, cannot, work the way he thinks it does. Sadly, sometimes the only way to do this is to replace the customer.
I would like to create a installer (like BootStarper) to achieve following steps using WiX.
There will be a setup.exe file.
Upon Runnig this file it has to open a UI and show the list of softwares (MSI) available for installation.
The software products are grouped into two Group A or Group B.
Each group may contain Two or more MSI files (Both internal and third party files)
Allow user to Choose a group and one or more products to be installed.
Based on the selection, the products should be silently installed on the local system.
Shall I create a WiX project and display given products(MSI) as its features and can start a deffered custom action to install the seleted ones?
How to author my WiX project to choose the groups and then selected features?
Any help would be greatly appreciated.
Upgrade to WiX 3.6 (Beta) and take a look at the new "Burn" functionality.
You cannot use a deferred custom action to install another MSI because there is a mutex that enforces one running execute sequence per machine.
There is functionality in MSI 4.5 called multi-package transactions however MSI 4.5 may not be already installed on a 2003/XP/Vista Machine so you'd need setup.exe to boostrap it anyways.
Also "concurrent" installs are deprecated and should not be used to do servicing issues.
This is not something you can solve either with the stable WiX release, or Windows Installer.
You will need a separate bootstrapper to launch your MSI files. as the WiX bootstrapper, Burn is only in the WiX 3.6 beta release and not yet properly documented I would suggest trying something like dotNetInstaller.