AssemblyResolve always get raised, asking for MyAssembly.resources

Question

I have a WPF application, and I subscribe to the event AppDomain.AssemblyResolve (this event get raised whenever the runtime does not find an assembly), and I notice it gets call several times trying to resolve MyAssembly.resources, where MyAssembly is the current executing assembly. It also asked the same thing for a library assembly I referenced from MyAssembly (it asked for Library.resources).

Is this normal? How do I fix it? My application does have a problem. It cannot load some xaml user control located in the library. Is this related?

Answer 1

Add this line to your AssemblyInfo.cs and your resolver will not get asked for resources any-more.

[assembly: NeutralResourcesLanguageAttribute("en-US", UltimateResourceFallbackLocation.MainAssembly)]

Though this is a work-around should be carefully considered multi-language applications.

More Info:

• https://connect.microsoft.com/VisualStudio/feedback/details/526836/wpf-appdomain-assemblyresolve-being-called-when-it-shouldnt
• http://blogs.msdn.com/b/kimhamil/archive/2008/11/11/what-does-the-neutralresourceslanguageattribute-do.aspx
• http://forums.devshed.com/net-development-87/c-wpf-appdomain-assemblyresolve-being-called-when-it-shouldn-t-669567.html

Answer 2

We ran into this same problem with an AssemblyResolve event handler. Oddly, we only saw the issue on Windows XP machines. Our application is localized to many languages, so we were hesitant to use the NeutralResourcesLanguageAttribute. Our application was compiled for .NET v3.5, but was still being affected by the AssemblyResolve change documented for .NET v4.0:

Important 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.

The way we resolved this was to check e.Name and see if it was looking for *.Resources.dll. If that file was not found in the AppDomain or known folder, we would remove ".Resources" and look for *.dll. If that file exists, we load and return that assembly. This resolved the problem for us.

Answer 3

You can use fuslogvw.exe in order to see where .Net is trying to look for your dependencies.

See http://msdn.microsoft.com/en-us/library/e74a18c4.aspx for more info.