主要升级 - .exe 文件未重新安装
我有一个由名为 MSICREATE 的程序创建的 .msi 文件，并使用 orca 进行了修改，如下所示...
InstallExecuteSequence 表
* added FindRelatedProducts with sequence 410
* added RemoveExistingProducts with sequence 1450
InstallUISequence 表
* added FindRelatedProducts with sequence 200
PropertyTable
* added RemovePreviousVersions TRUE
* added SECURECUSTOMPROPERTIES SOLARUPGRADE
* had a existing UpgradeCode with guid created by MSICREATE
* had a existing ProductVersion 12.2.12.0 created my MSICREATE
添加了升级表
* UpgradeCode same value as Upgrade in Property Table
* VersionMin null
* VersionMax 99.12.31
* Attributes 1
* ActionProperty SOLARUPGRADE (same value as SECURECUSTOMPROPERTIES in Property Table)
我还分配了一个新的 PackageCode 和一个新的 ProductCode，因此新的 msi 具有不同的 PackageCode 值， ProductCode 和 ProductVersion 与之前安装的产品不同。
当我使用以前安装的产品运行此 msi 时，旧产品将被删除，创建新的程序文件目录，并且从新的 .msi 重新安装除 .exe 之外的所有文件。修复将导致创建 .exe。如果在删除旧产品（使用控制面板添加/删除程序）后安装新的 msi，则将安装包括 .exe 在内的所有文件。
msiexec 日志文件是 mywebspace.wisc.edu/mdorl/msilog/log3.log
.msi 是 mywebspace.wisc.edu/mdorl/msilog/sbl_Major_Upgrade.msi
对我来说唯一看起来奇怪的是日志中的以下几行。第一个、第二个和第四个是已安装的文件，第三个是未安装的 .exe 文件。 注意此条目上的空操作。
Action start 8:04:41: InstallValidate.
MSI (s) (18:F4) [08:04:41:671]: Feature: _MainFeature; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _24A30964F6B6462282E161248AF15827; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _7B95B32E33EB4F699B44D53CA5BC22B5; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _2FBD153583AF40C09EB9920149F7C7B7; Installed: Absent; Request: Local; Action: Null
MSI (s) (18:F4) [08:04:41:671]: Component: _38A400D7DB76479CA0EC6D643D5793CD; Installed: Absent; Request: Local; Action: Local
I have a .msi file created by a program called MSICREATE and doctored using orca as follows...
InstallExecuteSequence Table
* added FindRelatedProducts with sequence 410
* added RemoveExistingProducts with sequence 1450
InstallUISequence Table
* added FindRelatedProducts with sequence 200
PropertyTable
* added RemovePreviousVersions TRUE
* added SECURECUSTOMPROPERTIES SOLARUPGRADE
* had a existing UpgradeCode with guid created by MSICREATE
* had a existing ProductVersion 12.2.12.0 created my MSICREATE
Added a Upgrade Table
* UpgradeCode same value as Upgrade in Property Table
* VersionMin null
* VersionMax 99.12.31
* Attributes 1
* ActionProperty SOLARUPGRADE (same value as SECURECUSTOMPROPERTIES in Property Table)
I also assigned a new PackageCode and a new ProductCode so the new msi had different values of PackageCode, ProductCode, and ProductVersion than the previously installed product.
When I run this msi with the product previously installed, the old product is deleted, a new program files directory created and all the files except the .exe reinstalled from the new .msi. A repair will cause the .exe to be created. If the new msi is installed AFTER removing the old product (using control panel add/remove programs), all files including the .exe are installed.
The msiexec log file is mywebspace.wisc.edu/mdorl/msilog/log3.log
The .msi is mywebspace.wisc.edu/mdorl/msilog/sbl_Major_Upgrade.msi
The only things that looks weird to me are the following lines from the log. The first, second, and fourth are files that do get installed, the third is the .exe file that does not get installed. NOTE THE NULL ACTION ON THIS ENTRY.
Action start 8:04:41: InstallValidate.
MSI (s) (18:F4) [08:04:41:671]: Feature: _MainFeature; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _24A30964F6B6462282E161248AF15827; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _7B95B32E33EB4F699B44D53CA5BC22B5; Installed: Absent; Request: Local; Action: Local
MSI (s) (18:F4) [08:04:41:671]: Component: _2FBD153583AF40C09EB9920149F7C7B7; Installed: Absent; Request: Local; Action: Null
MSI (s) (18:F4) [08:04:41:671]: Component: _38A400D7DB76479CA0EC6D643D5793CD; Installed: Absent; Request: Local; Action: Local
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您查看日志中的第 603 行，您将发现以下内容：
MSI (s) (18:10) [08:04:41:827]：禁止卸载组件：{ADC6C3E9-A0CF-4AFC- 9998-7B9449C8EA10}，因为存在另一个客户端
MSI (s) (18:10) [08:04:41:827]：禁止卸载组件：{F74907E7-607E-49D1-B613-D63A36ADB020}，因为存在另一个客户端
MSI (s) (18:10) [08:04:41:827]：由于存在另一个客户端，因此不允许卸载组件：{B1FE4023-E176-42BC-92C3-15B8E50CFBB0}
MSI (s) (18:10) [08:04:41:827]：禁止卸载组件：{E6F5DF5D-3460-4B44-8743-48787E68A2C1}，因为存在另一个客户端
如果相同的组件，则可能会发生这种情况在同一台计算机上安装的多个软件包之间共享。 Windows Installer 保留组件的引用计数，并允许删除它们，直到删除所有使用它们的应用程序。
如果您在测试/开发计算机上遇到此问题，我建议您在干净的虚拟机上进行测试，以确保之前的其他测试不会影响此虚拟机。
另外，如果您知道您在其他应用程序的包中使用了相同的组件，请对其进行编辑，确保每个组件对于每个包都有唯一的 GUID。
If you look in the log at the line 603 you will find the following:
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {ADC6C3E9-A0CF-4AFC-9998-7B9449C8EA10} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {F74907E7-607E-49D1-B613-D63A36ADB020} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {B1FE4023-E176-42BC-92C3-15B8E50CFBB0} since another client exists
MSI (s) (18:10) [08:04:41:827]: Disallowing uninstallation of component: {E6F5DF5D-3460-4B44-8743-48787E68A2C1} since another client exists
This can happen if the same components are shared between multiple packages installed on the same machine. Windows Installer keeps a refcount for the components and does allow removing them until all the applications that use them are removed.
If you encounter this on your test/development machine I recommend testing on a clean VM, to ensure no other previous tests affect this one.
Also, if you know you have used the same components in packages for other applications please edit them, making sure each component has an unique GUID for each package.
Windows Installer 使用密钥文件及其 GUID 来检测组件，以下是更多详细信息：
http://msdn.microsoft。 com/en-us/library/windows/desktop/aa370561(v=vs.85).aspx
正如您所怀疑的，Windows Installer 也在检查该文件版本，我假设您在新版本中正确增加了该版本。以下是它遵循的规则：
http://msdn.microsoft。 com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx
您需要从文件表中获取版本列EXE 设置为比计算机上已存在的值更高的值，否则 Windows Installer 将决定最好保留旧值，因为它具有更高的版本。
A keyfile is used by Windows Installer to detect the component, along with its GUID, here are more details:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370561(v=vs.85).aspx
As you suspected, Windows Installer is also checking the file version, which I assumed you correctly incremented in the new version. Here are the rules followed by it:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx
You need to have the version column from the File table for the EXE set to a higher value then of the one already existent on the machine, otherwise Windows Installer will decide its better to keep the old one, because it has a higher version.
为了结束这个项目，以下是我发现的内容以及我所做的修复工作。
1）我对版本化/非版本化文件的含义仍然模糊。我猜所有 .exe 文件都有版本控制。我想这意味着此类文件需要文件表中的相应版本。
2）我现在明白文件表版本不需要与 ProductVersion 相关。
3）我一直在使用非法的ProductVersion，例如。 2012年2月16日。我改用 12.2.16 之类的东西。
4) 我在 Visual Studio 中设置 .exe VS_VERSION_INFO FILEVERSION 并将相同的值添加到文件表版本字段。
现在，当我进行重大升级时，所有文件都会被替换。
For the sake of putting some closure to this item, here's what I've discovered and what I did to fix things.
1) I'm still fuzzy on the meaning of versioned/unversioned file. I guess all .exe files ar versioned. I suppose this means that such files need corresponding versions in the File table.
2) I now understand the file table version need have no connection to the ProductVersion.
3) I have been using illegal ProductVersion Eg. 2012.02.16. I switched to using something like 12.2.16.
4) I set the .exe VS_VERSION_INFO FILEVERSION in Visual Studio and added the same value to File table Version field.
Now, all files are replaced when I do a major upgrade.
我想其他文件的版本已增加。 Windows Installer 应该对包中的所有文件应用版本控制规则。
如果您想在新包中保持较小的版本，我没有看到解决方案。当然，自定义操作除外。
它们都是正确的版本号。后一个值通常设置为一个文件，以确保它替换计算机中的任何其他现有文件，即操作系统允许的最高版本号。
http://msdn.microsoft。 com/en-us/library/windows/desktop/aa368596(v=vs.85).aspx
I suppose the other files have their version increased. Windows Installer should apply the versioning rules on all the files from the package.
I don't see a solution if you want to keep the version smaller in the new package. Except of course, custom actions.
Both of them are correct version numbers. The latter value is usually set to a file to make sure it replaces any other existing file from the machine, i.e. its the highest version number allowed by the OS.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368596(v=vs.85).aspx