Deployment 部署由多个产品/版本共享的COM DLL

假设您有两个产品A和B，它们都是由同一家公司同时开发、测试和发布的。为了代码重用和不重复工作，在放置低级实用程序/框架/帮助程序代码的地方创建了第三个源代码管理分支C。此代码包括一些COM DLL

然后管理层决定A和B应该有自己的发布周期，并作为完全独立的产品进行管理。现在，您不能在任何时候修改/更新C，因为当一个团队在A上工作时，另一个团队可能离发布B还有两周的时间，所以任何进入B（也包括C）的代码都需要冻结

我看到的解决方案是将C去掉，使其成为a和B都依赖的独立SDK。这个SDK将有自己的版本控制方案和发布周期。这样，A可以承诺使用C-1.2.4，如果B需要更新的内容，可以在C-1.3.8中进行更改

我现在试图解决的问题是如何处理COM DLL，因为A和B可能都安装在同一台机器上。我看到了三个选项，但不确定哪一个是好的/更好的，或者是否还有另一个选项我没有看到：

每次版本号更改时，都要让某种脚本通过.IDL文件并更改所有的coclass GUID。可能有用，但由于某些原因，对许多人（包括我自己）来说似乎很可怕

使用免注册COM激活。对于不在我们控制下的可执行文件，这会起作用吗？（graphedt.exe，iexplore.exe…）

确保所有的COM对象都向后兼容，并且A和B都使用安装的模块的最新版本。这看起来像是一场测试噩梦，因为我们最终将得到未经质量保证的机器和DLL组合

---

我已经有一段时间没有关注构建或发布了，但我只记得DLL地狱！我同情你

正如您提到的创建一个通用安装一样，请将其安装到C:\Program Files\common Files\YourProductor Company\Version并注册。您需要保持向后兼容性，并正确地设置msi的版本（假设您使用该版本进行部署）。这样，每次安装都可以安装通用软件包（如果版本更高）

这对我们来说效果很好（大约有8个产品使用了一个共同的核心），但我们有一套全面的自动回归测试，因此每次更改某些内容时，我们都可以轻松地针对这些产品重新运行测试

后来，人们认为这些变化是巨大的，通用组件版本也发生了变化（包括所有ClassID等）。因此，您可以让10.1和11.1使用不同的内核在同一台机器上运行

嗯,，

---

马特

谢谢你的建议，马特。所以基本上，您实现了两个选项（1）和（3）。保持小改动/功能的向后兼容性，偶尔发布一个新版本并更改所有GUI，这样所有东西都可以在同一台机器上并排运行，并且可以限制回归测试的范围。是的，这就是总结。次要的版本更改guid保持不变，主要的版本更改破坏了兼容性。主要更改的驱动程序，但我猜它们也可能与测试\dev流程相关。