AssemblyResolve siempre se levantan, solicitando MyAssembly.resources

Question

Tengo una aplicación WPF, y me suscribo al evento AppDomain.AssemblyResolve (este evento se genera cada vez que el tiempo de ejecución no encuentra un ensamblado), y noto que recibe una llamada varias veces intentando para resolver MyAssembly.resources, donde MyAssembly es el ensamblado de ejecución actual. También solicitó lo mismo para una asamblea de biblioteca a la que hice referencia en MyAssembly (solicitó Library.resources).

¿Es esto normal? ¿Cómo lo arreglo? Mi aplicación tiene un problema. No puede cargar algún control de usuario xaml ubicado en la biblioteca. ¿Esto está relacionado?

Answer 1

Agregue esta línea a su AssemblyInfo.cs y su sistema de resolución no recibirá más recursos.

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

Aunque se trata de una solución temporal, se deben considerar cuidadosamente las aplicaciones de varios idiomas.

Más información:

• 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

Puede usar fuslogvw.exe para ver dónde .Net está tratando de buscar sus dependencias.

Consulte http://msdn.microsoft.com/en-us/library/e74a18c4.aspx para obtener más información.

Answer 3

nos encontramos con este mismo problema con un controlador AssemblyResolve evento. Curiosamente, solo vimos el problema en las máquinas con Windows XP. Nuestra aplicación está traducida a varios idiomas, por lo que dudamos en usar el NeutralResourcesLanguageAttribute. Nuestra solicitud fue compilado para la versión 3.5 de .NET, pero seguía siendo afectada por el cambio AssemblyResolvedocumented para .NET v4.0:

Importante Comenzando con .NET Framework 4, se provoca el evento ResolveEventHandler para todos los ensamblados, incluidos conjuntos de recursos. En versiones anteriores, el evento no se planteaba para conjuntos de recursos . Si el sistema operativo está localizado, el manejador se puede llamar varias veces: una vez para cada cultivo en la cadena alternativa.

La forma en que esto fue resuelto para comprobar e.Name y ver si estaba buscando * .Resources.dll. Si ese archivo no se encontraba en el AppDomain o en la carpeta conocida, eliminaríamos ".Resources" y buscaríamos * .dll. Si ese archivo existe, cargamos y devolvemos ese ensamblaje. Esto resolvió el problema para nosotros.