When creating an installer using Windows Installer (via WiX), is there any guideline as to whether or not to use a single MSI or multiple? Our application is divided into logical components internally, so I am wondering if there are any advantages to creating multiple MSI files versus a single file? We are using burn to create a bootstrapper, so I don't believe there will be any noticeable difference to the end user (but my knowledge of WiX is limited at this point). Thanks!
IT all depends on the size and complexity of your application. If it's a relatively small installer with no reuse across multiple products and you are using major upgrades then one install is probably a good choice. (KISS)
But if you have reusable pieces shipped by multiple applications and/or you are trying to keep each installer simple so you can manage minor upgrades and patches easier then chunking it out into multiple msi's and chaining them together might be a better approach.
WiX used to have a single MSI but went to multiple MSIs. Personally I don't see why they felt the need to do this as their footprint really isn't that big and they have never released a minor upgrade or patch. I'm guessing they just wanted to dog food Burn with a cool looking bootstrapper application and a bunch of MSIs to chain.
Related
What is the best tool to create an installer for asp.net application? My objectives are to:
Install an asp.net application on iisexpress
Install sqlexpress (as a prerequisite)
Configure IIS for my application
Restore data on sqlserver
Either will do the trick, so it comes down to what your needs are, and how they stack up against each other
InstallShield
Will guide you through the process a lot more than WiX, and so will get you off the ground quicker
Has built in functionality for talking to IIS, SQL and a bunch of other sources
Has built in functionality for installing a number of prerequisites, such as .NET. I believe installing sqlexpress as a prereq is supported.
Can target InstallScript, MSI, or a mix of the two
WiX
Is free & open source.
Is much more flexible in how you organise your code. It uses XML like InstallShield, but unlike InstallShield you have pretty much complete control over how the code is organised, and it's generally much easier to compare and merge the code in your source control system.
Is very extensible - you can hook into the compiler mechanism through WixExtensions
Has functionality for talking to IIS and SQL via custom actions and syntax extensions
Comes with Burn, a flexible and powerful bootstrapper, install chainer, and install host. This can handle your prerequisite installation for you, and even host your UI.
Conclusion
Personally, I recommend learning WiX - the code is easier to manage for large projects over time, and you are less likely to reach that brick wall where stuff just can't be done because of how extensible it is.
However, it will take you longer to get off the ground because you have to actually understand what's going on to a greater degree than with InstallShield.
I am currently migrating projects from various versions of InstallShield to Wix. You need to put more effort into Wix, but it is worth it in the long run. The problems I have found with InstallShield is it is relative expensive to license, and once you start using it you become hooked into paying out more money to upgrade it or get the latest version, because the person who used it last is no longer around, license keys have gone astray, there are not enough license keys anyway, a license key that used to work no longer does for some strange reason...etc, etc. Without a up-to-date and functioning license key InstallShield will not work.
Because an installation project is not something we use all the time, but when we do use it we need it to work, I have decided to junk InstallShield for something more reliable (in terms of licensing).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm comparing these two tools. The impression I have is:
Inno Setup does not produce an MSI, but can do everything WIX can do
WIX does produce an MSI, but has a steep learning curve
Do you agree with this characterization? What other differences are there? How does WIX# shake-up this story? Since Inno Setup does not use the windows installer, does it have difficulty with uninstalls? Can Inno Setup, upon command, downgrade an installation to an earlier version - or can it only install / upgrade applications?
It's been a long time since I worked with MSI, when I switched to InnoSetup I never looked back.
I did not want my installation to be a headache. I needed something where I could "Set it and forget it"
By default InnoSetup produces an uninstall.
It can handle simple or complex install and uninstall needs.
With InnoSetup You have a few different ways you can upgrade applications.
Initially we did use the overwrite method which just overwrote the existing installation.
Recently we switched an automatic uninstall of the previous version when new version was installed.
With InnoSetup downgrades are typically uninstall and reinstall the older version.
You are right about the MSI not MSI part and you are right that learning curve of MSI is steeper. But both have features others don't. Let me quote Glytzhkof on the advantages of MSI.
Glytzhkof says hi ;-). Please do read both my original answers on serverfault.com for a summary of common problems with MSI resulting from its steep learning curve. This answer here focuses on the theoretical benefits, the other answer (in the same thread) summarizes common MSI problems off the top of my head. Additions there are most welcome - I just added the most common issues.
Transparency (Open installer format)- An MSI can be reviewed and
inspected. This is a huge issue for
large corporations. With the exception
of compiled custom actions an MSI file
is a "white box". If the setup changes
something crazy such as the
system-wide network settings, you can
actually see it.
Customizability - An MSI can be customized via transforms to fit an
organization's needs and standards
whilst still allowing interoperability
with the vendor's installer updates.
You don't change the installer itself,
you create your customization in a
separate, organization-specific file
called the transform. You are free to
disable custom actions and in general
anything in the installer, and "black
box" custom actions can be approved by
contacting the vendor for explanation.
These transform files are also
sometimes used to localize an MSI file
to different languages. Several
transforms can be applied to a single
MSI.
Standardization - MSI does not lend itself to "allowing anything". It
provides a comprehensive framework for
the installer, which crucially also
includes the uninstall - all in
standard format. The installer GUI is
also standardized with built-in
features to support silent
installation and uninstallation which
can be triggered remotely.
Management and reporting - Windows Installer maintains a
comprehensive database of all items a
product has installed. You can
reliably determine if a product is
installed, what features were
installed, and what file versions were
installed. In addition you can get a
list of any patches that have been
applied to the base product, if any.
Security - following from the comprehensive installation database it
is possible to detect security
vulnerabilities in the installed
products. MSI also encompasses
"elevated rights" principles which allows a restricted user to trigger
the install of a product that requires
admin privileges to install. This is
part of the "advertisement feature"
which allows an administrator to make
installers available to users without
actually installing them on all
workstations. There is no need to mess
with temporary rights to get things
working.
Validation - MSI files can be checked with validation rules to
ensure it is in compliance with a
number of internal consistency rules
(referred to as ICE). Corporations can
create their own ICE checks to enforce
special corporate rules and
requirements. This helps greatly with
QA.
Resiliency - The Admin install feature of Windows installer
provides a standard way to extract the
source files from an MSI. These source
files can then be put on a share and
be available to all workstations for
installation. This ensures repair,
uninstall and modify operations
complete without requesting the
installation media on CD or similar.
This is particularly important for
patching and update operations which
may require access to the old versions
source files in special circumstances.
Rollback - The installation of an MSI file will normally trigger the
creation of a restore point.
Furthermore all files and registry
items replaced or overwritten during
the installation will be saved and
restored if the install fails to
complete. This ensure that the
workstation is left in a stable state
even if the install should fail. As
you might expect poorly designed MSI
files can violate the built-in
features of Windows here, see my other
post in this thread for more details.
Patching & Updates - though highly complex patching in Windows
installer is fully managed and
registered on the system so that a
systems security state can be
determined by checking what has been
installed. Updates are standardized to
a few basic variants, and this allows
updates to be performed with a higher
degree of certainty. Deployment
systems will be able to report what
updates failed and why.
Logging - Windows Installer provides a standardized logging
feature which is greatly superior to
previous incarnations, though almost
excessively verbose. Log files can be
deciphered using log analyzers, and
custom log levels can be used to
eliminate generating too large log
files with unnecessary information.
For debugging purposes verbose logging
is extremely useful. See Rob Mensching's blog for a good manual way to read an MSI log file.
I'm late to responding to this thread. I have used Inno Setup for my company's product for years. It does most things very well but the biggest hurdle for me is custom actions. In Inno Setup, one must use a variant of the Pascal language. With the WiX Toolset, I can and do use C# for my custom actions which is much more comfortable for me. Admittedly, that is a personal preference but it is the primary reason why I switched from an otherwise excellent Inno Setup platform to an also excellent WiX platform. That, and the fact that there were so many benefits from using MSIs which have already been mentioned in another response.
Frankly, for me, the learning curve of Pascal was greater than that of WiX using the book, WiX 3.6: A Developer's Guide to Windows Installer XML.
I realize this answer comes VERY late. But I ran into this post and figured one answer to the question could simply be: "Why not have both?" (eat cake and have it too) and also "Why expend the effort on implementing both when I could just expend the effort for one and get the second one for practically free?"
Toward that end, I present an Inno Setup script w/ MSI support:
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-innosetup/yourapp.iss
There are some custom Pascal functions in use here that kick in when passed /MSI={GUID} on the command-line that trigger useful changes to the script (e.g. no Uninstall icon in Start or Add/Remove Programs).
And I present a WiX script w/ support for the above Inno Setup script:
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-wix/yourapp.wxs
The WiX script wraps the Inno Setup-based installer EXE (the only payload) in a way that triggers the Inno Setup script to do things in a more MSI-compatible way and cranks out the MSI. It isn't perfect, but it saves a ton of time by letting you do things the Inno Setup way and then get most of the benefits of MSI (e.g. GPO/SCCM/DSC silent deployment) without pulling hair. This works best if mostly just deploying files to the system and a handful of registry entries (i.e. a basic app). I wouldn't recommend this approach for a larger application where there are lots and lots of components, but if you try it and it works, let me know! Having a MSI version that launches the Inno Setup EXE at least gives sysadmins doing deployments something reasonable to chew on.
Note that the WiX script depends on the custom Pascal functions on the Inno Setup side of things. You can't just take any ol' Inno Setup installer and wrap it with the WiX script and expect it to work (it probably won't). But maybe a future version of Inno Setup will natively support something similar.
We integrated both into our build system.
But we decided to promote innosetup exe files for non business customers and msi only on demand for one simple reason.
You can't ship a multi-localized version of setup program with MSI. You would need one installer for every language and this sucks huge. There might be some heavy hacking allowing you to rewrite the whole GUI but this is not well documented and no open source to steal and a lot of work.
The GUI is infact tbe worst part on WiX which otherwise is technically superior to Innosetup.
With Innosetup it's easy to ship one exe in 5 languages. We already have 6 binaries [Free,Home,Pro - each 32/64bit] so the variant explosion would be just huge and if you market a japanese version with a japanese webpage and the first thing that comes up is an english only installation it is a bad impression.
The MSI for business users who need group policies etc. is english only and thats fine for business users.
We've got an EXE which works great for installing our application. However, we have multiple customers who are requesting an MSI for ease of deployment in their current domain.
If we use our existing EXE install process, can we wrap that into an MSI and expect good results? The EXE creates an "Uninstall" that is added to the control panel's uninstall list... will the MSI also generate an uninstall point, leaving us with two entries?
Is there anything else I should watch for?
Thanks
Your customers are probably asking for MSIs so they can manipulate the MSI with the variety of tools that work only on MSIs. For example, there are deployment tools that are able to look at MSIs and only send down the changed files to a system when it gets a new version of the MSI. These work off the file table in the MSI. If you wrap your exe in a MSI, the only file in your MSI file table is the exe, which makes tools used to manipulate the files you are installing, useless.
An EXE setup file can be anything, including an MSI in a setup.exe launcher. However, in your case I don't believe that is the case. You probably have a legacy non-MSI installer.
Most big companies actually take older, legacy-style setups and repackage them as MSI themselves - whole teams exist to do this job (as mentioned by Linda). This is to benefit from a substantial number of MSI benefits for corporate use that are crucial for large scale deployment (the administration of software for many computers). See the same link for common problems with MSI files - it is definitely not an easy technology to deal with.
Wrapping your existing EXE in an MSI is not an option. This adds nothing but risk and complexity for no gain at all. In fact you will irritate application packagers in large companies by making it harder to repackage the right way.
Remaking your setup to be an MSI file is a good investment if you use good consultants to do it, or take the time to train your developers to do it right. MSI is an unusual technology, and distinctively unorthodox to deal with. Many developers feel it is impossible to understand, and for good reason. It is an entirely different installation paradigm than what used to be.
The latest and greatest for MSI is the Wix toolkit. A free open-source toolkit allowing you to create full-fledged MSI files without any expensive third-party tools. This short summary of its history and creation might be helpful to understand what MSI is about as well.
I guess the overall summary is that wrapping your software in an MSI file is no small investement with regards to the work involved, but it has major benefits when done right.
Wrapping your existing EXE inside an MSI has no value at all - it just causes new problems.
I have a WIX 3.0 installer that is building 88 slightly different builds (cross product of 32 and 64-bit, 11 locales, four editions (Beta, Retail, Evaluation, Different Evaluation).
Each build has slightly different contents in addition to localized UI, so I can't just build one configuration with multiple locales.
The resulting MSI is about 120MB. I'm already using the CabCache.
The installer takes about 3-5 minutes per release to build, resulting in a pretty lengthy overall build time.
The install appears to be heavily disk bound during linking (light.exe).
Clearly making the disks faster could help. Does anybody have advice on how to set up a machine that could crank through these installers faster? (or advice on reconfiguring my WIX project to build more efficiently?)
Get an SSD. Like one of those with internal RAID architecture from e.g. OCZ. SSD is every developer's upgrade of the decade. Plus more RAM if swapping is an issue.
If you have common parts (that are not localized) you can create a merge module with the common parts and then just add the differencing stuff to each build.
I am not sure if you have any say or communication with the developers of the application that you are installing, but if you have to create that many MSI's mainly because of languages, have you considered just offering one Language MSI that delivers all the language specific files to a resources directory and then the user can choose which language they would like to use (but only install this if they need something other than the default language). Also it might be worth looking into having the product made in such a way that the user can pick from within which language is best, then having all the languages installed from the start.
As for your question about speeding up the build, that is a tricky one. Using Merge Modules I would rule out right away, as I don't see any actual gain coming out of that. Of course updating the hardware (as you said) will give some results, but again, I am not sure how much of a jump you would be making so it is hard to tell what kind of gain that would give. I think it might be best to go over your WXS with a fine tooth comb and see what is really going on in there. You can sometimes find things that are left over from the developement of the package, or from a previous tool that are really slowing you down. One example would be that my company recently switched to WiX from a more automated setup creation utility (leaving the name out on purpose cause I am listing the problems with it :P ) and it automatically created every folder under Windows that might possibly be needed in the running of a windows application, as well as the common files folder, the current user profile, and many many more. I think I ended up erasing in all over 100 empty directories that this old technology was nice enough to add for me. That is just one example of optimization that was done. It is amazing what can be found when you take the time to REALLY review what is going on under the hood.
In your wixproj setup file add this just before the end of file in <PropertyGroup> tag
<IncrementalGet>true</IncrementalGet>
This will tell WIX to compile only those files which are changed after the previous build.
It's always seemed strange to me that downloadable applications would offer multiple types of installers. For example, sometimes you can choose either a .exe or a .msi
Do certain types of installers have advantages over others? Does it matter which one you choose? As a developer, why would I want to offer different installers to my users?
One big difference between the exe and msi:
You can EDIT an MSI file.
You can access the MSI Database directly using Orca -or- code it up through the WindowsInstaller APIs, using your favorite Windows hacking methods.
Ex. I wrote a python based builder which, amongst many other tasks, routinely edits and updates MSI packages.
A quick warning to brave souls:
Although the APIs seem well documented, a LOT of WI functionality is subtle, even cryptic - the MS Office team definitely did not chose the principle of "least surprise" when they created Windows Installer.
IF you choose to delve into the mystic world of WI, be prepared for long hours of head scratching, tedious debugging and pouring over enormous MSI log files
A big advantage of .msi over .exe is that they can be "rebundled" (I don't recall the correct term) by sysadmins for installation over the network for deployment in corporate environments.
In corporate environments, clients are often subject to a "lockdown" policy that prohibits them from downloading EXE files, but usually MSI files are OK.
the exe ones are mostly compressed ones. msi cant compress really good.
the msi file you can share/install on your computers directly with windows active directory.