C # C ++ / CLI C DLL System.IO.FileNotFoundException

Question

Ich erhalte System.IO.FileNotFoundException: The specified module could not be found , wenn C # -Code ausgeführt wird, die eine C ++ / CLI Versammlung ruft die wiederum einen reinen C-DLL aufruft. Es geschieht, sobald ein Objekt instanziiert, das die reinen C-DLL-Funktionen aufruft.

Backings ist reines C. CPPDemoViewModel ist C ++ / CLI Aufruf Backings es einen Verweis auf Backings hat.

habe ich versucht, einen möglichst einfachen Fall - ein neues C # Unit-Test-Projekt hinzufügen, die nur ein Objekt in CPPDemoViewModel definiert zu schaffen versucht. Ich habe einen Verweis aus dem C # Projekt CPPDemoViewModel.

Ein C ++ / CLI-Testprojekt arbeitet nur mit den hinzugefügt ref CPPDemoViewModel fein es ist also etwas zwischen den Sprachen geht.

ich Visual Studio 2008 SP1 mit .NET 3.5 SP1 bin mit. Ich baue auf x64 Vista, wurde dann aber vorsichtig, um sicherzustellen, ist mein Platform Ziel x86 gesetzt.

Das fühlt sich an wie etwas dumm und offensichtlich fehlt mir, aber es wäre noch mehr dumm von mir Zeit versucht, sie zu verschwenden privat zu lösen, so bin ich hier raus peinlich mich!

Dies ist ein Test für ein Projekt eine riesige Menge von Legacy-C-Code zu portieren, die ich mit einem Viewmodel in einer DLL zu halten implementiert in C ++ / CLI.

Bearbeiten Nach der Überprüfung Verzeichnissen, kann ich bestätigen, dass der BackingStore.dll kopiert worden ist.

Ich habe die Standard einzigartigen Projektordner mit einer typischen Multiprojektlösung erstellt.

WPFViewModelInCPP
  BackingStore
  CPPViewModel
  CPPViewModelTestInCS
    bin
      Debug
  Debug

Die übergeordnete Debug erscheint ein gemeinsamer Ordner mit dem C und C ++ / CLI-Projekten verwendet werden, zu meiner Überraschung.

WPFViewModelInCPP \ Debug enthält BackingStore.dll, CPPDemoViewModel.dll, CPPViewModelTest.dll und ihre zugehörigen ILK und PDB-Dateien

WPFViewModelInCPP \ CPPViewModelTestInCS \ bin \ Debug enthält CPPDemoViewModel und CPPViewModelTestInCS .dll und PDB-Dateien, aber nicht Backings. Jedoch manuell Backings in das Verzeichnis zu kopieren nicht den Fehler beheben.

CPPDemoViewModel hat die Eigenschaft Lokale Kopie Set, das nehme ich an für das Kopieren seiner DLL verantwortlich ist, wenn, wenn Bezug genommen wird. Ich kann keinen Verweis aus einem C # -Projekt zu einem reinen C-DLL hinzufügen - es sagt nur Ein Verweis auf Backing Store kann nicht hinzugefügt werden

.

Ich bin mir nicht sicher, ob ich nur ein Problem oder zwei.

kann ich einen altmodischen Kopieren Build-Schritt verwenden, um die BackingStore.dll in jedes gegebenen C # Projekt Verzeichnisse zu kopieren, obwohl ich das neue .net-Modell, dass nicht verlangte gehofft habe.

Dependency Walker sagt mir, dass die fehlende Datei GPSVC.dll ist die vorgeschlagen wurde, zeigt an Sicherheitseinstellung Fragen. Ich vermute, dies ist ein roter Hering.

edit2 Mit einer manuellen Kopie BackingStore.dll an die ausführbare Datei benachbart zu sein, arbeitet die GUI jetzt gut. Das C # Testprojekt hat immer noch Probleme, die ich vermute aufgrund der Laufzeitumgebung eines Testprojektes ist, aber ich kann jetzt ohne leben.

Answer 1

Die Antwort für den GUI, andere als Ausgabeeinstellungen zu ändern, war die Zugabe eines Pre-Build-Schrittes

copy $(ProjectDir)..\Debug\BackingStore.* $(TargetDir)

Die Antwort für die Test-Projekte war die fehlende DLL auf die Registerkarte Bereitstellung des testrunconfig hinzuzufügen. Sie können entweder tun, indem sie direkt die Standard-Bearbeitung LocalTestRun.testrunconfig (erscheint in Lösung unter Lösung Items) oder Rechtsklick auf die Lösung und einen neuen Testlauf Config hinzufügen, die dann unter dem Haupt-Test erscheinen Menü.

Danke für die Antworten auf diese Frage SO auf Prüfkonfigurationen für mich auf die Antwort führt.

Answer 2

Sind die C- und C ++ DLLs im selben Verzeichnis wie die C # Assembly, die Ausführung wird?

Sie müssen möglicherweise Ihre Projekt Ausgabeeinstellungen ändern, so dass die C # Montage und die anderen DLLs alle im selben Ordner landen.

ich oft habe die Dependency Walker in Fällen wie diesem verwendet werden; es ist eine Plausibilitätsprüfung, die alle Abhängigkeiten zeigt, dass tatsächlich gefunden werden kann.

Wenn Ihre App ausgeführt wird, können Sie auch wollen Prozess ausprobieren auf dem Code, den Sie ausführen, um zu sehen, welche DLLs verwiesen werden, und wo sie sich befinden.

Answer 3

Der Grund, warum dies passiert ist, weil Sie entweder DLLMain aus verwaltetem Code laden, bevor die CRT eine Gelegenheit hat, initialisiert werden. Sie können nicht irgendwelche Code gesteuert, durchgeführt werden DIREKT oder INDERECTLY aus einem Effekt von DllMain Benachrichtigungen. (Siehe: Expert C ++ / CLI: NET für Visual C ++ Programmierer, Kapitel 11 ++).

oder Sie haben keinen nativen Einstiegspunkt definiert wahtsoever, aber Sie haben zu MSVCRT verknüpft. Die CLR ist für Sie mit / clr automatisch initialisiert, dieses Detail verursacht viel Verwirrung und müssen berücksichtigt werden. Ein Mixed-Mode-DLL tatsächlich Verzögerung Lasten die CLR durch die Verwendung von Hot-Patching all verwalteten Einstiegspunkt vtables in Ihren Klassen.

Eine Reihe von Klasseninitialisierung Fragen umgibt dieses Thema, loader Sperre und Verzögerung Laden CLR manchmal etwas Trickey ist. Versuchen globale statische zu erklären und nicht verwenden #pragma managed / unmanaged, isolieren Sie den Code mit / clr pro-Datei.

Wenn Sie Ihren Code nicht vom verwalteten Code isolieren kann, und haben Probleme, (nach einigen dieser Schritte zu unternehmen), können Sie die CLR in Richtung Hosting selbst auch einen Blick und vielleicht durch die Anstrengung gehen einen Domain-Manager zu erstellen, das wäre sicherzustellen, dass Ihr voll "in-the-Loop" von Laufzeitereignissen und Bootstrapping.

Dies ist exactally warum es nothting todo mit Ihrem Suchpfad oder Initialisierung hat. Leider ist der Fusion-Protokoll-Viewer nicht so viel helfen (was der üblicher Platz suchen .NET CLR-Assembly Bindungsprobleme nicht Dependency Walker).

Die Verknüpfung hat statisch nichts todo mit dieser entweder. Sie können nicht Link statisch eine C ++ / CLI-Anwendung, die im gemischten Modus ist.

1. Zeigen Sie DllMain-Funktion in eine Datei von selbst aus.
2. Stellen Sie sicher, dass diese Datei hat nicht wurde / CLR in den Build-Optionen festgelegt ( Datei Build-Optionen)
3. Stellen Sie sicher, dass Ihre Verknüpfung mit / MD oder / MDd, und alle Abhängigkeiten, die Sie genau den gleichen CRT verwenden Link.
4. Überprüfen Sie Ihren Linker Einstellungen für / defaultlib und / umfassen jegliche possiable Referenz Probleme zu identifizieren, können Sie einen Prototyp in Ihrem Code und die Verwendung erklären kann / include Standardbibliothek Link Auflösung außer Kraft zu setzen.

Viel Glück, überprüfen Sie auch das Buch, es ist sehr gut.

Answer 4

Dies ist ein interessantes Dilemma. Ich habe noch nie ein Problem Laden nativen .DLLs von C ++ / CLI nach einem Aufruf in es von C # zu hören. Ich kann nur annehmen, dass das Problem ist, wie @ Daniel L vorgeschlagen, und dass Ihre DLL ist einfach nicht in einem Pfad der Montage Lader finden.

Wenn Daniels Vorschlag nicht funktioniert, ich schlage vor, Sie versuchen statisch den nativen C-Code in das C ++ / CLI-Programm verknüpft, wenn Sie können. Das würde löst sicherlich das Problem, da die DLL würde dann vollständig in die C ++ / CLI .DLL- absorbiert werden.

Answer 5

Stellen Sie sicher, dass das Zielsystem die richtige MS Visual C Laufzeit hat, und dass Sie nicht versehentlich bauen den C-DLL mit einer Debug-Laufzeit.

Answer 6

das gleiche Problem auf 64-Bit-Vista-Schalt hat. Unsere Anwendung ruft Win32-DLLs, die das Ziel Build für die Anwendung war verwirrend. So beheben Sie es haben wir folgendes:

1. Gehen Sie Eigenschaften zu projizieren;
2. Wählen Sie Erstellen Registerkarte;
3. Ändern 'Platform Ziel:' Option x86;
4. Erstellen Sie die Anwendung.

Wenn ich die Anwendung wieder lief es funktionierte.