This has been a thorn in my side for some time now -- in .NET ArcGIS add-ins, assembly dependencies packaged with the add-in are often not resolved correctly. I am still not sure why and under which circumstances this happens but there are a couple of examples (1, 2) on this site, and I have run into several others involving reflection and WPF/XAML resources.
Presumably this is happening because add-ins run in the ArcGIS application's AppDomain, whose assembly probing path is that of the folder containing the application executable, not the add-in. If you use fuslogvw to log assembly binding failures you'll see that it is probing e.g. C:\Program Files\ArcGIS\Desktop10.0\Bin for your assemblies, which will obviously never work with assemblies packaged in your add-in, which are extracted on app startup to e.g. %USERPROFILE%\Local Settings\Application Data\ESRI\Desktop10.0\AssemblyCache\<{Add-In Guid}>.
Some workarounds I have seen include handling the AppDomain.AssemblyResolve event and explicitly forcing a referenced assembly to load by referencing a type defined within that assembly, e.g. var dummy = typeof(SomeTypeInReferencedAssembly);. The latter is what I have settled on doing since it is simple enough, but it seems tacky.
The former seems fragile, especially when you have the potential for multiple add-ins needing to do the same thing. Is there not potential for them to mishandle the others' AssemblyResolve events, since they are all in the same AppDomain?
Why did ESRI not provide an AppDomain for each add-in so they automatically get the correct probing path and avoid all this trouble? What practice does ESRI recommend in this situation?
