What is the correct way to handle assembly resolution in .NET ArcGIS add-ins?

Question

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?

• Kirk Kuykendall: Is this an issue when working with traditional (non-addin) customizations too? I've had to do a similar hack to force telerik assembly to load.
• blah238: Good question, I don't know. When I have a chance I'll try to create samples for both.
• Petr Krebs: What a great topic! I personally do not like the add-in deployment model at all exactly for these reasons. I am curious what the practice and experience in the real world is. My opinion is that ArcGIS is essentially loading add-in assemblies in the wrong context (see blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx for further discussion).
• blah238: Yes it appears ESRI is using the LoadFrom context for the add-in assemblies. I wonder what "Dependencies in the same dir as the requesting LoadFrom context assembly will automatically be found" means in this scenario. The other article linked in that one also explains what ESRI should have done (multiple AppDomains), but maybe there is some technical (COM interop-related most likely) reason they couldn't.
• Petr Krebs: LoadFrom context should be fine, but isn't ArcGIS using Load context instead? I'm not sure, I'll have to check.