0

几周前，我创建了一个安装程序（基本的 Windows 安装程序类型）（版本 1.0.0），它部署了一些 dll，并为 com-interop（使用 vdsrpCOM）注册了其中一个。其实没什么大不了的。我还有一个助手类，它通过自定义操作（在特定位置提取 ZIP 库）在 onBeforeInstall 和 onAfterInstall 上做一些事情。

现在是时候更新我的产品了，更具体地说是我的 com 注册 dll。因此，我更改了所有必须升级的 dll 的文件和程序集版本，并将安装程序标记为 RemovePreviousVersions = true。当然，除了更新我的项目的文件和程序集版本之外，我还更新了我的安装程序版本（到 1.1.1）。

安装这个新版本时，每个具有新文件版本的 dll 都会被很好地覆盖，而那些没有更改文件版本的 dll 则不会（当然，MSI 很聪明，'如果事情没有改变，为什么要那我换掉它？'...）

我现在遇到的唯一错误是我的 com-registered dll 没有很好地注册了。我还注意到，在 ole-view 中，我的 dll 仍然已注册，但在“注册表部分”中缺少一些代码行，更具体地说：MyNamespace.MyClass = MyNamespace.MyClass CLSID = {bla-bla-bla-bla-bla }

卸载和重新安装解决了这个问题。但是，当然，我不想卸载和重新安装，因为这是 MSI 应该照顾的。

所以，我一直在想，因为我确实有一个 installerHelper，它通过自定义操作在 onBeforeInstall 上触发，我为什么不检查自己是否安装了一个版本，如果有，删除它。

现在，UpgradeCode 中版本之间的唯一常量。我的问题从这里开始：如何从我的助手类中获取升级代码，检查具有相同升级代码的先前版本，在 onBeforeInstall 方法中卸载那些版本？

或者，也许更好，我如何确保在更新时处理好com-registering？（这可能更容易，但我确实喜欢能够强制完全卸载/重新安装的想法）

4

1 回答 1

0

这是为什么任何形式的“自我注册”在 Windows 安装程序世界中都不是最佳实践的示例。当您使用内置的 Windows Installer 功能时，它通常可以正常工作并且您可以获得正确的事务行为（安装、卸载、回滚、提交）。当您退出流程并使用“助手”时，如果您不确切知道并且我的意思是您在做什么，它会很快变得丑陋。

我不清楚您的 COM 服务器是本地的还是托管的。也不清楚您使用什么工具来创作您的 MSI。确切的答案将取决于这两个因素。

但一般来说，这个概念是从 DLL 中“收获”或“提取”COM 元数据，并使用 COM 表（ProdID、Class 等表）将其直接创作到 MSI 中，或者避免某些 COM 广告对注册表的干扰桌子。InstallShield 之类的工具支持使这更容易（右键单击 | COM Extract 或 COM Extract at Build = True 或 .NET Com Interop = True），但也有一些工具可以获取此信息，然后手动将其导入安装程序项目或代码。

这样做的好处是 MSI 完全了解该 DLL 的资源并可以为您管理所有资源。这提高了安装程序的性能和可靠性。

于 2013-08-23T11:53:24.840 回答