AssemblyResolve всегда поднимают, спрашивая MyAssembly.resources

Question

У меня есть приложение WPF, и я подписываюсь на событие AppDomain.AssemblyResolve (это событие возникает, когда среда выполнения не находит сборку), и я замечаю, что он получает вызов несколько раз, пытаясь решитьMyAssembly.resources, где MyAssembly - текущая исполняемая сборка.Он также спросил то же самое для сборки библиотеки, на которую я ссылался из MyAssembly (он запросил Library.resources).

Это нормально?Как мне это исправить?У моего приложения есть проблема.Он не может загрузить какой-либо пользовательский элемент управления xaml, расположенный в библиотеке.Это связано?

Answer 1

Добавьте эту строку в файл AssemblyInfo.cs, и ваш распознаватель больше не будет запрашивать ресурсы.

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

Хотя это обходной путь, следует внимательно рассмотреть многоязычные приложения.

Подробнее:

• 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

Мы столкнулись с той же проблемой с обработчиком событий AssemblyResolve.Как ни странно, мы видели эту проблему только на компьютерах с Windows XP.Наше приложение локализовано на многие языки, поэтому мы не решались использовать NeutralResourcesLanguageAttribute.Наше приложение было скомпилировано для .NET v3.5, но все еще находилось под влиянием AssemblyResolve изменения , документированного для .NET v4.0:

Важно Начиная с .NET Framework 4, событие ResolveEventHandler возникает для всех сборок, включая сборки ресурсов.В более ранних версиях событие не было инициировано для сборок ресурсов.Если операционная система локализована, обработчик может вызываться несколько раз: по одному разу для каждой культуры в резервной цепочке.

Мы решили, что для этого нужно проверить e.Name и посмотреть, смотрит ли ондля * .Resources.dll.Если этот файл не был найден в AppDomain или в известной папке, мы удалили бы «.Resources» и искали * .dll.Если этот файл существует, мы загружаем и возвращаем эту сборку.Это решило проблему для нас.

Answer 3

Вы можете использовать fuslogvw.exe, чтобы увидеть, где .Net пытается найти ваши зависимости.

Подробнее см. http://msdn.microsoft.com/en-us/library/e74a18c4.aspx.