Reiner und überprüfbarer Code

  • Artikel

Aktualisiert: November 2007

Bei der .NET-Programmierung unterstützt Visual C++ das Erstellen dreier unterschiedlicher Typen von Komponenten und Anwendungen: gemischt, rein und überprüfbar. Alle drei sind über die Compileroption /clr (Common Language Runtime-Kompilierung) verfügbar.

Hinweise

Weitere Informationen zu überprüfbaren Assemblys finden Sie unter:

Gemischt (/clr)

Gemischte Assemblys (kompiliert mit /clr) enthalten sowohl unverwaltete als auch verwaltete Teile, sodass sie .NET-Features verwenden, jedoch weiterhin unverwalteten Code enthalten können. Dadurch können Anwendungen und Komponenten für die Verwendung von .NET-Features aktualisiert werden, ohne dass das gesamte Projekt neu geschrieben werden muss. Derartiges Mischen von verwaltetem und nicht verwaltetem Code mit Visual C++ wird als C++ Interop bezeichnet. Weitere Informationen finden Sie unter Gemischte (systemeigene und verwaltete) Assemblys und unter Interoperabilität von systemeigenem Code und .NET.

Rein (/clr:pure)

Reine Assemblys (kompiliert mit /clr:pure) können sowohl systemeigene als auch verwaltete Datentypen enthalten, aber nur verwaltete Funktionen. Ebenso wie bei gemischten Assemblys ist Interop mit systemeigenen DLLs durch P/Invoke (siehe Verwenden von explizitem PInvoke in C++ (DllImport-Attribut)) auch bei reinen Assemblys möglich, allerdings sind die C++ Interop-Features nicht verfügbar. Darüber hinaus können reine Assemblys keine Funktionen exportieren, die von systemeigenen Funktionen aufrufbar sind, weil die Einstiegspunkte in einer reinen Assembly die __clrcall-Aufrufkonvention verwenden.

Vorteile von /clr:pure

  • Besseres Leistungsverhalten: Da reine Assemblys ausschließlich MSIL enthalten, gibt es keine systemeigenen Funktionen, sodass keine Übergänge zwischen verwalteten und unverwalteten Funktionen notwendig sind. (Funktionsaufrufe durch P/Invoke sind eine Ausnahme von dieser Regel.)

  • AppDomain-Unterstützung: Verwaltete Funktionen und CLR-Datentypen sind in Anwendungsdomänen vorhanden, was ihre Sichtbarkeit und Verfügbarkeit beeinflusst. Reine Assemblys sind domainfähig (__declspec(appdomain) ist für jeden einzelnen Typ vorhanden), sodass ein Zugreifen auf ihre Typen und Funktionen seitens anderer .NET-Komponenten einfacher und sicherer ist. Folglich arbeiten reine Assemblys einfacher mit anderen .NET-Komponenten zusammen als gemischte Assemblys.

  • Laden von Nicht-Datenträgern: Reine Assemblys können speicherintern und sogar als Stream geladen werden. Dies ist entscheidend für die Verwendung von .NET-Assemblys als gespeicherte Prozeduren. Darin unterscheiden sie sich von gemischten Assemblys, die aufgrund ihrer Abhängigkeit von Windows-Lademechanismen auf einem Datenträger vorliegen müssen, um ausgeführt werden zu können.

  • Reflektion: Es ist nicht möglich, eine Reflektion über gemischte ausführbare Dateien durchzuführen, während reine Assemblys die Reflektion in vollem Umfang unterstützen. Weitere Informationen finden Sie unter Reflektion in C++.

  • Hoststeuerbarkeit: Da reine Assemblys nur MSIL enthalten, verhalten sie sich vorhersagbarer und flexibler als gemischte Assemblys, wenn sie in Anwendungen verwendet werden, die das CLR hosten und sein Standardverhalten modifizieren.

Beschränkungen von /clr:pure

Dieser Abschnitt deckt derzeit von /clr:pure nicht unterstützte Features ab.

  • Reine Assemblys können nicht von nicht verwalteten Funktionen aufgerufen werden. Deshalb können reine Assemblys keine COM-Schnittstellen implementieren oder systemeigene Rückrufe verfügbar machen. Reine Assemblys können keine Funktionen über __declspec(dllexport) oder DEF-Dateien exportieren. Ebenso können mit der __clrcall-Konvention deklarierte Funktionen nicht über __declspec(dllimport) importiert werden. Funktionen in einem systemeigenen Modul können von einer reinen Assembly aufgerufen werden, aber reine Assemblys können keine von systemeigenen Funktionen aufrufbaren Funktionen verfügbar machen, sodass das Verfügbarmachen von Funktionalität in einer reinen Assembly durch verwaltete Funktionen in einer gemischten Assembly erfolgen muss. Weitere Informationen finden Sie unter Gewusst wie: Migrieren auf /clr:pure.

  • In Visual C++ 2005 werden ATL- und MFC-Bibliotheken von der Kompilierung im pure-Modus nicht unterstützt.

  • Reine .netmodules werden als Eingabe für den Visual C++-Linker nicht akzeptiert. Reine OBJ-Dateien werden jedoch vom Linker akzeptiert, und OBJ-Dateien enthalten ein Superset der in netmodules enthaltenen Informationen. Weitere Informationen finden Sie unter .NETMODULE-Dateien als Eingabe für den Linker.

  • Compiler-COM-Unterstützung (#Import) wird nicht unterstützt, da dies nicht verwaltete Anweisungen in die reine Assembly einführen würde.

  • Gleitkommaoptionen für die Ausrichtung und Ausnahmebehandlungen sind für reine Assemblys nicht einstellbar. Daher kann __declspec(align) nicht verwendet werden. Hierdurch werden einige Headerdateien, z. B. fpieee.h, als nicht mit /clr:pure kompatibel wiedergegeben.

  • Die GetLastError-Funktion im PSDK (Platform Software Development Kit) kann bei Kompilierung mit /clr:pure zu nicht definiertem Verhalten führen.

Überprüfbar (/clr:safe)

Die Compileroption /clr:safe generiert überprüfbare Assemblys, die wie in Visual Basic und C# geschriebene Assemblys die Anforderungen erfüllen, anhand derer die CLR (Common Language Runtime) gewährleisten kann, dass der Code die aktuellen Sicherheitseinstellungen nicht verletzt. Wenn die Sicherheitseinstellungen beispielsweise einer Komponente verbieten, auf die Festplatte zu schreiben, kann die CLR feststellen, ob eine überprüfbare Komponente dieses Kriterium erfüllt, bevor der Code ausgeführt wird. Es gibt für überprüfbare Assemblys keine CRT-Unterstützung. (CRT-Unterstützung steht reinen Assemblys durch eine Pure-MSIL-Version der C-Laufzeitbibliothek zur Verfügung.)

Diese Vorteile bieten überprüfbare Assemblys gegenüber reinen und gemischten Assemblys:

  • Erhöhte Sicherheit.

  • Einige Situationen erfordern dies (z. B. SQL-Komponenten).

  • Zukünftige Versionen von Windows werden überprüfbare Komponenten und Anwendungen zunehmend erfordern.

Ein Nachteil ist, dass C++ Interop-Features nicht verfügbar sind. Überprüfbare Assemblys können keine nicht verwalteten Funktionen oder systemeigenen Datentypen enthalten, selbst wenn der verwaltete Code nicht auf sie verweist.

Bei der Kompilierung von Anwendungen mit /clr:safe bedeutet "safe" nicht, dass es keine Fehler gibt; das bedeutet lediglich, dass CLR die Sicherheitseinstellungen zur Laufzeit überprüfen kann.

Unabhängig vom Assemblytyp werden Aufrufe systemeigener DLLs über P/Invoke durch verwaltete Assemblys kompiliert, können aber aufgrund von Sicherheitseinstellungen zur Laufzeit scheitern.

Hinweis:

Es gibt eine Codekonstellation, die kompiliert wird, obwohl dies eine unüberprüfbare Assembly zu Folge hat: Aufruf einer virtuellen Funktion durch eine Objektinstanz mit dem Bereichsauflösungsoperator. Beispiel: MyObj -> A::VirtualFunction();.

Siehe auch

Weitere Ressourcen

.NET-Programmierhandbuch