在 wix 中更改我的组件 GUID? [英] Change my component GUID in wix?

问题描述

我应该何时更改或不更改 WIX 中的组件 GUID? Microsoft SDK 信息混乱.

Glytzhkof 编辑:澄清一下，问题涉及何时应为 MSI 组件更改组件 GUID.组件可能会随着以下方面的变化而变化:更改的目标路径、向/从同一组件添加或删除文件、添加注册表数据等……这会导致所谓的组件引用出现问题，即 在 MSI 中创建组件的最佳实践.

解决方案

MSI 的总体概念是在 MSI 之间存在 1:1 映射组件 GUID(唯一标识符)和绝对路径(安装位置/关键路径).完整路径，包括文件名，如果任何.请参阅下面的更新以了解新的 Wix 功能以自动神奇地处理有了这个.

---

Rob Mensching(WiX 作者):

• Windows Installer 组件规则 101
• Windows Installer 组件介绍

关于组件规则的更多信息:

• 将应用程序组织成组件
• 创建组件的最佳实践.

---

我使用一些简单的规则来处理过于复杂且违反直觉的组件规则(特别是对于开发人员而不是部署专家):

• 始终为每个文件使用单独的组件(即使对于非二进制文件).这样就避免了各种问题.有一些例外:
  • 多文件 .NET 程序集都应该在一个组件中，因为它们应该始终作为一个单元安装/卸载.
  • 其他一些一般文件类型属于匹配对" - 它们属于一起.通常这些是内容和索引文件.例如，考虑 Microsoft 帮助文件:
    • .HLP 和 .CNT 文件属于一起.
    • .CHM 和 .CHI 文件属于一起.
  • 可能有几个这样的文件类型属于一起，因此应该放在同一个组件中，以便它们一起安装/卸载 - 我怀疑某些证书文件是候选文件.很难想出一个明确的清单.简单地问问自己这些文件是否总是属于一起的" - 所以只要有新版本，它们总是成对出现?如果是，则通过相同的组件安装它们.将版本化文件(如果有)设置为密钥文件.
  • 我想添加驱动程序文件作为一组始终属于一起的文件的示例:SampleDriver.cat、SampleDriver.inf、SampleDriver.sys、SampleDriver.cer.它们必须全部匹配为一个单元".用于部署.
• 请记住，一旦为组件分配了 GUID，它就会为该组件的关键路径(绝对路径)设置成石头.如果您将文件移动到新位置或重命名文件，请为其指定一个新的组件 GUID(因为绝对路径不同，因此实际上是一个新标识).
• 总而言之，组件 GUID 与绝对安装位置相关，而不与特定文件相关.如果文件移动，GUID 不会跟随文件.GUID 引用计数的是绝对位置，而不是文件本身.
• 不要在现有组件中添加或删除文件.各种升级和补丁问题导致.这就是为什么我喜欢每个组件一个文件作为一般规则.
• 组件引用还有很多内容，但我将把它留在概述"中.

一些示例:

• 您将文件 C:Program FilesMyCompanyMyAppMyFile.exe 重命名为 C:Program FilesMyCompanyMyAppMyFile_NEW.exe.这对组件创建意味着什么?这是一个新的绝对安装路径，因此您为托管组件生成一个新的 GUID，或者您添加一个新组件并删除旧组件(具有相同的效果).
• 您更新后的 MSI 提供了新版本的 MyFile.exe.位置与之前相同，这意味着组件 GUID 不应更改.这是同一个文件(身份)，只是版本不同.

---

<块引用>

更新:

<块引用>

自动组件 GUID:WIX 现在有一个新的 自动生成组件 GUID 功能，计算一个GUID只要目标路径保持不变.老实说，我还没有尝试过，但很多人似乎使用它没有问题，并且 Rob Mensching(Wix 作者)表示正常使用是安全的.作为一个概念，我强烈推荐这个因为它具有一些自动魔法并保护您免受某些复杂性.

最小 WiX 标记:另请注意，您可以离开从中取出很多源属性您的 Wix xml 文件 并依赖 Wix 默认值而不是硬编码值.

When should I change or not change my component GUID in WIX? The Microsoft SDK information is confusing.

Glytzhkof edit: To clarify, the question deals with when a component GUID should be changed for an MSI component. A component can change with aspects such as: changed destination path, addition or removal of files to/from the same component, addition of registry data etc... This causes problems with regards to the so called component referencing, i.e the best practice for creating components in MSI.

解决方案

The overall concept of MSI is that there is a 1:1 mapping between a component GUID (unique identifier) and an absolute path (install location / key path). The full path, including file name if any. See update below for a new Wix feature to deal auto-magically with this.

---

Rob Mensching (WiX author):

• Windows Installer Component Rules 101
• Windows Installer Components Introduction

More on Component Rules:

• Organizing Applications into Components
• Best Practice for Creating Components.

---

I use some simple rules to deal with the overly complex and rather counterintuitive component rules (especially for developers as opposed to deployment specialists):

• Always use a separate component per file (even for non-binaries). This avoids all kinds of problems. There are a few exceptions:
  • Multi-file .NET assemblies should all be in one component since they should always be installed / uninstalled as a single unit.
  • A few other, general file types come in "matching pairs" - they belong together. Often these are content and index files. As an example consider Microsoft help files:
    • .HLP and .CNT files belong together.
    • .CHM and .CHI files belong together.
  • There are likely several such file types that belong together and should hence be put in the same component so they install/uninstall together - I suspect certain certificate files to be candidates. It is hard to come up with a definite list. Simply ask yourself "do these files always belong together" - so they always show up in pairs whenever there is a new version? If yes, then install them via the same component. Set the versioned file, if any, as key file.
  • I want to add driver files as an example of a bunch of files always belonging together: SampleDriver.cat, SampleDriver.inf, SampleDriver.sys, SampleDriver.cer. They must all match as a "unit" for deployment.
• Remember that once you have allocated a GUID for a component, it's set in stone for that component's key path (absolute path). If you move the file to a new location or rename the file, give it a new component GUID (since the absolute path is different it's effectively a new identity).
• In summary component GUIDs are tied to an absolute installation location, and not to a specific file. The GUID doesn't follow the file around if it moves. The GUID reference counts an absolute location, not the file per se.
• Do not add or remove files from an existing component. All sorts of upgrade and patching problems result. This is why I like one file per component as a general rule.
• There is a lot more to component referencing, but I will leave it at that for an "overview".

Some samples:

• You rename the file C:Program FilesMyCompanyMyAppMyFile.exe to C:Program FilesMyCompanyMyAppMyFile_NEW.exe. What does this mean for component creation? This is a new absolute installation path, so you generate a new GUID for the hosting component, OR you add a new component and delete the old one (which has the same effect).
• Your updated MSI delivers a new version of MyFile.exe. The location is the same as before, this means the component GUID should not change. It is the same file (identity), just in a different version.

---

UPDATE:

Auto Component-GUIDs: WIX now has a new auto-generate component GUID feature that calculates a GUID as long as the target path stays the same. I have not tried this out to be honest, but many seem to use it without problems, and Rob Mensching (Wix author) states it is safe for normal use. As a concept I highly recommend this since it features some auto-magic and shields you from some complexity.

Minimal WiX Markup: Also note that you can leave out a lot of source attributes from your Wix xml file and rely on Wix defaults instead of hard coding values.

这篇关于在 wix 中更改我的组件 GUID?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！