Strano comportamento durante la miscelazione del caricamento di assiemi mediante Assembly.LoadFrom e Assembly.Load

Question

Comportamento strano durante la miscelazione del caricamento di assiemi mediante Assembly.LoadFrom e Assembly.Load

Ho riscontrato un comportamento strano durante il caricamento degli assembly con Assembly.LoadFrom e successivamente con Assembly.Load.
Sto caricando un assembly utilizzando Assembly.LoadFrom, in cui l'assembly si trova in una cartella che non è la cartella di esecuzione.

Più avanti nel mio codice di prova quando provo a caricare nuovamente questo assembly con Assembly.Load, il caricamento non riesce con System.IO.FileNotFoundException (& # 8220; Impossibile caricare file o assembly & # 8230; & # 8221 ;) nonostante il fatto che il gruppo sia già caricato. Il caricamento fallisce sia con il nome sicuro che con il nome non sicuro (il motivo originale per caricare nuovamente questo assembly è l'utilizzo di un BinaryFormatter).

Tuttavia, nel caso in cui l'assembly si trovi nella cartella di esecuzione, il caricamento successivo ha esito positivo in entrambi i casi, con il nome sicuro e il nome non sicuro. In questo caso puoi vedere che due assiemi identici vengono caricati da due posizioni diverse.

Un semplice esempio di codice che ricrea questo problema & # 8211;

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

// Il caricamento con un nome sicuro non riesce Assembly assembly2 = Assembly.Load (@ " a, Version = 1.0.0.0,       Culture = neutral, PublicKeyToken = 14986c3f172d1c2c ");

// Anche il caricamento con errore non forte Assembly assembly3 = Assembly.Load (@ " a ");

1. Qualche spiegazione del perché il CLR ignora l'assembly già caricato?
2. Qualche idea su come posso alleviare questo problema?

Grazie.

Answer 1

Non è strano. Come da documentazione, il caricamento con Load e LoadFrom posizionerà gli assembly in contesti diversi. Questo potrebbe essere d'aiuto.

  

  
1. Qualche spiegazione del perché il CLR ignora l'assembly già caricato?
  

Perché si trovano in un contesto diverso.

  

  
2. Qualche idea su come posso alleviare questo problema?
  

Carica dallo stesso contesto o aiuta il CLR a trovare l'assembly, magari collegando un gestore a AppDomain.AssemblyResolve .

Alternativa

Se la posizione da cui si stanno caricando gli assembly è una sottocartella in AppDomain.BaseDirectory, è possibile aggiungere semplicemente una voce al proprio 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: Questa sembra essere la spiegazione corretta. Per una spiegazione completa, Suzanne Cook ha questo post sul blog che elabora un po 'più di quello originale che hai pubblicato: http://blogs.msdn.com/suzcook/archive/2003 /05/29/57143.aspx

Di seguito è riportato il codice che sfrutta 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;
 }