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