在System.AddIn（aka MAF）管道适配器中，有很多手动将值从一种DTO类型复制到另一种 - 从HostView类型到Pipeline Contract类型，从Pipeline Contract类型到AddIn视图类型（并返回）再次）。这似乎是使用automapper的理想情况。
但是我不确定在HostView和AddInView适配器中使用和打包第三方程序集的正确方法，尤其是当AddIn激活位于单独的AppDomain中时。
我尝试了以下内容：
将automapper的nuget引用添加到AddIn适配器项目并在其中创建映射配置文件。 （我使用静态ctor到初始化配置文件的适配器cos MAF负责实例化适配器。）
反直觉地说，为了让管道找到并激活适配器支持的AddIns，我必须确保automapper DLL存在于我的 Host 的bin目录中 - 拥有在＆＃34; AddInAdapters＆＃34;中的automapper DLL实际适配器DLL旁边的文件夹无效。
通过这种安排，我能够在我的开发框中找到并激活AddIn（获胜7）。但完全相同的二进制文件在Server2008R2上不起作用。 （我知道，我知道：我不能控制开发或服务器操作系统的选择）
我们正在使用（和定位）.Net 4.5.1 - 是的，它在桌面和服务器上。我们正在使用automapper 2.2.1 - nope，它不在我的开发框的GAC中
适配器使用的第三方程序集应位于何处（AddIn端和Host端）。特别是在考虑AppDomain隔离时
为什么上述安排适用于Windows 7，而不适用于2008R2？
答案 0 :(得分：1)
在主机端，它应该位于应用程序的根输出目录中。所有主机dll都加载到您的应用程序域中，程序集解析程序将查看正在运行的程序集的位置以查找automapper dll。
在Addin端，它应该存在于addin适配器目录中。 addin适配器和插件视图被加载到新的app域中，并且需要他们自己的dll副本。
在管道中的任何地方使用第三方库时要注意的一件事是，它可能会使管道版本变得痛苦。如果要加载管道的多个版本以允许V1和V2插件仍然有效，如果它们依赖于程序集的不同版本，则在协调它时可能会遇到问题。如果您不关心管道版本控制，那么这不是一个问题。