Mit gemischten DLLs von / clr: pure Projekte

Question

Ich baue ein Projekt zusammen mit einer DLL.

Die DLL muss nativen Code unterstützen, so erklärte ich es als / clr. Mein Projekt war initialy auch ein / clr Projekt und alles war in Ordnung. Allerdings würde ich gerne einige NUnit Tests umfassen, damit ich mein Hauptprojekt wechseln musste von / clr / clr:. Reines

Alles kompiliert noch aber jeder DLL-Aufruf erzeugt einen Laufzeitfehler. Als ich wieder zu / clr alles zufällt ist ok

In meiner DLL exportierten Funktionen werden wie folgt erklärt:

#define DllExport   __declspec( dllexport )
DllExport bool DisplayScan(bool bShow, bool bAllPasses) { }

Ich habe auch eine DEF-Datei die wirklichen Namen aller exportierten Funktionen

enthalten

LIBRARY "Controller"
EXPORTS
DisplayScan

Von meinem Hauptprojekt meiner Importe wie folgt erklärt werden:

#define _DllImport [DllImport("Controller.dll", CallingConvention = CallingConvention::Cdecl)] static
_DllImport bool DisplayScan(bool bShow, bool bAllPasses)

Wer jemals ein solches Problem gestoßen?

Answer 1

Ok alles funktioniert jetzt

In der Tat, es wurde von Anfang an zu arbeiten.

Moral: versuchen Sie nicht, ein char * in ein std :: string zu werfen

Schräge Sache: sein in / clr ok, bis Sie aus der Funktion zurück. Er stürzt sofort in / clr: pure

Answer 2

Im Grunde tun Sie etwas, das nicht unterstützt wird; / Clr: pure native DLL-Exporte. Zitiert von diesen „reinen Baugruppen MSDN-Artikel können Funktionen nicht exportieren, sind aufrufbar aus nativen Funktionen weil Einspeisepunkten in einer reinen Baugruppe die __clrcall verwenden Aufrufkonvention. "

Ich bin der beste Abhilfe nicht sicher. Doch mit ein wenig experimentieren, könnte man wahrscheinlich mit der / clr Option Vorteil der __clrcall Aufrufkonvention nehmen. Hier ist ein Link , die nützlich sein können. Von dem, was ich sammeln kann, sollten Sie sie in der Lage sein, diese verwalteten Klassen zu exportieren und konsumieren innerhalb einer verwalteten Assembly wie Ihr NUnit-Test-Projekt verwaltet, aber halten Sie Ihre unmanaged Exporte dort mit unterschiedlichen Methodensignaturen. Beachten Sie, dass, sobald Sie eine .net-Klasse über einen Export aussetzen, es müssen die __clrcall Aufrufkonvention verwenden.

Answer 3

Die Vorteile von / clr: pure

Bessere Performance: Da reine Baugruppen nur MSIL enthalten, gibt es keine native Funktionen, und somit auch keine verwaltete / nicht verwaltete Übergänge sind notwendig. (Funktion Anrufe durch P / Invoke sind eine Ausnahme von dieser Regel.)

AppDomain Awareness: Managed Funktionen und CLR-Datentypen existieren innerhalb Anwendungsdomänen, die ihre Sichtbarkeit und Zugänglichkeit betrifft. Reine Baugruppen sind Domain-aware (__declspec (Appdomain) wird für jeden Typ impliziert) so ihre Typen und Funktionalität von anderen .NET-Komponenten ist der Zugriff einfacher und sicherer. Als Ergebnis interoperabel reine Baugruppen einfacher mit anderen .NET-Komponenten als Misch Baugruppen.

Nicht-Plattenlade: Reine Baugruppen können im Speicher und sogar gestreamten geladen werden. Dies ist wichtig für die Verwendung von .NET-Assemblies als gespeicherte Prozeduren. Dies unterscheidet sich von gemischten Baugruppen, die aufgrund einer Abhängigkeit von den Windows-Lademechanismen, auf der Festplatte, um existieren muss auszuführen.

Reflexion: Es ist nicht möglich, gemischte ausführbare Dateien zu reflektieren über, während reine Baugruppen volle Reflexion unterstützen. Weitere Informationen finden Sie Reflection (C ++ / CLI).

Host Steuerbarkeit. Da reine Baugruppen nur MSIL enthalten, verhalten sie sich vorhersehbarer und flexibler als Misch Baugruppen, wenn sie in Anwendungen verwendet, die die CLR-Host und seine Standardverhalten ändern

Einschränkungen von / clr: pure

In diesem Abschnitt wird Funktionen derzeit nicht von / clr unterstützt:. Reinen

Reine Baugruppen können nicht von nicht verwalteten Funktionen aufgerufen werden. Daher reine Baugruppen können nicht COM-Schnittstellen implementieren oder native Rückrufe aus. Reine Baugruppen können nicht exportieren Funktionen über __declspec (dllexport) oder DEF-Dateien. Auch mit der __clrcall Konvention deklarierten Funktionen können nicht über __declspec (dllimport) importiert werden. Funktionen in einem nativen Modul können von einer reinen Baugruppe genannt werden, sondern reine Baugruppen können nativer aufrufbaren Funktionen aus, da so in einem reinen Montagebelichtungs Funktionalität muss durch Managed-Funktionen in einer gemischten Versammlung erfolgen. Siehe Gewusst wie: Migrieren von / clr:. Reines (C ++ / CLI) für weitere Informationen

ATL und MFC-Bibliotheken sind nicht durch reine Modus Kompilierung in Visual C ++ unterstützt.

Reine .netmodules sind nicht als Eingabe für den Visual C ++ Linker akzeptiert. Allerdings sind reine OBJ-Dateien vom Linker akzeptiert und OBJ-Dateien enthalten ein Superset von Informationen in netmodules enthalten. Siehe .netmodule Dateien als Linker Eingang für weitere Informationen.

Compiler COM-Unterstützung (Import) wird nicht unterstützt, da diese nicht verwalteten Anweisungen in die reine Montage einführen würde.

Gleitkomma-Optionen für die Ausrichtung und Ausnahmebehandlung sind nicht einstellbar für reine Baugruppen. Als Ergebnis __declspec (auszurichten) kann nicht verwendet werden. Dies macht einige Header-Dateien, wie fpieee.h, unvereinbar mit / clr:. Reinen

Die GetLastError Funktion im PSDK kann nicht definiertes Verhalten geben, wenn mit / clr kompiliert. Reine

Answer 4

Ihr Problem conventionCallingConvention = Calling ruft :: Cdecl ... Ihre Funktion wie die definieren oder verwenden stdcall oder clrcall, clecl ist für reine C

oder Problem ist hier: definieren diese Funktion extern nicht statisch