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.
坦率地说，对我来说，使用《WiX 3.6：Windows Installer XML 开发人员指南》一书，Pascal 的学习曲线比 WiX 的学习曲线要长。
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:
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:
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.
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.
发布评论
评论（5）
我已经很长时间没有与 MSI 合作了，当我切换到 InnoSetup 时，我就再也没有回头。
我不想让我的安装变得令人头疼。我需要一些可以“设置它并忘记它”的东西，
默认情况下 InnoSetup 会产生卸载。
它可以处理简单或复杂的安装和卸载需求。
使用 InnoSetup，您可以通过几种不同的方式升级应用程序。
对于 InnoSetup 降级通常是卸载并重新安装旧版本。
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.
With InnoSetup downgrades are typically uninstall and reinstall the older version.
您对 MSI 而非 MSI 部分的看法是正确的，并且您认为 MSI 的学习曲线更陡峭，这是正确的。但两者都有其他人没有的功能。让我引用 Glytzhkof 来谈谈 MSI 的优势。
Glytzhkof 打招呼;-)。请务必阅读我在 serverfault.com 上的原始答案总结了由于 MSI 陡峭的学习曲线而导致的常见问题。这里的答案重点关注理论上的好处，其他答案（在同一线程中）总结常见的 MSI 问题就在我脑海中浮现。欢迎添加 - 我刚刚添加了最常见的问题。
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.
我迟到了回复这个话题。我多年来一直在我公司的产品中使用 Inno Setup。它可以很好地完成大多数事情，但对我来说最大的障碍是自定义操作。在 Inno Setup 中，必须使用 Pascal 语言的一种变体。借助 WiX 工具集，我可以并且确实使用 C# 来执行自定义操作，这对我来说更加舒适。诚然，这是个人偏好，但这是我从优秀的 Inno Setup 平台切换到同样优秀的 WiX 平台的主要原因。事实上，使用 MSI 有很多好处，这在另一个回复中已经提到过。
坦率地说，对我来说，使用《WiX 3.6：Windows Installer XML 开发人员指南》一书，Pascal 的学习曲线比 WiX 的学习曲线要长。
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.
我意识到这个答案来得很晚。但我看到这篇文章，认为这个问题的一个答案可能很简单：“为什么不两者兼而有之呢？” （吃蛋糕并拥有它）以及“当我只需花费精力购买一个并几乎免费获得第二个时，为什么要花费精力来实现两者呢？”
为此，我提出了一个带有 MSI 支持的 Inno Setup 脚本：
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-innosetup/yourapp.iss
这里使用了一些自定义的 Pascal 函数当在命令行上传递
/MSI={GUID}时启动，触发对脚本的有用更改（例如，“开始”或“添加/删除程序”中没有“卸载”图标）。我提供了一个 WiX 脚本，支持上述 Inno Setup 脚本：
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-wix/yourapp.wxs
WiX 脚本包装了基于 Inno Setup 的安装程序 EXE（唯一的有效负载）以触发 Inno Setup 脚本以更兼容 MSI 的方式执行操作并生成 MSI 的方式。它并不完美，但它可以让您以 Inno Setup 方式完成操作，然后轻松获得 MSI 的大部分优势（例如 GPO/SCCM/DSC 静默部署），从而节省大量时间。如果主要只是将文件部署到系统和少量注册表项（即基本应用程序），那么这种方法效果最好。对于有很多组件的大型应用程序，我不会推荐这种方法，但如果您尝试它并且它有效，请告诉我！拥有一个启动 Inno Setup EXE 的 MSI 版本至少可以为进行部署的系统管理员提供一些合理的参考。
请注意，WiX 脚本依赖于 Inno Setup 方面的自定义 Pascal 函数。您不能只使用任何 ol' Inno Setup 安装程序并将其与 WiX 脚本包装在一起并期望它能够工作（它可能不会）。但也许 Inno Setup 的未来版本将原生支持类似的功能。
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.
我们将两者集成到我们的构建系统中。
但出于一个简单的原因，我们决定仅按需向非商业客户和 msi 推广 innosetup exe 文件。
您无法使用 MSI 发送安装程序的多本地化版本。每种语言都需要一个安装程序，这很糟糕。可能存在一些严重的黑客攻击，允许您重写整个 GUI，但这没有很好的文档记录，也没有开源可以窃取，而且需要大量工作。
GUI 事实上是 WiX 上最糟糕的部分，否则它在技术上优于 Innosetup。
使用 Innosetup，可以轻松以 5 种语言发布一个 exe。我们已经有 6 个二进制文件 [免费、家庭版、专业版 - 每个 32/64 位]，因此变体爆炸将非常巨大，如果您销售带有日语网页的日语版本，那么首先出现的就是纯英文安装，它是不好的印象。
需要组策略等的商业用户的 MSI 只有英文，这对于商业用户来说很好。
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.