Disclaimer: I've still never gotten beyond the most basic WiX tutorial, because every time I try to understand the concepts, my head starts spinning.
I've been reading Is it feasible/sensible to wrap an InnoSetup installer inside an MSI for easier distribution via AD? :
- There is a tool (look for exemsi MSI wrapper) today that can wrap a script/exe based installer, like InnoSetup, and provide install, upgrade and uninstall.
- From my experience, that's what users expect: Can install product, newer setups can upgrade it, uninstalling will remove product.
-
Yet quite a few answers on that question state that only a "true" MSI can reliably provide "all"(?) required(?) features.
So, given that what I always thought an installer was supposed to do is:
- Install product with as little hassle as possible
- Allow repairing a product (possibly by simply running the setup again)
- Allow upgrading of product via a newer setup
- eventually uninstall the product, leaving as little trace as possible.
The question is, given that it is proven that, given the right tool, the points above are possible by simply wrapping an exe in an MSI, what additional advantages do "real" MSI packages offer?
To be clear here: An MSI package does (seem to) offer additional benefits for enterprise / AD / GPO distribution, that you don't have if you have a bare .exe
installer - I don't question that. What I'm interested in is what - actually used - features are only possible through a "real" MSI package?
MSI supports installing additional features on demand. A shortcut (.lnk) created by MSI contains special metadata recognized by Windows and can automatically repair and/or install missing features.
Another advantage is that non-administrators can install patches without UAC elevation if the package is signed.
Some disadvantages of MSI are:
- Cannot create a single .msi for 32-bit and 64-bit targets.
- Single user/non-elevated installers can be problematic because the support for this has changed over time and new MSI properties have been added.
- Depending on your minimum supported Windows version you might have several major versions of MSI to test/deal with.
- Bloats your system drive by storing the full .msi in %windir%\Installer on recent versions of Windows.
- Bloats the registry by storing the path and other information about every single file it installs.
- Installation or removal operations are by Feature (of a Product). This is not as relevant as it used to be because of the trend toward smaller installers with fewer questions being asked of users. For large installers, for example Visual Studio and SQL Server, questions are asked via bootstrappers--the opposite of what you are considering.
- Installation, repair and removal are by Component (across all Product and Version). Reference counting is under the control of Windows Installer and is less likely to become corrupted than the pre-Windows Installer technique. Shared components are now less common because of different application technologies such as .NET and registration-free COM. Large systems might share components but again they might be divided into separate installers so that no Component is needed by more than one Product.
Whether these are advantages depends on the needs of your installation architecture.