Comportamiento extraño al mezclar la carga de ensamblajes usando Assembly.LoadFrom y Assembly.Load

Question

Comportamiento extraño al mezclar la carga de ensamblajes usando Assembly.LoadFrom y Assembly.Load

Me he encontrado con un comportamiento extraño al cargar ensamblados con Assembly.LoadFrom y más tarde con Assembly.Load.
Estoy cargando un ensamblaje utilizando Assembly.LoadFrom, donde el ensamblaje se encuentra en una carpeta que no es la carpeta de ejecución.

Más adelante, en mi código de prueba, cuando intento cargar una vez más este conjunto con Assembly.Load, la carga falla con una excepción System.IO.FileNotFoundException ("No se pudo cargar el archivo o el conjunto ...") a pesar del hecho de que el conjunto ya está cargado La carga falla con el nombre seguro y el nombre no fuerte (la razón original para cargar una vez más este ensamblaje es el uso de un BinaryFormatter).

Sin embargo, en caso de que el ensamblaje se encuentre en la carpeta de ejecución, la carga posterior se realizará correctamente en ambos casos, con el nombre seguro y el nombre no seguro. En este caso, puede ver que se cargan dos ensamblajes idénticos desde dos ubicaciones diferentes.

Un ejemplo de código simple que recrea este problema -

Assembly assembly1 = Assembly.LoadFrom (@ " C: \ a.dll ");

// La carga con un nombre seguro falla Assembly assembly2 = Assembly.Load (@ " a, Version = 1.0.0.0,       Cultura = neutral, PublicKeyToken = 14986c3f172d1c2c ");

// También se carga con errores no fuertes Assembly assembly3 = Assembly.Load (@ " a ");

1. ¿Alguna explicación de por qué el CLR ignora el ensamblaje ya cargado?
2. ¿Alguna idea de cómo puedo aliviar este problema?

Gracias.

Answer 1

Eso no es raro. Según la documentación, la carga con Load y LoadFrom colocará los ensamblajes en diferentes contextos. Esto podría ayudar.

  

  
1. ¿Alguna explicación de por qué el CLR ignora el ensamblaje ya cargado?
  

Porque están en un contexto diferente.

  

  
2. ¿Alguna idea de cómo puedo aliviar este problema?
  

Cargue desde el mismo contexto, o ayude a CLR a encontrar el ensamblaje, quizás adjuntando un controlador a AppDomain.AssemblyResolve .

Alternativa

Si la ubicación desde la que está cargando ensamblajes es una subcarpeta en AppDomain.BaseDirectory, simplemente puede agregar una entrada a su App.config:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

http://msdn.microsoft.com/en-us/library /823z9h8w.aspx

Answer 2

@Kent Boogart: Esa parece ser la explicación correcta. Para una explicación completa, Suzanne Cook tiene esta publicación de blog que elabora un poco más que la original que usted publicó: http://blogs.msdn.com/suzcook/archive/2003 /05/29/57143.aspx

A continuación se muestra el código que aprovecha AppDomain.AssemblyResolve -

 // register to listen to all assembly resolving attempts:
 AppDomain currentDomain = AppDomain.CurrentDomain;
 currentDomain.AssemblyResolve += new ResolveEventHandler(MyResolveEventHandler);


 // Check whether the desired assembly is already loaded
 private static Assembly MyResolveEventHandler(object sender, ResolveEventArgs args) {
    Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
    foreach (Assembly assembly in assemblies) {
       AssemblyName assemblyName = assembly.GetName();
       string desiredAssmebly = args.Name;
       if (assemblyName.FullName == desiredAssmebly) {
           return assembly;
       }
    }

    // Failed to find the desired assembly
    return null;
 }