Installers: WIX or Inno Setup? [closed]
开发者_如何学Go
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 questionI'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.
加载中,请稍侯......
精彩评论