两个 Outlook VSTO 插件之间共享代码
我们遇到的情况是，我们有两个 VSTO Outlook 加载项，它们都以一些通用的共享代码开始，但随着时间的推移，共享代码可能会有所不同。理想情况下，我们希望重组加载项，将通用代码分解到单独的共享 dll 中，但出于非技术原因，目前这不是一个选择。如果这两个加载项部署在同一个 Outlook 实例上，您预计会出现什么问题？您是否发现出现问题，因为两个类具有相同的名称和相同的命名空间，但两个不同的加载项加载到同一 Outlook 实例的定义不同？此外，其中一个加载项需要调用另一个加载项中的表单。您认为这会是公共代码差异的问题吗？
假设我们设法重组加载项以分离出包含所有公共代码的 dll，那么 Outlook 是否会遇到两个不同加载项部署同一 dll 的不同版本的问题？
We have a situation where we will have two VSTO Outlook add-ins which both start off with some common shared code, but the shared code will probably diverge over time. Ideally, we'd like to restructure the add-ins to factor out the common code into a separate shared dll, but for non-technical reasons this is not an option right now. What problems do you anticipate if both the add-ins are deployed on the same outlook instance? Do you see problems cropping up because there would be two classes with the same name and same namespace, but with different definitions loaded by the two different add-ins on to the same outlook instance? Also one of the add-ins needs to call a form in the other add-in. Do you think this will be a problem with the differences in common code?
Assuming we manage to restructure the add-ins to separate out a dll with all the common code, will Outlook have a problem with different versions of the same dll being deployed by the two different add-ins?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我当前的项目在 Word 的 VSTO 加载项之间进行了类似的代码共享。目前，我们在编译时使用对其他项目的“复制本地”引用，但希望将其切换为引用 GAC 之外的共享代码，这样我们就可以摆脱构建需要重建的共享组件的情况依赖它的所有项目。
如果所有共享库 dll 在构建期间都是“复制本地”，则不应有任何名称/命名空间冲突 - 但每当共享库代码发生更改时，您都需要重新构建加载项。如果您希望单独处理构建，请创建一个充当库的加载项，该加载项会在 GAC 中安装自身的副本，以便其他加载项可以使用它。我提供了一些链接，显示如何从其他加载项调用代码。在实践中，我发现它有点愚蠢，因为 VSTO 是 Office 本地代码之上的 .Net。
参考文献：
My current project had done similar code sharing between VSTO add-ins for Word. For now, we're using references to the other project with "copy local" at compile time but would like to switch that to reference the shared code out of the GAC so we are freed from the scenario of building the shared component requiring a rebuild of all projects that depend on it.
If all of your shared library dll's are "copy local" during build, you shouldn't have any name/namespace conflicts - but you will need to rebuild the add-in whenever your shared library code changes. If you want the builds to be handled separately, create an add-in that will serve as the library, that installs a copy of itself in the GAC so other add-ins can use it. I've included some links that show how to call code from other add-ins. In practice I've found it a little goofy because of VSTO being .Net on top of Office's native code.
References: