如何更好地利用 MSI 文件

发布于 2024-07-12 06:51:46 字数 371 浏览 6 评论 0原文

您可能知道,msiexec< /a> 是一个命令行应用程序,可用于安装 MSI 文件。 如您所知,您可以在静默或隐形模式下运行它。

如果安装程序要求用户回答有关要安装哪些部分的具体问题,是否可以通过某种方式在 msiexec 命令行中添加一系列选项来执行此操作?

我认为必须有某种方法来设置 MSI 文件的默认设置才能实现这一点。 MSI 文件是如何制作的? 它们是通过 Microsoft 的工具开发的吗? 它们可以打开和编辑吗?

As you might know, msiexec is a command line application that you can use to install an MSI file. As you might know, you can run it in silent or invisible mode.

If the installer requires the user to answer specific questions about what parts to install, is there some way that I can put in the msiexec command line a series of options to do this?

I figure there must be some sort of way of setting the MSI file's default settings to make this happen. How are MSI files made? Are they developed through tools from Microsoft? Can they be opened and edited?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

盗梦空间 2024-07-19 06:51:46

MSI 文件专门设计用于支持静默安装作为内置功能 - 您始终可以跳过 GUI。但是,某些 MSI 文件存在设计缺陷,导致静默模式下的安装不完整 -这是一个严重的设计错误。 此问题描述如下:


简短版本如何从 Electron 构建器参数化 msi 文件
- 使用公共属性和转换来自定义 MSI 包的安装。



配置 MSI 安装

在静默安装 MSI 时,您需要做的是从 msiexec.exe 命令行或通过对原始 MSI 文件应用所谓的转换来配置设置。 这两个选项在下面的单独部分中进行了描述。

如果 MSI 文件设计良好,您将能够从 msiexec.exe 命令行通过使用转换文件修改原始 MSI 来设置公共属性(它们始终为大写)。 这些操作描述如下。 公共属性最容易在 MSI 文件的“属性表"。 使用您选择的 MSI 工具打开 *.msi 文件 并导航到“属性”表。 您还可以使用一些免费 MSI 工具来生成转换和查看(和编辑)MSI 文件:如何比较两个(或更多)MSI 文件的内容?(指向底部的链接)。

精心设计的 MSI 设置可以通过这些公共属性进行完全配置。 设计不当的 MSI 文件则不然。 设计不当的 MSI 文件最好使用转换文件进行调整(这可以对整个 MSI 文件进行重大更改以在安装时应用)。 设置公共属性只能更改公共属性可配置的内容 - 由设置创建者设计。 转换几乎可以更改整个 MSI 文件中的任何内容

一般来说,所有企业静默部署都是使用转换来“将 MSI 文件打造成符合企业标准的形状”来完成的。它是一种非常有效的企业部署工具,并且被广泛使用。


几个用于安全保存的链接:


MSI“功能”

MSI 通常是违反直觉的,并且在幕后有些复杂。 然而,过度简化的 MSI 文件包含一个或多个“功能” - 正如您所说,这些功能共同构成“应用程序的位”。 反过来,功能由“组件”组成——它们是整个软件安装的原子单元——但这是一个非常技术性的细节——这个答案是关于 MSI 的用户公开位的——特点。

屏幕截图真正的 MSI 包中的功能是什么样的(屏幕截图)

您通常可以通过交互式运行安装程序来找到这些功能的列表,并导航到自定义安装对话框(并不总是存在)。 此处显示的功能是应用程序的“用户可配置”部分,可以选择排除或包含这些部分(有些是强制性的)。 您还可以通过使用上述功能强大的工具打开 MSI 来找到这些功能(您还可以查看下面第 2 部分中的链接)。

典型功能有:核心程序字典示例插件拼写检查器SDK & 开发者工具(用于开发工具)等...某些功能是强制性的(必须安装) - 上面的示例是核心程序 ,其他是可选的,应用程序启动不需要(如上面的开发工具功能)。 可以使应用程序“按需”安装功能 - 例如,当用户启动拼写检查时进行拼写检查。

根据我的经验,大多数用户都希望安装整个应用程序。如果 Windows Installer 意外弹出并开始安装拼写检查器组件,许多用户会非常恼火。 坦白说非常可以理解。 但是,只有少数用户感兴趣的很少使用的模块化组件可以制作成可选组件 - 特别是如果系统管理员可能不希望在其网络上使用该功能。 对于开发者工具来说,情况确实如此——这些工具不应该对普通用户可用。 它们往往是人们搬起石头砸自己脚所需的全部绳索。


如上所述,自定义 MSI 安装通常有两种方法:(1) 使用 msiexec.exe 自定义命令行,或使用 (2) 转换文件


1:msiexec.exe 命令行

控制安装过程中安装的功能的最简单且轻量级的方法是使用 msiexec.exe 指定您的功能选择命令行。 有一系列属性用于功能配置。 但是,在大多数情况下,指定ADDLOCAL就足够了:

msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" /qn

上面的命令行指定功能“Program”和“Dictionaries”应该是本地安装(功能名称区分大小写!)。 这通常就足够了,但您也可以以类似的方式使用 REMOVE 属性指定要删除的任何功能。 一个特殊的开关是 ADDLOCAL=ALL ,它将在本地磁盘上安装 MSI 中的所有功能(前提是 MSI 中没有额外的逻辑来覆盖它)。 MSDN 上的 ADDLOCAL 属性

由公共属性定义的一个非常常见的事情是应用程序的许可证密钥。 以下命令行指定安装功能“程序”和“词典”并应用序列号“1234-1234”:

msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn

正如上面的描述所暗示的, 每个设置的可自定义属性列表始终不同。 您可以找到 MSI 文件的属性表中列出的大多数属性,但也可能设置一些属性表中未定义的属性。 在大多数情况下,这与仅从设置 GUI 设置的属性相关(在大多数情况下表示设置设计错误)。 所有属性都应在正确编写的包的属性表中定义。

在供应商的下载页面上查找文档,并向他们的支持人员询问与静默安装或大规模部署相关的任何文档。 做起来很快,如果有标准答案模板,答案也可以很快。 能够控制其部署的公司始终能够提供此服务。 在我看来,理想的方法是使用一页 PDF 来描述不同的部署设置。 坦率地说,如果他们不能提供这一点,就给他们一些热度;-)。


2:转换

MSI 文件本质上是封装在 COM 结构化存储文件中的 SQL 数据库(文件内的文件系统)。 转换文件是通过安装工具构建的“部分数据库”,例如 Orca (SDK 链接),Installshield 或 Wise、高级安装程序等...(链接到不同工具的说明)。 这些转换可以自定义或覆盖 MSI 中的几乎所有设置或数据库字段 - 包括安装的“应用程序部分”(功能)。 创建转换后,您可以在 msiexec.exe 命令行中将其应用程序指定给 MSI:

msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn

然后,Windows Installer 将在安装开始之前合并 MSI 和转换。 这是希望完全控制 MSI 安装方式的大型组织使用的方法。 MSDN 上的 TRANSFORMS 属性

如上所述,该选项允许修改 MSI 中的所有设置。 可以对设计不当的 MSI 文件进行大量修复,以实现可靠的部署。 这是由“应用程序打包程序”完成的。 他们的工作是调整所有设置,使其符合公司标准。 他们可能是最有知识的 MSI 专家之一 - 他们在 MSI 文件中看到很多奇怪的东西。

许多工具可用于创建转换,以下是在比较 MSI 文件的更技术背景下对此类工具的描述。 只需直接跳到底部的免费工具列表:如何比较两个(或多个)MSI 文件的内容?


反模式与 Windows Installer 的企业优势:

Windows Installer 有许多设计怪癖并且可能对开发者来说特别烦人。 诚然,有些问题近乎反模式

潜在的反模式

  • 困难的多实例安装
    • 相对常见的要求,特别是对于服务安装
  • 违反直觉的服务安装文件覆盖规则 (赛门铁克)
    • 奇怪的规则,尤其是对于非版本化文件
    • 强制覆盖所有文件的疯狂功能(REINSTALLMODE = amus)
      • 可以在系统范围内降级共享文件
      • 可能会导致版本不一致,因为旧软件包可以在新软件包之后安装,并且仅降级某些共享文件
      • 可以降级或清除非版本化文件中的设置(以及注册表设置)
      • 由于尝试不必要地替换相同版本的正在使用的文件,可能会导致请求重新启动的次数显着增加。
      • 还有几个非常具体的问题。 有一天我会把它们全部写下来
  • 在升级后意外的重置用户数据在注册表中
    • 这是非常有问题的。 如果您遇到这种情况,那不是您的问题,而是技术的问题
    • 常见于服务凭证登录和序列号
    • 避免此问题的一些技巧
      • 避免从您的设置中写入任何 HKCU 注册表项,而是从您的应用程序中写入它们。 您的设置现在将永远不会干扰它们 - 它根本不知道这些值。
      • 将注册表数据放入其自己的功能中(应该可以防止自我修复出现问题)
      • 通过具有空组件 GUID 的组件安装注册表数据(这样在修复或自我修复期间将不会被重写)
      • 如果键路径存在,则将组件标志设置为永不覆盖。
      • 改用自定义操作将 HKLM 数据(例如许可证密钥)写入注册表(这会带来其他问题,但可以让您完全控制何时写入数据 - 采用何种安装模式)
      • 请务必确保保持稳定的注册表项路径。 设置标志值 KeyPath = 1 并且永远不要更改它 - 最重要的是 - 也不要更改组件 GUID
      • 切勿将 REINSTALLMODE 设置为“amus” - 当然不要在属性表中对该值进行硬编码。
      • 还有更多的技巧和经验法则,如果我能立即记住它们就好了:-)。
  • 复杂的升级机制
    • 次要升级有很多限制和限制
    • 主要升级还面临其他挑战(重置注册表数据、安装后丢失文件、安装后 COM 文件自我修复等...)
  • 缺乏 GUI 功能强>
    • 不是火箭科学,但有些复杂
    • 缺乏事件和功能来实现适当流畅的 GUI

  • 令人震惊复杂的修补
  • 自定义操作的实现极其复杂
    • 复杂测序
    • 复杂调理
    • 复杂的模拟/部分运行与提升的权限
    • 总体上极容易出错
  • 每用户设置实施乏善可陈
    • 概念上可疑(文件夹重定向、不可预测性、现实世界中的设置无法支持每用户和每台机器安装)
    • 升级、卸载和修补复杂。 允许为不同用户以及每台计算机多次安装产品​​
    • 我必须承认 - 主观上 - 我认为当前每用户设置的实现是一个完整的部署反模式。 我从不使用它,除非被迫,否则我坚持不使用它
  • 意外的自我修复
  • 缺乏写入 XML 文件的内置功能
  • IIS 安装的功能较差
    • 问题的一部分是未版本化文件的文件覆盖规则(可能出现不可预测的结果)。
    • 老实说,IIS 可能需要一种全新的部署技术 - 一种以完全可预测的方式定义非版本化文件处理的方法 - 具有合理的、现实的选项。 也许自动备份强制替换的非版本化文件,强制执行一致的文本文件组(“程序集”),这些文件必须是正确的版本,等等......
    • 还有一些与 IIS 以及虚拟文件夹和站点的复杂配置有关的其他问题
  • 在自定义操作上马虎地启用“检查退出代码”可能会导致无法升级或卸载软件包(无需认真调整)
    • 主要升级可能会失败并触发微不足道的回滚
    • 较小的升级可用于修复卸载顺序或错误的调节
  • 还有更多...

的问题实现自定义操作(自定义安装逻辑)的高度复杂性可以说是不可避免的,并且编写自定义操作的行为在需要时应该是强大的和有能力的 - 因此是复杂的。 如果技术本身提供了通常用于部署的内容,则很少需要自定义操作。 换句话说,您应该使用内置 MSI 功能,而不是自定义操作(如果可用),或者使用 WiX 或第三方部署软件扩展(如果可用)。

WiX 框架(开源)和商业工具等(Installshield、Advanced Installer 等)已经实现了扩展 Windows Installer 的功能,以处理缺失的功能,例如缺乏 XML 文件的升级机制、共享创建和管理、用户和组的创建、高级 IIS 配置、COM+ 安装、更改 ACL 权限、设置防火墙规则、持久安装属性等... 应该有实施自己的自定义操作的需求越来越少。 如果可以的话,始终使用数以千计的其他用户已经测试的功能(甚至数百万用户 - 这些扩展名是由可用的最佳部署专家编写的 - 您认为您可以自己做得更好吗?)。

Windows安装程序的公司优势(非常重要)

需要特定的心态来接近Windows安装程序。 但是,它提供了许多至关重要的公司福利几乎完全缺乏以前的安装技术。 使用MSI文件 建议阅读。 特别是对于那些认为Windows Installer的人比价值更大的麻烦。

简而言之,总结链接的文章, MSI比以前的部署技术的核心公司益处是(在我看来):

  • 可靠的无声跑步(具有标准化的,完全可抑制的GUI )
  • 隐式可用的卸载(与较旧的部署tecnologies的噩梦)
  • 冗长的记录 (尽管确实确实有帮助,但确实有帮助)
  • 可靠的远程管理
  • > 一个非常有益的功能 - 不再追逐隐藏的命令行选项)
  • 安装程序的半透明性(开放格式,除了汇编的cas除外)
  • 滚动 support(计算机)状态管理,防止部分部署,失败和倒退更改)
  • admin install (对于公司重新包装至关重要,以标准方式提取所有文件
  • ) strong>(基本上允许对企业部署进行完整的自定义),

这只是樱桃选择最重要的(经过多年的公司部署之后)。 在所有老实说中,这些功能在世界上(对于企业部署而言)都会有所不同,并且尽管它的所有缺陷 ,但MSI确实可以使用MSI。

Windows Installer的暮光之日安装

人员登上了暮光之城,我们只能希望未来的部署技术将保留这些伟大的公司部署福利,并以使每个人的方式和开发人员的方式处理上述的反模式。特别的。

部署是发展的关键部分未能成功为潜在的最终用户成功安装您的出色软件可能是整体软件开发中最昂贵的错误。,如果用户从未看到您的软件完全功能齐全,您该如何成功?

必须更好地处理Windows Installer的复杂性(减少),其关键优势必须在接下来的任何范式中正确保留。

一个相当不错的很好: Windows安装程序的摘要

云平台

所有这一切都有 ; 随着一般计算转移到云平台,部署世界可能会以不可预测的方式改变。 但是,正如著名的俗话说:变化越多,它们保持不变。 部署需要处理将在未来几十年中使用的所有传统技术。 这是有关为什么部署似乎变得更加复杂而又不太复杂的一篇文章 - 尽管有所有营销: 程序安装的好处和真正目的是什么?

看到部署的未来将是什么 - 在未来的几年中将是什么。 也许我们会看到家庭计算机的简化部署,而公司部署会比以往任何时候都更加复杂? 将来,大多数部署可能是数据库部署任务,而不是文件和文件夹部署任务。 到目前为止,由于数据库脚本,用户和组创建,共享设置和ACL许可,绩效计数器,防火墙规则更新,广告查询和更新,com+和消息队列配置,服务安装等... - 整个九码。


MSI files are designed specifically to support silent installation as a built-in feature - you can always skip the GUI. However, some MSI files have design flaws that render the install incomplete in silent mode - which is a serious design error. This problem is described here:


Short Version: How to parameterize msi file from electron builder
- using PUBLIC PROPERTIES and transforms to customize an installation of an MSI package.



Configuring MSI Installations

When it comes to installing an MSI silently, what you need to do is to configure the setup either from the msiexec.exe command line, or by applying what is referred to as a transform to the original MSI file. Both these options are described below in separate sections.

If the MSI file is well-designed you will be able to set PUBLIC PROPERTIES (they are always UPPERCASE) from the msiexec.exe command line or by using a transform file to modify the original MSI. These operations are described below. Public properties are easiest to find in the MSI file's "Property table". Use the MSI tool of your choice to open the *.msi file and navigate to the Property table. There are also some free MSI tools you can use to generate transforms and view (and edit) MSI files: How can I compare the content of two (or more) MSI files? (links towards bottom).

Well-designed MSI setups are fully configurable via these public properties. Badly designed MSI files are not. Badly designed MSI files are best to tweak using transform files (which can make substantial changes to the whole MSI file to apply at install time). Setting public properties can only change whatever is configurable by public properties - as designed by the setup creator. Transforms can change almost anything in the whole MSI file.

In general, all corporate, silent deployment is done using transforms to "beat MSI files into shape" for the corporate standard. It is a very effective tool for corporate deployment and is extensively used.


A couple of links for safe-keeping:


MSI "Features"

MSI is often counterintuitive and somewhat complicated under the hood. However, to over-simplify an MSI file contains one or more "Features" - and these features collectively constitute the "bits of the application" as you put it. Features, in turn, consist of "Components" - which are the atomic units of installation for the whole software - but this is a very technical detail - this answer is about the user-exposed bits of MSI - the features.

Screen Shots: What Features look like in a real MSI package (screen shots).

You can generally find a list of these features by running the setup interactively, and navigate to the customize install dialog (not always present). Features that show up here are the "user configurable" parts of the application that can be chosen for exclusion or inclusion (some are mandatory). You can also find these features by opening an MSI with a capable tool as mentioned above (you can also see links in section 2 below).

Typical features are: Core or Program, Dictionaries, Samples, Plug-Ins, Spell Checker, SDK & Developer Tools (for dev tools), etc... Some features are mandatory (must be installed) - examples above would be Core and Program, others are optional and are not needed for the application to launch (like the dev tools features above). It is possible to make the application install features "on demand" - for example spell checkers when the user initiates a spell check.

In my experience most users want the whole application installed. Many users are very annoyed if Windows Installer pops up unexpectedly and starts installing spell checker components. Frankly very understandable. However, rarely used modular components interesting only to a few users could be made into optional components - especially if system administrators may not want the feature available on their network. This is certainly the case for developer tools - these should not be available to regular users. They tend to be all the rope people need to shoot themselves in the foot.


As mentioned above, there are generally two ways to customize an MSI installation: (1) using msiexec.exe custom command lines, or using (2) transform files.


1: msiexec.exe command line:

The simplest and light-weight way of controlling what features are installed during an installation, is to specify your feature selection using the msiexec.exe command line. There is a whole family of properties used for feature configuration. But, in most cases it is sufficient to specify ADDLOCAL:

msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" /qn

The above command line specifies that the features "Program" and "Dictionaries" should be installed locally (feature names are cases-sensitive!). This is generally enough, but you can also specify any features that you want to remove using the REMOVE property in a similar fashion. A special switch is ADDLOCAL=ALL which will install all features in the MSI on the local disk (provided there is not additional logic in the MSI to override this). ADDLOCAL property on MSDN.

A very common thing to define by public properties is the license key for the application. The following command line specifies to install the features "Program" and "Dictionaries" and to apply the serial key "1234-1234":

msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn

As is implied in the description above, the list of customizable properties for each setup is always different. You can find most properties listed in the MSI file's Property table, but it is also possible that some properties can be set that are not defined in the Property table. In most cases this relates to properties being set only from the setup GUI (indicates a setup design error in most cases). All properties should be defined in the property table in a properly authored package.

Look for documentation on the vendor's download page and ask their support for any documents relating to silent installation or large scale deployment. It is quick to do, and answers can be quick if they have standard answer templates. Companies with control of their deployment will always be able to provide this. In my view the ideal way is a one-page PDF which describes different deployment settings. Frankly, give them some heat if they can't provide this ;-).


2: Transforms:

MSI files are essentially SQL-databases wrapped in COM structured storage files (file system within a file). Transform files are "partial databases" constructed via installation tools such as Orca (SDK link), Installshield or Wise, Advanced Installer, etc... (link to descriptions of the different tools). These transforms can customize or override almost all settings or database fields in an MSI - including what "parts of the application" (features) are installed. After creating a transform you specify its application to the MSI at the msiexec.exe command line:

msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn

Windows Installer will then merge the MSI and the transform before installation starts. This is the approach used by large organizations who want full control of how the MSI gets installed. TRANSFORMS property on MSDN.

As mentioned above this is the option that allows all settings in an MSI to be modified. Substantial fixes can be applied to badly designed MSI files to allow reliable deployment. This is done by "application packagers". Their job is to tune all setups to work within the corporate standard. They can be among the most knowledgeable MSI specialists around - they see a lot of weird stuff in MSI files.

Many tools can be used to create a transform, here is a description of such tools inside the more technical context of comparing MSI files. Just jump straight to the list of free tools at the bottom: How can I compare the content of two (or more) MSI files?


Anti-Patterns Vs The Corporate Benefits of Windows Installer:

Windows Installer has many design quirks and may be particularly annoying for developers. Admittedly there are some issues that border on anti-patterns.

Potential Anti-Patterns

  • Difficult multi-instance installations
    • Relatively common requirement, especially for service installations
  • counter-intuitive file overwrite rules (symantec)
    • strange rules, especially for non-versioned files
    • an insane feature to force overwrite all files (REINSTALLMODE = amus)
      • can downgrade shared files system-wide
      • can cause inconsistent version estate since an old package can be installed after a newer one and downgrade only some of the shared files
      • can downgrade or wipe-out settings in non-versioned files (and registry settings)
      • can cause a significant increase in the number of requested reboots due to attempts to needlessly replace in-use files of the same version.
      • there are several further issues that are quite specific. One day I will write them all up
  • unexpected reset user data in the registry after upgrades
    • This is extremely problematic. If you experience this it is not you, it is the technology
    • Often seen with service credentials logins and serial keys
    • Some techniques to avoid this problem
      • avoid writing ANY HKCU registry keys from your setup, write them from your application instead. Your setup will now never interfere with them - it has no knowledge of the values at all.
      • putting registry data in a feature of its own (should prevent problems on self-repair)
      • install registry data via a component with empty component GUID (will then not ever be rewritten during repair or self-repair)
      • set component flag to never overwrite if key-path exists.
      • write HKLM data (such as license keys) to the registry using a custom action instead (this has other problems, but will give you complete control of when data is written - in what installation mode)
      • make darn sure you keep a stable registry key path. Set a flag value KeyPath = 1 and never change it - and crucially - don't change the component GUID either
      • never set REINSTALLMODE to "amus" - certainly not hard code that value in the property table.
      • there are further tricks and rules of thumb, if only I could remember them all off the top of my head :-).
  • complex upgrade mechanism
    • minor upgrades has a lot of limitations and restrictions
    • major upgrades have other challenges (reset registry data, missing files after install, self-repair for COM files after install, etc...)
  • lackluster GUI features
    • not rocket science, but somewhat complex
    • lacking events and features to implement a properly smooth GUI
  • shockingly complicated patching
  • extremely complicated implementation of custom actions
    • complex sequencing
    • complex conditioning
    • complex impersonation / partial running with elevated rights
    • overall extremely error prone.
  • the lackluster implementation of per-user setups
    • conceptually dubious (folder redirects, unpredictability, impossibility of making setups in the real world support both per-user and per-machine installs)
    • complex to upgrade, uninstall and patch. Allows products to be installed multiple times for different users AND also per-machine
    • I have to admit - on a subjective note - that I deem the current implementation of per-user setup a full on deployment anti-pattern. I never use it and insist not to unless forced to.
  • unexpected self-repair
  • the lack of built-in features to write to XML files
  • poor features for IIS installs
    • part of the issue is the file overwrite rules for unversioned files (unpredictable results possible).
    • IIS may need a brand new deployment technology altogether to be honest - a way to define handling of non-versioned files in a totally predictable fashion - with sensible, real-world options. Perhaps auto-backup of force-replaced non-versioned files, enforcing of groups of consistent text files ("assemblies") that have to be correct version all of them, etc...
    • also several other issues with the complex configuration of IIS and virtual folders and sites
  • sloppy enabling of "check exit code" on custom actions can cause packages that are not possible to upgrade or uninstall (without serious tweaking)
    • major upgrades may fail and trigger rollback for something insignificant
    • a minor upgrade can be used to fix the uninstall sequence or the faulty conditioning
  • there are a few more...
    • In fact I wrote up a sprawling summary of commonly seen anti-patterns often seen in real-world MSI packages themselves (erroneous use of the technology): How do I avoid common design flaws in my WiX / MSI deployment solution?
    • I can stand by all the content, but the format is not great - it is a messy brain dump, but sometimes that seems to be the only way to get things done. Take it for what it is.
    • Overuse of custom actions is another MSI problem. There is a core of complexity behind this, but overall the problem is that people don't use fully functional pre-existing solutions in MSI or via extensions such as WiX (or commercial tools such as Installshield or Advanced Installer). Here is a summary: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?

The issue of high complexity of implementing custom actions (custom installation logic), could be argued to be unavoidable and the act of writing a custom action should be powerful and capable once needed - and hence complicated. Rarely should custom actions be needed if the technology itself offers what is commonly used for deployment. In other words you should use built-in MSI features rather than custom actions if they are available, or WiX or third party deployment software extension when available.

The WiX framework (open source) and commercial tools alike (Installshield, Advanced Installer, etc...) have implemented features to extend Windows Installer to deal with missing features such as the lack of an upgrade mechanism for XML files, share creation and management, creation of users and groups, advanced IIS configuration, COM+ installations, changing ACL permissions, setting firewall rules, persisting installation properties, etc... There should be less and less need to implement your own custom actions. Always use the features that are already tested by thousands of other users if you can (millions of users even - and these extensions have been written by the best deployment experts available - do you think you can do it better on your own?).

The Corporate Benefits of Windows Installer (very significant)

It requires a specific mindset to approach Windows Installer. However, it provides a number of crucial corporate benefits that were almost entirely lacking in previous installation technologies. The corporate benefits of using MSI files is recommended reading. Particularly for those who think Windows Installer is more trouble than it is worth.

To summarize the linked article in brief, the core corporate benefits of MSI over previous deployment technologies are (in my opinion):

  • the reliable silent running (with standardized, completely suppressible GUI)
  • the implicitly available uninstall (a nightmare with older deployment tecnologies)
  • the verbose logging (can be helpful, though really verbose indeed)
  • the reliable remote management (in effect the overall benefit altogether - the combined effect of all other listed benefits of sorts)
  • the elevated install rights (no messy temporary admin rights)
  • the standardized command line (a hugely beneficial feature - no more chasing hidden command line options)
  • the installer's semi-transparent nature (open format, except compiled CAs which are black box)
  • the rollback support (computer state management, prevent partial deployments, fail and roll back changes)
  • the admin install (essential for corporate repackaging, extracts all files in a standard way)
  • the standard package customization approach (transforms) (basically allows complete customization for corporate deployment)

That's just to cherry pick the most important ones (after many years doing corporate deployment). In all honesty these features make all the difference in the world (for corporate deployment) and truly makes MSI great to use despite all its flaws.

The Twilight Years Of Windows Installer

As Windows Installer hits its twilight years, we can only hope that the deployment technologies of the future will preserve these great corporate deployment benefits and deal with the mentioned anti-patterns in a way that benefits everyone, and developers in particular.

Deployment is a crucial part of development. Failing to get your great software successfully installed for your potential end users may be the most expensive mistake to make in software development overall. How can you succeed if the user never sees your software fully functional?

Windows Installer's complexity must be handled better (reduced), and its crucial benefits must be preserved properly in whatever paradigm comes next.

A reasonably good: summary of Windows Installer.

Cloud Platforms

With all this said; as computing in general moves to cloud-platforms, the world of deployment is likely to change considerable in unpredictable ways. However, as the famous saying goes: the more things change, the more they stay the same. Deployment needs to deal with all legacy technology that will be in use in companies for decades to come. Here is a piece on why deployment seems to get more complicated and not less complicated - despite all the marketing: What is the benefit and real purpose of program installation?.

It will be interesting to see what the future of deployment will be - in the years to come. Perhaps we will see simplified deployment for home computers, and corporate deployment will become more complicated than ever? In the future most deployment will probably be a database deployment task more than a file and folder deployment task. Server deployment can be extremely complicated as of now with database scripts, user and group creation, share setup and ACL permissioning, performance counters, firewall rules updates, AD queries and updates, COM+ and message queue configuration, service installation, etc... - the whole nine yards.


倒带 2024-07-19 06:51:46

将带有 MSI 的用户界面视为可选。 这意味着不需要任何答案,因为开发人员已经设置了合理的默认值,这样就不会出现问题。

我们以 MSI 格式向企业客户分发软件,我还为他们提供有关 Orca 基础知识的文档(orca.msiWindows Installer SDK)以及如何自定义我们在<中列出的某些字段其安装的 code>Property 表。 例如序列号、注册详细信息和一些其他设置。

为了回答有关 msiexec 命令行选项 的原始问题,只需运行 MSIEXEC /? 在命令行上设置属性,您将使用类似的内容

MSIEXEC /I test.msi SOMEPROPERTY="Some value" PROP2="something else"

Think of the user interface with MSI as optional. This means no answers should be required as the developer has sensible defaults in place so that things don't break.

We distribute our software in MSI format to corporate customers, I also provide them with documentation on the basics of Orca (orca.msi is distributed with the Windows Installer SDK) and how to customize certain fields we have listed in the Property table for their installation. Such as serial number, registration details and a few other settings.

In response to the original question about msiexec command line options just run MSIEXEC /? to set properties on the command line you would use something like

MSIEXEC /I test.msi SOMEPROPERTY="Some value" PROP2="something else"
別甾虛僞 2024-07-19 06:51:46

如何配置静默 MSI 安装

可以通过设置安装程序使用的属性在命令行上配置 MSI 安装。 有预定义的 Windows Installer 属性,例如 ALLUSERS 属性。 此属性定义是否在当前用户或计算机的上下文中完成安装。

有关可用属性的信息可以从安装日志中获取,该安装日志可以使用 msiexec 的 /l 选项创建

msiexec /I mysetup.msi /l*vx log.txt

如何创建 MSI 文件

创建 MSI 文件的方法有多种。 MSI 文件基本上是一个数据库,由各种表组成,其中包含所有必要的设置信息和安装对话框。

Microsoft 提供了一个简单的工具调用 Orca,它使您能够编辑现有的 MSI 文件并允许您查找可以设置哪些属性来配置安装。 理论上,也可以使用此工具创建新的 MSI 文件,但这是一种非常麻烦的方法。

如果您正在寻找免费的开源解决方案,我建议您查看 WiX 工具集在 SourceForge 或 Nullsoft 上可用。 所有安装信息均通过 XML 文件完成,然后将其转换为 MSI 安装程序。 WiX 很稳定(尽管仍标记为测试版)并且可以在生产中使用。 实际上,它将集成在即将推出的 Visual Studio 2010 版本中。

当然,也有可用的商业解决方案,InstallShield 是市场领导者(也是价格领导者),而 Visual Studio 可能是最广泛使用的工具。

How to configure silent MSI setup

An MSI installation can be configured on the command line by setting the properties that the installer uses. There are pre-defined Windows Installer properties such as the ALLUSERS property. This property defines whether an installation will be done in the context of the current user or the machine.

Information on the available properties can e.g. be obtained from an install log which can be created using msiexec's /l option

msiexec /I mysetup.msi /l*vx log.txt

How to create MSI files

There are many ways to create MSI files. An MSI file is basically a database consisting of various tables containing all necessary setup information and installation dialogs.

Microsoft offers a simple tool call Orca which enables you to edit existing MSI files and allows you to find out which properties can be set to configure an installation. Theoretically it is also possible to create new MSI files using this tool but it is a very cumbersome way to go.

If you are looking for a free and open source solution I would recommend you to have a look at the WiX toolset available on SourceForge or the Nullsoft . All setup information is done via XML files which are then converted into an MSI installer. WiX is stable (although still tagged beta) and can be used in production. Actually it will be integrated in the upcoming version of Visual Studio 2010.

Of course there are also commercial solutions available, InstallShield being the market leader (also being the price leader) and Visual Studio probably being the most wide-spread tool.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文