如何在System.AddIn中使用automapper？

Question

在System.AddIn (又名MAF)管道适配器中，大量的值从一种DTO类型复制到另一种DTO类型--从HostView类型到管道契约类型，以及从管道契约类型到AddIn视图类型(然后再次回来)。这似乎是一个理想的情况下使用自动驾驶。

但是，我不确定在HostView和AddInView适配器中使用和打包第三方程序集的正确方法，特别是当AddIn激活在单独的AppDomain中时。

我尝试了以下几点：

• 将automapper的nuget引用添加到AddIn适配器项目，并在其中创建映射配置文件。(我对初始化配置文件的适配器使用了一个静态ctor，因为MAF负责实例化适配器。)
• 相反地，为了使管道定位并激活适配器支持的AddIns，我必须确保automapper驻留在我的主机的bin dir中--在实际适配器DLL旁边的"AddInAdapters“文件夹中的automapper没有任何影响。

通过这种安排，我能够在我的开发框(win 7)上找到并激活AddIn。但是完全相同的二进制文件不能在Server2008R2上工作。(我知道，我知道:我不控制开发或服务器操作系统的选择)

我们正在使用(并瞄准) .Net 4.5.1 -是的，它在桌面和服务器上。我们使用的是automapper 2.2.1 -不，它不在我的开发框的GAC中

适配器使用的第三方程序集应位于何处( AddIn侧和主机端)。特别是在考虑AppDomain隔离时

为什么上述安排会在Windows 7上工作，而不是在2008 R2上？

Answer 1

在主机端，它应该位于应用程序的根输出目录中。所有主机dll都加载在应用程序域中，程序集解析器将查找正在运行的程序集的位置，以查找automapper。

在Addin端，它应该位于addin适配器目录中。插件适配器和加载项视图被加载到新的应用程序域中，并要求它们自己复制这个dll。

在管道中的任何地方使用第三方库时，要小心的一件事是，它会使管道的版本控制变得痛苦。如果您正在加载多个版本的管道以允许V1和V2加载项仍然工作，如果它们依赖于程序集的不同版本，则在协调这一点时可能会遇到问题。如果您不关心管道版本控制，那么这就不那么重要了。