Question

我一直在尝试设置WiX组件，以便用户可以指定安装程序不应在MajorUpgrade上升级该组件。我有以下代码，但这意味着如果满足条件，则不会安装新版本，但旧版本也会被删除。

<Component Id="ExampleComponent" GUID="{GUID here}">
  <Condition>NOT(KEEPOLDFILE="TRUE")</Condition>
  <File Id="ExampleFile" Name="File.txt" KeyPath="yes" Source="File.txt"/>
</Component>

理想情况下，如果用户指定＆＃34; KEEPOLDFILE = TRUE＆＃34;，则现有版本的＆＃34; File.txt＆＃34;应该保留。我已经研究过使用Permanent属性，但这看起来并不相关。

这可以在不使用CustomActions的情况下实现吗？

Answer 1

然而，更多背景信息会很有用：

如果您的主要升级提前排序（例如afterInstallInitialize），则升级是卸载，然后是全新安装，因此保存文件是一个棘手的主张，因为您要保存它，然后执行新安装，然后恢复它。
如果升级延迟，则在升级过程中会应用文件覆盖规则，因此无论如何都不会替换它。您需要执行诸如创建和修改时间戳相同的操作，以便Windows将使用新的覆盖它。在这种情况下，解决方案是运行以“保留旧文件”为条件的自定义操作，因此您可以执行相反的操作：

https://blogs.msdn.microsoft.com/astebner/2013/05/23/updating-the-last-modified-time-to-prevent-windows-installer-from-updating-an-unversioned-file/

并且还不清楚该文件是否总是更新，所以如果实际上它还没有更新那么为什么还要问客户是否要保留它？

通过将其组件ID设置为null来忽略Windows Installer行为可能更简单，如下所示：

https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx

然后你可以用文件做你想做的事。如果您已经使用组件guid安装它，那么这个解决方案已经太晚了。

有更好的解决方案需要应用程序参与安装此文件的模板版本。该应用程序制作了它始终使用的副本。在升级时，模板文件总是被替换，当应用程序在升级后首次运行时，它会询问是否使用新文件（因此它会复制并覆盖它正在使用的文件）或继续使用现有文件。在我看来，将这些问题委托给安装通常不是最佳解决方案。

设置像Permanent这样的属性通常不是一个好主意，因为它们不是您可以随意打开和关闭的项目属性 - 它们适用于系统上的组件ID，而永久性意味着永久性。

Answer 2

我试图将此作为评论，它变得很长。我更喜欢Phil描述的选项4 。数据文件不应由设置干预，而是由其应用程序exe（如果有）在其启动序列期间进行管理。我不知道其他人，但我觉得这是一个重复这个建议的破纪录，但听我们说...

There is a description of a way to manage your data file's overwriting or preservation here。基本上，您更新您的exe以“了解”您的数据文件应该如何管理 - 如果它应该被保留或覆盖，并且您可以根据需要更改每个版本的appliation exe的此行为。链接的线程描述了注册表项，但该概念也可用于文件。

基本上是这样的：

模板：将每台计算机的文件安装为只读模板
启动序列 ：使用application.exe启动序列魔法将其复制到位
复杂文件修订 ：根据the linked thread提议的行，更新每个版本的文件覆盖或保存逻辑

您的设置“永远不会知道”您的数据文件，只有模板文件。在所有情况下，它都会保留您的数据文件。只有它将处理的模板文件。

从设置中解放数据文件有很多优点：

Setup.exe错误 ：没有意外的意外文件覆盖或文件重置问题从有问题的主要升级等...这是MSI的一个非常常见的问题。
- 设置错误很难重现和调试，因为目标系统上的条件通常无法复制，调试涉及很多不寻常的技术复杂性。
- 这不是很好 - 它很混乱 - 但是这里列出了常见的MSI问题：How do I avoid common design flaws in my WiX / MSI deployment solution? - “为了帮助解决问题而做出的最大努力”。老实说，这是一团糟，但也许它很有帮助。
Application.exe错误 ：请记住，您可以在application.exe文件中创建新错误，这样您仍然可以看到错误 - 显然。也不好 - 如果你不小心 - 但你也可以很容易地实现一个备份功能 - 一个总是在可预测的上下文中运行的功能。
- 您可以避免复杂的排序，条件和模拟关注使自定义操作和现代设置变得如此复杂以至于做得正确并且可靠。
- 根据其他技术和实际原因： 调试应用程序启动顺序中的问题要比设置中的错误 容易得多。
  - 您可以轻松设置测试条件并以交互方式测试它们。换句话说，您可以轻松地重新创建问题条件并在几秒钟内测试它们。使用设置可能需要数小时才能完成。
  - 错误消息可以是交互式且有意义的，并向用户显示。
  - QA人员比设置功能更熟悉测试应用程序功能。
  - 我重复一遍：你总是处于相同的模拟环境（用户环境）中，你无需担心安装顺序。

（可选）在升级

2 个答案: