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

如何解决部署由多个产品/版本共享的COM DLL

|| 假设您有两个产品A和B，它们都是由同一家公司同时开发，测试和发布的。为了代码重用并且不做两次工作，在放置低级实用程序/框架/帮助程序代码的地方创建了第三个源代码控制分支C。此代码包括一些COM dll。 然后，管理层决定A和B确实应该有自己的发布周期，并作为完全独立的产品进行管理。现在，您无法随时修改/更新C，因为当一个团队正在使用A时，另一个团队可能距离发布B有2周的时间，因此进入B（包括C）的所有代码都必须冻结。 我看到的解决方案是将C淘汰，并使其成为A和B都依赖的独立SDK。该SDK将具有自己的版本控制方案和自己的发布周期。这样，A可以承诺使用C-1.2.4，如果B需要更新的东西，则可以在C-1.3.8中进行更改。 我现在要解决的问题是如何处理COM DLL，因为A和B都可能安装在同一台计算机上。我看到了三个选项，但不确定哪一个是好/更好的，或者是否还有我看不到的另一个选项： 每次版本号更改时，都有某种脚本通过.IDL文件并更改所有共同类GUID。可能工作，但由于某些原因，对许多人来说（包括我本人）似乎很害怕 使用免注册COM激活。这可以与不受我们控制的可执行文件一起使用吗？ （graphedt.exe，iexplore.exe ...）。 确保所有向前的COM对象都向后兼容，并且A和B都使用所安装模块的最新版本。这似乎就像测试噩梦一样，因为我们最终将得到尚未经过质量检查的机器和DLL组合。     

解决方法

        自从我负责构建或发布以来已经有一段时间了，但是我记得DLL HELL只能很好！你有我的同情！ 正如您已暗示要创建通用安装一样-将其安装到C：\\ Program Files \\ Common Files \\ YourProductOrCompany \\ Version并注册它们。您需要保持向后兼容性，并正确版本化您的msi（假设您使用该版本进行部署）。这样，如果每个安装具有更高版本，则可以安装该通用软件包。 这对我们来说效果很好（大约有8种产品使用一个公共内核），但是我们有一套全面的自动化回归测试，因此每次更改某些内容时，我们都可以轻松地针对产品重新运行测试。 在某些地方，这些更改被认为是很大的，并且公共组件版本也已更改（包括所有的ClassID等）。因此，您可以使用不同的内核在同一台计算机上运行10.1和11.1。 HTH， 马特