我有一个InstallShield 2012 Basic MSI项目，我一直在为我们公司维护。我不是一个受过训练的InstallShield开发人员(只是图腾柱上[当时]最低的开发人员)，但几个月来我学到了足够多的东西，使各个版本都能顺利运行。
最近，我们的一位客户坚持说，我们已经在最新版本中修复了旧版本产品中的一个错误。我们通常不会创建补丁，因为完整的安装程序兼作更新程序，但在这种情况下，我们遵守了规定，在他们所在的版本创建了一个分支，并向他们发送了一个更新补丁。该修补程序中只包含一个文件，并且该文件的版本与要替换的文件的版本相同。一切都很好。
今天，该客户希望升级到我们的最新版本。实际上，我们正在将他们的分支合并回主线，由于他们的分支没有额外的组件或特定于客户端的代码，我想我们可以简单地给他们我们的常规安装程序，并让它覆盖所有内容。不是这样…
当我复制他们的分支安装并尝试更新文件时，安装程序成功运行，并替换了除分支dll之外的所有内容。修补"omus"、"amus"、强制覆盖等不会改变任何内容。事先删除文件不会有任何作用。无论我尝试什么，分支dll都会保留下来，日志看起来是这样的(为了保护罪犯而更改了名称，版本和指南保持不变)：
正确更新的DLL：
Executing op: RegisterSharedComponentProvider(,,File=dll_that_works.r1,Component={B4F132E0-6C2A-4138-990B-16B991F8C54D},ComponentVersion=1.1.1.195,ProductCode={B2F1D6AC-95A4-44A9-9A52-631A3AD14389},ProductVersion=1.1.1,PatchSize=0,PatchAttributes=0,PatchSequence=0,SharedComponent=0,IsFullFile=0)
Executing op: FileCopy(SourceName=SY2F9C~1.DLL|dll_that_works.dll,SourceCabKey=dll_that_works.r1,DestName=dll_that_works.dll,Attributes=16384,FileSize=51584,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,Version=1.1.1.195,Language=0,InstallMode=130023424,,,,,,,)
File: C:inetpubwwwrootServicebindll_that_works.dll; Overwrite; Won't patch; REINSTALLMODE specifies all files to be overwritten
Source for file 'dll_that_works.r1' is compressed
未更新的分支DLL：
Executing op: SetSourceFolder(Folder=C:WindowsInstaller$PatchCache$ManagedCA6D1F2B4A599A44A92536A1A31D34981.1.1)
Executing op: RegisterSharedComponentProvider(PatchGUID={EC6657A6-01A1-4AFC-86F9-1F4BF5F15481},MediaCabinet=#PCW_CAB_Family1,File=branched_dll.r,Component={74531F91-82A9-421D-A227-15DDDEDFC2FA},ComponentVersion=1.1.1.195,ProductCode={B2F1D6AC-95A4-44A9-9A52-631A3AD14389},ProductVersion=1.1.1,PatchSize=35952,PatchAttributes=0,PatchSequence=10000,SharedComponent=0,IsFullFile=0)
Executing op: FileCopy(SourceName=branched_dll.r,SourceCabKey=branched_dll.r,DestName=branched_dll.dll,Attributes=0,FileSize=225664,PerTick=65536,,VerifyMedia=0,,TotalPatches=1,,,CheckCRC=0,Version=1.1.1.195,Language=0,InstallMode=130023424,,,,,,,)
File: C:inetpubwwwrootServicebinbranched_dll.dll; Overwrite; Smart patch; REINSTALLMODE specifies all files to be overwritten
Redirecting file copy of 'C:inetpubwwwrootServicebinbranched_dll.dll' to 'C:Config.MsiPTB2C9.tmp'. A subsequent patch will update the intermediate file, and then copy over the original.
Source for file 'branched_dll.r' is uncompressed, at 'C:WindowsInstaller$PatchCache$ManagedCA6D1F2B4A599A44A92536A1A31D34981.1.1'.
这有点超出我的理解范围。据我所知，它正在尝试修补分支DLL，但无法这样做，并出于某种原因将文件放入临时目录(我找不到"智能补丁"的确切含义的详细信息)。我见过应用到错误版本的补丁会出现这种情况，但这不是补丁！这是一个使用REINSTALLMODE=v(oa)mus和REINSTALL=ALL运行的常规安装程序。它应该只看到旧版本，看到它嵌入了新版本，然后把旧版本吹走。
(一时兴起，我尝试手动更新DLL，而不是使用我们给客户端的更新程序。一切都更新正确，所以它不会阻塞文件本身)
我的直接目标是让这个客户端恢复同步，最好不用任何卸载，只使用一个统一的安装程序，而不是只为它们创建一个特殊的更新程序。由于这些文件已经在野外了，如果不可行的话，我可以忍受一个特殊的情况。我未来的目标是让它像我想象的那样自然地工作——文件是旧版本，文件被替换，其他什么都不重要。
我想我已经提供了所有相关的信息，但如果没有，我可以提供更多的信息。我今天大部分时间都在研究这个问题，我根本找不到任何类似于这个场景的材料。
根据您对场景的描述，您为客户修补的组件的密钥文件的"修改日期"可能晚于升级包中的日期，但版本相同。Windows安装程序可能不会替换该文件。请参阅替换现有文件和FileF 行中的示例
此客户可能需要使用自定义软件包，在应用最新升级之前卸载已修补的组件。