48

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?

Brent Arias
  • 26,187
  • 32
  • 120
  • 209
  • For anyone who chooses Wix in the end, please use [WixSharp](https://wixsharp.codeplex.com) togother, it will save you days. – Felix Jun 07 '16 at 06:49
  • I prefer GetWebInstaller. In any case you can use standard installer from Visual Studio. – MastAvalons Oct 16 '18 at 18:58

5 Answers5

46

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.

Tim Cooper
  • 144,163
  • 35
  • 302
  • 261
Robert Love
  • 11,881
  • 2
  • 47
  • 77
  • 17
    If you software is delivered to consumers, InnoSetup is an option. If your software is delivered to enterprises, I would only use MSI. That fact is why I ignore InnoSetup and just use MSI. I paid the learning curve for MSI a long time ago. :) – Rob Mensching Jul 25 '11 at 15:59
  • 2
    Our software is internal and for an enterprise. – Robert Love Jul 27 '11 at 19:42
  • 2
    @Rob Mensching: I'm curious, Why would you only use MSI for enterprises? – 8DH Apr 25 '12 at 13:31
  • 2
    @8DH, MSI is more group policy friendly. That is, you can easily deploy an MSI with group policy, an EXE is more fiddly. – Boinst May 08 '12 at 04:43
  • @RobertLove Why did you switch to uninstallinng the previous version? Does your installer rollback the uninstall if the upgrade fails? – jpmc26 Nov 18 '13 at 08:02
  • No it does not rollback, but then we have never had our installation fail. – Robert Love Nov 18 '13 at 22:04
  • 7
    FYI- Even Microsoft is using InnoSetup for Visual Studio Code. – Robert Love Jun 01 '17 at 16:22
  • @RobertLove - can you provide details for how you accomplished "automatic uninstall of the previous version when new version was installed"? – Bill_Stewart Mar 17 '21 at 16:12
  • 1
    @Bill_Stewart I looked for the unins*.dat files in install directory (inside InitializeSetup) and Added CurStepChanged that detect if step was ssInstall and runs uninstall first. I have code if you want ask a separate question that is not closed I can share. – Robert Love Mar 18 '21 at 19:00
  • Thanks @RobertLove - I am actually writing a simple DLL for use in IS that makes this pretty simple. Once I get it polished up I will be sharing it on GitHub. (It uses a slightly more advanced technique for checking if the app is already installed and can compare the version so you can decide, from code, if you want to automatically uninstall the current version only when downgrading, for example.) – Bill_Stewart Mar 19 '21 at 13:39
  • Published to GitHub - https://github.com/Bill-Stewart/UninsIS – Bill_Stewart Mar 19 '21 at 21:33
36

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.
Community
  • 1
  • 1
Lars Truijens
  • 40,852
  • 6
  • 117
  • 137
  • 1
    Thanks, very good summary of MSI. Now I'm just wondering, which of these features are not present in Inno Setup? – 8DH Apr 25 '12 at 13:36
  • 5
    I like InnoSetup and I haven't used InnoSetup for a while, but basically all. The downside that MSI is much more complicated, so if you don't need these extra features you should definately try InnoSetup – Lars Truijens Apr 25 '12 at 16:22
  • 6
    When I read this, I can't help but think, "bureaucracy run amok." It sounds like MSIs are good when you're dealing with control freaks who want to mess with everything your installer does. I actually consider that a disadvantage, since then you have to design your installer to handle all these unforeseen cases. Supporting that kind of workflow sounds like a nightmare. If they want that level of control over the install, what's the advantage over them writing their own installer or using scripts they can just modify themselves? – jpmc26 Nov 18 '13 at 08:27
  • 2
    jpmc26: It is actually quite the opposite. MSI enforces so many restrictions on the packaging process that many applications are much easier to deal with for large scale deployment than before, but very often the packages are badly designed from vendor due to the steep learning curve of the technology. Most of the times these errors can be corrected because the technology is largely transparent - but it takes a lot of experience and knowledge. The most important of all MSI benefits is that the uninstall is automatically included as part of its design. This was a nightmare before. – Stein Åsmul May 09 '14 at 00:36
9

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.

Mike
  • 3,373
  • 3
  • 18
  • 12
  • 2
    See http://www.jrsoftware.org/ishelp/index.php?topic=scriptdll. According to that page, you can call .NET DLLs via COM interop. I imagine that's what WiX is doing for you in the background, anyway. So it's less convenient, but at least it's available. – jpmc26 Nov 18 '13 at 08:17
  • No. WiX do it in "native" way, means the custom actions were put into MSI database as a "DLL" action, so the MSI will then call the DLL directally (MSI itself maintains a .NET host). – Earth Engine Feb 12 '14 at 22:32
4

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.

CubicleSoft
  • 1,614
  • 14
  • 17
3

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.

Lothar
  • 11,018
  • 5
  • 66
  • 110
  • 4
    In the meantime i learned that multilanguage installers are possible with some installer "transformations". So we might completely move to WiX in the future. – Lothar Nov 02 '15 at 03:11