We have a product similar to Microsoft Office. Several different applications with a lot of shared libraries. We’re trying to refactor the deployment process of this product as currently we’re using several individual MSI packages to install each application independently. While this is working, we would like to use the WiX bootstrapper to bundle these MSI files and create just one setup application. Currently all shared libraries are included in each MSI package, which takes a lot of space.
We have basically two options to achieve this:
Create one WiX setup (MSI) project; include all products as individual
Features. In this case handling the shared libraries is pretty
straight forward. But the structure of the project is getting too big
in my opinion.
Create several MSI packages. Each with just one
product and bundle them to the bootstrapper. In my opinion, this
approach is more flexible and more clearly arranged in terms of files
and components. However how do shared libraries work here? They
should not be included in each and every MSI file.
Which approach is preferred in a WiX bootstrapper project?
One big MSI with many features is too hard to support.
It's easy to share components between MSIs. The shared components must have identical GUIDs and component key paths. See details.
To easily achieve this goal create a WiX Library project for all shared components (each component or component group in its own fragment). Then include the library into all WiX Package projects and reference its components (or component groups) in WiX Package projects.
You can group shared components into several MSIs, then create one or more bootstrappers for your applications.
A couple key things to know:
MsiPackages can be configured so when the bootstrapper installs an MSI, it shows or doesn't show the MsiPackage in "Programs and Features" (ARP) list.
An MSI may or may have its own UI. In any case, you can suppress it in the MsiPackage element. If your really, really need to ask users something during installation, you can ask in a custome bootstrapper application and probably pass it to the MSI as an MsiProperty.
So, I suggest an MSI for each application and each group of shared components. And, one or more bootstrappers for one or application MSIs and the shared MSIs that they need. If you create a custom bootstrapper application UI (C++ or .NET), like Visual Studio and WiX itself do, your users can selectively install/uninstall your various applications using one bootstrapper.
Related
I am using WiX 3.11 from MSBuild to generate multiple MSIs (one MSI per "application"). Each application is the same set of core assemblies with a few unique assemblies that provide the unique functionality of the application.
The build is fully automated, and "just works" when a developer references a new nuget package or adds a project because I use Heat (via the HeatDirectory task) to collect and generate wxs files for each application and produce an MSI.
Since these applications all use the same core projects, the MSIs are probably 90% or more the same underneath. I am at a loss, however, as to how (or if) I can leverage this commonality to speed up and/or save space during our builds without having to manage which components are shared. We'd also like to continue to have a single MSI for each application.
Has anyone done anything similar for their installers?
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 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 have a product that has three parts:
Application files (exe and dll files)
Help files
SSRS reports
All three things get installed together with the same installer built using WIX. In our company, each component is developed by separate teams and with different deadlines. We would like to break our MSI into three parts so that when one part becomes stable its installer part is also stable and is not rebuilt from scratch when the other parts are updated.
I've looked at merge modules and CAB files but I think that's the wrong direction. Is there anything in the WIX toolset that can help me achieve my aims?
(I have read the question Building MSI Installer and Separaete Installation Files but believe this question is a bit different.)
Thanks for your help.
WiX library (*.wixlib) seems to be the best approach to distribute the components in your case.
I would organize this process like this:
each team has a separate WiX installation project (Setup Library Project), which compiles into *.wixlib file instead of the MSI (or MSM) package
each project is evolved as the component is developed, and the output is shared to other teams
an integration build gathers all wixlib libraries and links (light.exe) them all together into a single MSI package
Hence, you'll always have a final installation package with the latest builds of components, which is what continuous integration is all about.
As far as I understand, you won't distribute the components separately, and for the end user it is still a solid installation package. Hence, merge modules could be an overhead. I suspect (but not sure) that light.exe performs some extra validation when linking the libraries, comparing to merging tool.
Well, merge modules are a solution. You could have two merge modules containing the help files ans SSRS reports, and add them in the main package that will contain only the application files. This can increase build time if nothing is changing in the two merge modules but you will still have a long build time for the main package changes.
Another option is to create separate packages for each of the components and bundle them into a single one using Burn. I would recommend using the merge modules, its more cleaner and easy to manage.
I'm looking for a tool (preferably not InstallShield, and also preferably cheap/Free) that supports Chained MSI Installations. I've got several small installations that need to be able to be deployed separately, but also as one group, and I'd like to not have to maintain multiple installers.
It looks like I need Windows Installer 4.5 to do this properly, but I can't seem to find to much info when I'm looking around for what version of Installer is supported.
The MSI 4.5 functionality is just a set of APIs that allow bootstrapper/chainers to do smarter things for multiple MSIs. You still need a bootstrapper/chainer to install multiple packages. In WiX v3.6 there will Burn.
Incidentally, it used to be possible--although not particularly easy--to "nest" or embed other MSIs into one parent, but it involved tweaking custom actions and such to ensure that the nested programs were removed upon removal of the parent, etc. Sadly, this feature is "deprecated" and thus no longer recommended by Microsoft. Here's how to do it in a Visual Studio installer project... but creating a bootstrapper with WiX would be more advised.
What you need is a bootstrapper. Using and InstallShield or Wix will created an MSI themselves which when that is running will not allow the other smaller MSIs to run. If you already have the smaller MSIs to run a bootstrapper is all you need.
MSDN has a free one you can download that plugs into VS2008 and uses MSBuild to compile. What you will probably need to do is create packages for your MSIs and put them in the bootstrapper as prerequisites. This will allow you to set it up to run them in a particular order.
Here is the MSDN link: MSDN Bootstrapper Manifest Generator
Look at NSIS