未安装新组件的文件，因为旧组件具有相同的文件 [英] File of a new component isn't installed because there was an old component with the same file
问题描述
我们有一个问题，即重大更新时未安装 fie
We have a problem that a fie is not installed upon a major update
- 我们有一个重大更新
<MajorUpgrade Schedule="afterInstallInitialize"... - 我们是一个旧组件，其中包含来自外部制造商的 1 个文件(xyz.exe 版本 12.34)
- 我们现在有一个来自新制造商的名称相同的新文件(xyz.exe 版本 2.34).新文件的版本号低于旧文件.
- 我们在安装包中创建了一个新组件并删除了旧组件(实际上我们给了它一个新的 guid)
- 无法更改 exe 的名称，这会对文档和内部功能产生很大影响.
在正常安装时一切正常.
On a normal installation everything is OK.
但是现在更新时会发生什么:
But what happens now on an update:
- 安装程序启动.
- 并检测到新组件(xyz.exe)存在，版本较低，所以不会安装.
- 安装程序运行并删除旧组件
- 但它没有安装新的，因为它刚刚检测到该组件已经安装.
- 进行修复安装修复了问题，然后文件又出现了.
设置组件的 KeyPath 解决了这个问题.但这对我来说是错误的.这个文件的安装目录就是主安装目录.
Setting the KeyPath to the Component fixes the problem. But it seams wrong to me. The directory where this file is installed is the main installation directory.
如何强制安装这个组件?
How to force the installation of this component?
推荐答案
主要升级降级:为了在主要升级时覆盖具有更高版本号的二进制文件，有几个首选选项:
Major Upgrade Downgrade: In order to overwrite binaries with higher version numbers on major upgrades there are a couple of preferred options:
- 首选方法是使用配套文件(第三方文件).
- 或者，如果您可以:编译具有更高版本号的新二进制文件(用于您自己的文件).
- The preferred approach would be to use a companion file (third party files).
- Or if you can: compile a new binary with a higher version number (for your own files).
配套文件:下面是关于如何使用 伴随文件:
<..>
<Component Id="MyFile.exe" Feature="Main">
<File Id="MyFile.exe" Source="MyFile.exe"></File>
</Component>
<!-- Do not re-use any GUIDs in your own sources! (very important) -->
<Component Id="MyFile_2.exe" Guid="{00000000-0000-0000-0000-3D82EA2A99AF}" Feature="Main">
<File Source="MyFile_2.exe" CompanionFile="MyFile.exe"></File>
</Component>
<..>
单行摘要:在第二个组件中，我们指向第一个组件的文件，以便 MyFile_2.exe 将在安装 MyFile.exe 时安装 - 无论版本问题如何.
One-Line Summary: In the second component we point to the first component's file so that MyFile_2.exe will install whenever MyFile.exe is installed - regardless of versioning issues.
然后有许多进一步的选择:
Then there are a number of further options:
REINSTALLMODE:MSI 属性 REINSTALLMODE 可以使用 - 但它有许多副作用:
REINSTALLMODE: The MSI property REINSTALLMODE can be used - but it has a number of side-effects:
设置 1:用于设置的版本 1.0.0:
msiexec.exe /i Setup1.msi /qn
Setup 2:主要升级设置的2.0.0版本:
Setup 2: Version 2.0.0 for the major upgrade setup:
msiexec.exe /i Setup2.msi REINSTALLMODE=amus /qn
几个问题:REINSTALLMODE 存在几个问题，使其成为使用不安全的功能(尝试 emus 代替?查看文档 - 可能会少一些蛮力).遗憾的是，此设置适用于设置中的所有功能 - 这使其非常危险:
Several Problems: There are several issues with REINSTALLMODE that makes it an unsafe feature to use (try emus instead? See documentation - a little less brute force maybe). It is a shame that this setting applies to all features in the setup - that makes it very dangerous:
- 可以在系统范围内降级共享文件 - 如果包含合并模块 - 例如(Windows 中的功能可以防止大部分此类问题:WFP 和 WRP 在 Vista 和超越 - 非 Microsoft 合并模块仍然会导致非 Microsoft 共享文件出现问题)
- 可能会导致版本资产不一致，因为旧包可以在新包之后安装，并且只能降级部分共享文件
- 可以降级或清除非版本文件和注册表设置中的设置(自我提示:再次测试，组件设置很复杂)
- 可能会由于尝试不必要地替换相同版本的使用中的文件而导致请求重新启动的次数显着增加(真正的解决方法是正确关闭服务并使用 重启管理器 允许在部署期间自动关闭应用程序 - 关于文件锁).
- 还有几个非常具体的问题
- can downgrade shared files system-wide - if there are merge modules included - for example (features in Windows are in place to prevent most of this problem: WFP and WRP in Vista an beyond - non-Microsoft merge modules can still cause problems for non-Microsoft shared files)
- 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 (note to self: test this again, there are complexities with component 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 (the real fix for this is to shut down services properly and to use the restart manager to allow applications to be shut down automatically during deployment - on file locks).
- there are several further issues that are quite specific
Hack 二进制版本:丑陋但有效选项是使用 Visual Studio 更改实际二进制文件的版本以设置更高的版本号(您将二进制文件作为资源打开并设置新版本 - 这显然与使用 Visual Studio 编译新版本的二进制文件非常不同源代码编译).有几个副作用:
Hack Binary Version: An ugly, but effective option is to change the version of the actual binary file using Visual Studio to set a higher version number (you open the binary as a resource and set a new version - this is obviously very different from compiling a new version of the binary using visual studio source code compilation). There are several side effects:
- 你破坏了数字签名
- 你可以制造版本混淆"
- 从 Visual Studio 编写新的二进制文件存在风险
- 这是一个hack 手动步骤"；- 对于新版本，您可能需要继续这样做吗?
- 等等...
移动、重命名:如果您可以通过重命名或移动将新文件与旧文件分离，您就可以解决问题.如果您将来再次获得新版本，则可能必须再次执行此操作.笨重.
Move, Rename: If you can de-couple the new file from the old by renaming it or moving it you can work around the problem. If you get a new version again for the future, you might have to do this again. Clunky.
加载自":将文件放在共享位置并从该特定位置加载并从安装文件夹中删除旧副本.那能行吗?这意味着该文件也可以由该位置的其他设置传送.
"Load From": Putting the file somewhere shared and load it from that specific location and removing the old copy from your installation folder. Could that work? This means the file could also be delivered by another setup at that location.
版本谎言:Installshield 中有一个概念，可以为文件设置特定的版本号.我不确定如何在 WiX 中实现它.还有一个总是覆盖选项"，显然为版本设置了最大值，因此现有文件总是被覆盖.
Version Lying: In Installshield there is a concept of being able to set a specific version number to a file. I am not sure how to implement that in WiX. There is also an "always overwrite option" that apparently sets a maximum value for the version so the existing file is always overwritten.
一些链接:
- 为什么 Windows Installer 在重大升级期间删除文件，如果它们的版本号倒退
- 降级"MS dll 在升级时消失 - Windows Installer
- 安装文件而不管版本号与 WiX
- 如何更好地利用 MSI 文件
- 相反:文件保存和文件覆盖规则.
这篇关于未安装新组件的文件，因为旧组件具有相同的文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
