我几周前创建了一个安装程序（基本的Windows安装程序类型）（版本1.0.0），它部署了一些dll并且还为com-interop（使用vdsrpCOM）注册了其中一个。实际上没什么大不了的。我还有一个帮助类，通过自定义操作（在特定位置提取ZIP库）onBeforeInstall和onAfterInstall上做一些事情。
现在是时候更新我的产品了，更具体的是我的com注册的dll。 因此，我更改了必须升级的所有dll的文件和汇编版本，并标记了安装程序RemovePreviousVersions = true。当然，除了更新项目的文件和汇编版本之外，我还会更新安装程序的版本（到1.1.1）。
安装这个新版本时，每个具有新文件版本的dll都会被很好地覆盖，而那些没有更改过的文件版本的dll则不会（当然，如果事情没有改变，MSI就是那么聪明） ，我为什么要更换呢？'...）
我现在遇到的唯一错误是我的com注册的dll不再很好地注册了。我还注意到，在视图中，我的dll仍然已注册，但在“Registery”部分中缺少一些代码行，更具体： MyNamespace.MyClass = MyNamespace.MyClass CLSID = {bla-bla-bla-bla-bla}
卸载和重新安装解决了这个问题。但是，当然，我不想松开并重新安排，因为这就是MSI应该照顾的。
所以，我一直在想，因为我有一个可以通过自定义操作在onBeforeInstall上触发的installerHelper，为什么我不检查自己是否安装了版本，如果有，请删除它。
现在，UpgradeCode中版本之间唯一的常量。我的问题开始在哪里： 如何通过我的帮助程序类获取升级代码，检查具有相同升级代码的先前版本，在onBeforeInstall方法中安装那些？
或者，或许更好，我怎样才能确保在更新时妥善处理com注册？ （这可能更容易，但我确实希望能够强制完成unistall /重新安装）
答案 0 :(得分：0)
这是为什么任何形式的自我注册＆＃34;在Windows安装程序世界中不是最佳实践。当您使用内置的Windows Installer功能时，它通常可以正常工作并获得正确的事务行为（安装，卸载，回滚，提交）。当你离开过程并使用＆＃34;助手＆＃34;如果你不确切知道它会变得很难看，我的意思正是你在做什么。
我不清楚您的COM服务器是本机还是托管服务器。它还不清楚您使用什么工具来创作MSI。确切的答案取决于这两个因素。
但总的来说，这个概念是为了收获＆＃34;或者＆＃34;提取＆＃34;来自DLL的COM元数据，并使用COM表（ProdID，Class等表）将其直接创建到MSI，或者避免某些COM广告使Registry表烦恼。像InstallShield这样的工具支持使这更容易（右键单击| COM Extract或COM Extract在Build = True或.NET Com Interop = True）但是也有方法可以使用工具获取此信息，然后手动将其导入到安装程序项目中或代码。
这样做的好处是MSI完全理解该DLL的资源，并且可以为您管理所有这些。这提高了安装程序的性能和可靠性。