我们有一种情况，我们将有两个VSTO Outlook加载项，它们都是从一些常见的共享代码开始的，但共享代码可能会随着时间的推移而出现分歧。理想情况下，我们希望重新构建加载项以将公共代码分解为单独的共享dll，但出于非技术原因，这不是现在的选项。如果两个加载项都部署在同一个Outlook实例上，您预计会出现什么问题？您是否看到问题突然出现，因为会有两个具有相同名称和相同名称空间的类，但是两个不同的加载项在同一个Outlook实例上加载了不同的定义？另外一个加载项需要在另一个加载项中调用表单。您是否认为这将是常见代码差异的问题？
假设我们设法重新构建加载项以将dll与所有公共代码分开，那么Outlook是否会遇到由两个不同加载项部署的相同dll的不同版本的问题？
答案 0 :(得分：2)
我当前的项目在Word的VSTO加载项之间进行了类似的代码共享。目前，我们在编译时使用“复制本地”的其他项目的引用，但是希望将其切换为引用GAC中的共享代码，这样我们就可以摆脱构建需要重建的共享组件的场景所有依赖它的项目。
如果在构建期间所有共享库dll都是“复制本地”，则不应该有任何名称/命名空间冲突 - 但只要共享库代码发生更改，您就需要重建加载项。如果您希望单独处理构建，请创建一个将用作库的加载项，该加载项在GAC中安装自身的副本，以便其他加载项可以使用它。我已经包含了一些链接，显示如何从其他加载项调用代码。在实践中，我发现它有点傻，因为VSTO是.Net在Office的本机代码之上。
参考文献：