Thursday, April 5, 2012


At EarthSoft, we have an application that uses the AppDomain.AssemblyResolve event to dynamically find assemblies (aka DLL files). We have two purposes for our custom AssemblyResolve event:

1. In a recent upgrade we consolidated several of our assemblies and wanted to maintain backwards compatibility with client customizations that reference our old assembly names.

2. Part of our application is used as an extension to Esri ArcGIS Desktop. In that scenario, the process is running from a different folder, so the .NET Framework will not automatically find our other assemblies without our AssemblyResolve event handler.

Our custom AssemblyResolve event handler had been working fairly well until just recently. We had a few clients that reported problems related to the application not being able to find the satellite resource assemblies. Upon further investigation, I found an interesting note in the MSDN documentation for AppDomain.AssemblyResolve:


Beginning with the .NET Framework 4, the ResolveEventHandler event is raised for all assemblies, including resource assemblies. In earlier versions, the event was not raised for resource assemblies. If the operating system is localized, the handler might be called multiple times: once for each culture in the fallback chain.

I must admit, I have not read every page of the MSDN documentation and I was not aware of this change. The peculiar thing is that our application is compiled for .NET v3.5 - so it is a little unclear as to why it is affected by this change. It is also interesting that the only clients that reported this issue are using Windows XP. Nonetheless, this nugget of information was helpful in resolving the problem. We enhanced our event handler such that it would redirect probes for neutral resource assemblies to the corresponding assembly. For example, we had to redirect a probe for "EarthSoft.Common.resources.dll" to "EarthSoft.Common.dll". After making this change, the problem was resolved.

No comments:

Post a Comment