Riferimento Assemblea non trovato, anche se l'assemblaggio è nella stessa directory

Question

Al momento stiamo sviluppando un add-in per alcuni software. Abbiamo deciso di sviluppare in .NET, anche se l'applicazione è scritta in una lingua nativa. Dal momento che ci sono stati alcuni problemi che creano direttamente l'interfaccia esterna in .NET, abbiamo deciso di costruire una DLL ponte in C ++ / CLI, che fa un po 'inizializzazione di base e quindi carica il nostro gestito assemblaggio e crea un controllo utente da questo.

In un componente aggiuntivo file .ini, il C ++ / CLI DLL viene fatto riferimento per nome, quindi l'applicazione verrà caricata da lì. Il DLL NET, tuttavia, è solo riferimento dal C ++ / CLI DLL (come riferimento gestito), quindi tipi esportati sono disponibili. In questa configurazione, howerver, l'applicazione si blocca il caricamento della DLL NET.

Abbiamo trovato rapidamente che potremmo semplicemente sottoscrivere l'evento AppDomain.AssemblyResolve per caricare il .NET assembly dalla stessa directory in cui il C ++ / CLI DLL è, in modo che il problema si è risolto.

La domanda reale è: perché il caricatore non trova la DLL .NET, anche se è nella stessa directory del gruppo di riferimento è? Ho sempre aspettato che le assemblee di carico cercherà prima nella stessa directory, e non solo nella directory di lavoro corrente. Perché un eseguibile trovare un assembly se cambia la sua directory di lavoro, allora? O sono cose diverse se il CLR viene richiamato caricando un C ++ / CLI di montaggio (piuttosto che un'applicazione gestita puro)?

Answer 1

I raccomanderebbe di utilizzare fuslogvw.exe per analizzare problemi di questo tipo:

  

Fuslogvw.exe e la diagnosi. NET problemi di assemblaggio vincolante

E, naturalmente, lo strumento general purpose per l'analisi dei problemi con i file non trovato:

  

Process Monitor

Answer 2

Il percorso di sondaggio per gli assiemi arrivare a essere un po 'imprevedibile quando un EXE non gestito avvia il processo. Proprio perché è caricato un C ++ / CLI DLL, magari attraverso LoadLibrary o SetDllDirectory, non in alcun modo il percorso di sondaggio per il CLR.

Ma questo è solo indovinare. Non c'è bisogno di indovinare quando si guarda l'output prodotto dal Fuslogvw.exe. Essa mostra esattamente ciò che viene sondato e quali criteri vengono applicati. A risolvere il problema con un file App.exe.config (elemento di sondaggio) o addirittura da AssemblyResolve.