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

Question

假设您有两个产品A和B，它们由同一家公司同时开发，测试和发布。为了代码重用而不进行两次工作，第三个源控制分支C被创建，其中放置了低级实用程序/框架/帮助程序代码。此代码包含一些COM dll。

然后管理层决定A和B应该有自己的发布周期，并作为完全独立的产品进行管理。现在你无法随时修改/更新C，因为当一个团队正在处理A时，另一个团队可能在发布B后2周，因此任何进入B的代码（也包括C）都需要被冻结。

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

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

1. 每次版本号更改时，都会有某种脚本通过.IDL文件并更改所有coclass GUID。可能会工作，但由于某种原因，许多人（包括我自己）似乎很可怕。
2. 使用无注册表的COM激活。这是否适用于我们无法控制的可执行文件？ （graphedt.exe，iexplore.exe ...）。
3. 确保所有前进的COM对象都向后兼容，并且A和B都使用安装的最新版本的模块。这似乎是在测试噩梦，因为我们最终会得到没有进行QA的机器和DLL组合。

Answer 1

自从我照看构建版本或发布版本以来已经有一段时间但我记得DLL HELL只是为了好！你有我的同情心！

正如您所提到的，创建一个通用安装 - 将其安装到C：\ Program Files \ Common Files \ YourProductOrCompany \ Version并注册它们。你需要保持向后兼容性和版本你的msi（假设你正确部署）。这样，如果公共包具有更高版本，则每个安装都可以安装它。

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

并且出现了变化被认为很好并且常见组件版本被更改的点（包括所有ClassID等等）。因此，您可以使用不同的内核在同一台计算机上运行10.1和11.1。

HTH， 马特