In the System.AddIn (aka MAF) pipeline adapters, there is a lot of manual copying of values from one DTO type to another - from HostView types to Pipeline Contract types and from Pipeline Contract types to AddIn view types (and back again). This seems like an ideal situation to use automapper.
However I am unsure as to the correct way to use and package 3rd party assemblies in the HostView and AddInView adapters, especially when AddIn activation is in a separate AppDomain.
I tried the following:
add nuget reference for automapper to AddIn adapter project and create the mapping profiles within. (I used a static ctor to the adapter that initializes the profiles cos MAF is responsible for instantiating the adapter.)
Counter-intuitively, to get the pipeline to locate and activate AddIns supported by the adapter, I had to ensure that the automapper DLL lived in the bin dir of my Host - having the automapper DLL in the "AddInAdapters" folder beside the actual adapter DLL had no effect.
With this arrangement, I was able to find and activate the AddIn on my dev box (win 7). But the exact same binaries would not work on Server2008R2. (I know, I know: I don't control the choice of development or server OS)
We are using (and targeting) .Net 4.5.1 - yep, it's on desktop and server. We are using automapper 2.2.1 - nope, it's not in the GAC of my dev box
Where should 3rd party assemblies used by Adapters be located (both AddIn side and Host side). Especially when considering AppDomain isolation
Why would the above arrangement work on Windows 7, but not 2008R2?
On the host side, it should live in the root output directory of your application. All of the host dlls are loaded in your app domain and the assembly resolver will look in the location of your running assembly for the automapper dll.
On the Addin side, it should live in the addin adapter directory. The addin adapter and addin view are loaded into the new app domain and require their own copy of this dll.
One thing to be careful with when using third party libraries anywhere in your pipeline is it can make versioning your pipeline painful. If you are loading multiple versions of your pipeline to allow for V1 and V2 addins to still work, if they depend on different versions of an assembly, you may run into problems in reconciling this. If you don't care about pipeline versioning, then this is less of a concern.