Identificare dipendenze problematiche nel progetto C++/CLI

Question

La mia applicazione compila bene, ma ottengo il seguente errore di runtime:

System.IO.FileNotFoundException was unhandled 
    HResult=-2147024770 
    Message=Could not load file or assembly {Wrapper} or one of its dependencies. The specified module could not be found. 

Il riferimento al wrapper nell'applicazione che si chiama sembra corretto. La dll Wrapper esiste nella posizione corretta.

Questo progetto è stato utilizzato per creare ed eseguire sul sistema di qualcun altro, l'ho visto dimostrato più volte. Quella persona/computer non è più disponibile. Alcuni percorsi di alcune dipendenze sono cambiati dall'ultima volta che è stato creato ed eseguito correttamente, ho corretto tutti gli errori di compilazione relativi a questo.

Giusto per chiarire la mia struttura del progetto:

Digraph G 
{ 
    App [ label = "My C# Application"] 
    Wrapper [ label = "C++/CLI Wrapper"] 
    Lib [ label = "C++ Library"] 
    Dll [ label = "My helper C# DLL"] 
    CDep [ label = "Series of deep C++ dependencies managed \n by CMake for Lib, hard coded relative paths for Wrapper."] 
    App->Wrapper->Lib->CDep; 
    App->Dll->Wrapper->CDep; 
} 

Wrapper è un C++/CLI wrapper per una libreria C++. L'errore viene attivato quando proviamo a caricare una classe nell'applicazione che ha un'istruzione using per il wrapper.

Il wrapper ha molte dipendenze, ma il messaggio di errore non indica quale dipendenza sia problematica. Questo è un sistema ampio e complicato, la maggior parte delle quali è costruita da altri team. I componenti C++ utilizzano CMake per ottenere tutte le dipendenze corrette, ma CMake non supporta C# in modo nativo.

Ho provato a utilizzare fuslogvw per trovare l'errore di associazione, ma non mi ha mostrato assolutamente nulla finché non ho modificato le impostazioni per includere tutti i binding e quindi ha mostrato solo vincoli riusciti. http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.100).aspx

I percorsi sono lunghi ma non superiori a 256 caratteri.

Avevo un avviso nella compilazione per Dll (vedi grafico sopra): Avviso 1 C'è stata una mancata corrispondenza tra l'architettura del processore del progetto in fase di costruzione "MSIL" e l'architettura del processore del riferimento "{cli_wrapper.dll } "," AMD64 ". Questa mancata corrispondenza potrebbe causare errori di runtime. Si prega di prendere in considerazione la possibilità di modificare l'architettura del processore di destinazione del progetto tramite Configuration Manager in modo da allineare le architetture del processore tra il progetto e i riferimenti, o prendere una dipendenza dai riferimenti con un'architettura del processore che corrisponda all'architettura del processore di destinazione del progetto.

In Configuration Manager, la DLL sta creando per piattaforma "Qualsiasi CPU" e Wrapper sta creando per "x64". Ho cambiato la DLL in x64. Ricevo ancora l'errore di runtime.

Could not load file or assembly or one of its dependencies Eseguito un contenuto di directory di compilazione pulito e cancellato. Nessun cambiamento. Riapri Visual Studio. Nessun cambiamento. Provato a cambiare nome assembly, spazio dei nomi predefinito e nome del progetto in modo che corrispondano. Nessun cambiamento.

Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format Credo che dobbiamo compilare per 64 bit. Siamo dipendenti da una libreria C++ a 64 bit.

Could not load file or assembly ... The parameter is incorrect Sono un amministratore locale.

How to enable assembly bind failure logging (Fusion) in .NET Provato le impostazioni del Registro di sistema, ma sembrano essere solo impostazioni fuslogvw. Nessun miglioramento dei dati di registro disponibili.

Molte altre domande simili avevano ASP o il servizio installa risposte specifiche.

Answer 1

Ho trovato il problema. C'era più di una versione della libreria disponibile per me, e stavo usando i file include da una versione e la libreria compilata dell'altro. La dipendenza Walker era la chiave per scoprire quale biblioteca aveva il problema, e se Aschratt lo avesse pubblicato come risposta piuttosto che come commento avrei accettato la sua risposta.

Answer 2

Ho avuto lo stesso errore con un progetto simile all'inizio di questa settimana. Innanzitutto, quando si utilizza C++/CLI, "Any CPU" non esiste. Ho dovuto costruire entrambi per x86 per superare le cose.

Inoltre, sebbene le dipendenze del mio wrapper fossero soddisfatte, è l'eccezione del wrapper che viene catturata dal CLR, quindi afferma che al wrapper manca una dipendenza. In realtà mi mancava una dipendenza per il C++ DLL del mio wrapper (nel mio caso si trattava semplicemente di dimenticare di rilasciare SDL2.dll e OpenAL32.dll nella mia nuova cartella di output di configurazione "Release" ... in precedenza funzionava solo con la configurazione di Debug in cui avevo già eliminato quelle DLL

Se sei sicuro che hai risolto le dipendenze del tuo wrapper, ti consiglio di utilizzare Dependency Walker per verificare le dipendenze della DLL nativa. potrebbe usare Assembly.GetReferencedAssemblies con un fuori script/programma per controllare due volte il vostro involucro così (o ILSpy: http://ilspy.net/).

Ultimo ma non meno importante, dare un'occhiata a questo:. http://www.codeproject.com/Articles/442784/Best-gotchas-of-Cplusplus-CLI Egli dettagli i primi due raccomandazioni i fatto così come altri

Buona fortuna!