/clr (Common Language Runtime-Kompilierung)

  • Artikel

Ermöglicht Anwendungen und Komponenten die Verwendung von Funktionen der Common Language Runtime (CLR).

/clr[:options]

Argumente

  • options
    Eine oder mehrere der folgenden Schalter, jeweils getrennt durch ein Komma.

    • /clr
      Erstellt Metadaten für die Anwendung. Die Metadaten, die von anderen CLR-Anwendungen verwendet werden können, und ermöglicht die Verwendung von Typen und Daten aus den Metadaten anderer CLR-Komponenten in der Anwendung.

      Weitere Informationen finden Sie unter

      Gemischte (systemeigene und verwaltete) Assemblys und

      Gewusst wie: Migrieren zu /clr.

    • /clr:pure
      Erzeugt eine Ausgabedatei nur mit Microsoft Intermediate Language (MSIL), die keinen systemeigenen ausführbaren Code enthält. Es kann jedoch systemeigene in MSIL kompilierte Typen enthalten.

      Weitere Informationen finden Sie unter Reiner und überprüfbarer Code (C++/CLI).

    • /clr:safe
      Erzeugt eine nur MSIL enthaltende (kein systemeigener ausführbarer Code) und überprüfbare Ausgabedatei. /clr:safe aktiviert Überprüfungsdiagnose (PEVerify-Tool (Peverify.exe)).

      Weitere Informationen finden Sie unter Writing Verifiably Type-Safe Code.

    • /clr:oldSyntax
      Aktiviert Managed Extensions für C++-Syntax, die ursprüngliche Visual C++-Syntax für CLR-Programmierung. 

      Managed Extensions for C++-Syntax ist veraltet. Verwenden Sie /clr:oldSyntax nur, wenn Sie eine Anwendung warten möchten, die Managed Extensions for C++ verwendet. Wenn Sie eine neue Anwendung entwickeln, verwenden Sie die aktualisierte Syntax. Weitere Informationen finden Sie unter Komponentenerweiterungen für Laufzeitplattformen.

      Wenn Sie über eine Managed Extensions for C++-Anwendung verfügen, können Sie das Projekt für die Verwendung der neuen Syntax aktualisieren. Weitere Informationen finden Sie unter Portieren und Aktualisieren von Programmen.

    • /clr:noAssembly
      Legt fest, dass ein Assemblymanifest nicht in die Ausgabedatei eingefügt wird. Die noAssembly-Option ist standardmäßig nicht aktiviert.

      Die noAssembly-Option ist veraltet. Verwenden Sie stattdessen /LN (Erstellen eines MSIL-Moduls). Weitere Informationen finden Sie unter Deprecated Compiler Options.

      Ein verwaltetes Programm, das keine Assemblymetadaten im Manifest aufweist, wird als Modul bezeichnet. Die noAssembly-Option kann nur verwendet werden, um ein Modul zu erzeugen. Wenn Sie mit /c und /clr:noAssembly kompilieren, legen Sie in der Linkerphase die /NOASSEMBLY-Option fest, um ein Modul zu erstellen.

      Vor Visual C++ 2005 implizierte /clr:noAssembly /clr. /clr unterstützt nun jedoch auch /clr:oldSyntax, daher müssen Sie das /clr-Formular festlegen, wenn Sie /clr:noAssembly angeben. Beispielsweise wird mit /clr:noAssembly /clr ein Modul mit der neuen Visual C++-CLR-Syntax erstellt, und mit /clr:noAssembly,oldSyntax wird ein Modul mit Managed Extensions for C++ erstellt.

      Vor Visual C++ 2005 erforderte /clr:noAssembly /LD. /LD wird jetzt impliziert, wenn Sie /clr:noAssembly angeben.

    • /clr:initialAppDomain
      Aktiviert die Ausführung einer Visual C++-Anwendung auf Version 1 der CLR. Wenn Sie initialAppDomain verwenden, dann werden möglicherweise einige der Probleme, die in der Microsoft Support-Website BUG: AppDomainUnloaded-Ausnahme, wenn Sie Erweiterungen für verwaltete Visual C++-Komponenten verwenden beschrieben werden.

      Eine Anwendung, die mit initialAppDomain kompiliert wird, sollte nicht von einer Anwendung verwendet werden, die ASP.NET verwendet, da dies in Version 1 der CLR nicht unterstützt wird.

    • /clr:nostdlib
      Weist den Compiler an, das Standard-\clr-Verzeichnis zu ignorieren. Der Compiler erzeugt Fehler, wenn Sie mehrere Versionen einer DLL wie System.dll einschließen. Mit dieser Option können Sie das bestimmte Framework angeben, das während der Kompilierung verwendet werden soll.

Hinweise

Unter verwaltetem Code versteht man Code, der von der CLR überprüft und verwaltet werden kann. Verwalteter Code kann auf verwaltete Objekte zugreifen. Weitere Informationen finden Sie unter Einschränkungen für "/clr".

Informationen zum Entwickeln von Anwendungen, mit denen verwaltete Typen definiert und verwendet werden, finden Sie unter Komponentenerweiterungen für Laufzeitplattformen.

Eine mit /clr kompilierte Anwendung kann möglicherweise verwaltete Daten enthalten.

Informationen zum Aktivieren des Debuggens einer verwalteten Anwendung finden Sie unter /ASSEMBLYDEBUG (DebuggableAttribute hinzufügen).

Auf dem Heap der Garbage Collection werden nur CLR-Typen instanziiert. Weitere Informationen finden Sie unter Klassen und Strukturen (Komponentenerweiterungen für C++). Um eine Funktion in systemeigenem Code zu kompilieren, verwenden Sie das unmanaged-Pragma. Weitere Informationen finden Sie unter managed, unmanaged.

In der Standardeinstellung ist /clr nicht aktiviert. Wenn /clr gültig ist, ist auch /MD gültig. Weitere Informationen finden Sie unter /MD, /MT, /LD (Laufzeitbibliothek verwenden). /MD stellt sicher, dass die dynamisch verknüpften, Multithreadversionen (.h) der Laufzeitroutinen aus den Standardheaderdateien ausgewählt werden. Multithreading ist für die verwaltete Programmierung erforderlich, da Finalizer vom CLR-Garbage Collector in einem Hilfsthread ausgeführt werden.

Wenn Sie mit /c kompilieren, können Sie den CLR-Typ (IJW, safe oder pure) der generierten Ausgabedatei mit /CLRIMAGETYPE angeben.

/clr impliziert /EHa, und keine anderen /EH-Optionen werden für /clr unterstützt. Weitere Informationen finden Sie unter /EH (Ausnahmebehandlungsmodell).

Weitere Informationen zum Bestimmen des CLR-Imagetyps einer Datei finden Sie unter /CLRHEADER.

Alle an einen bestimmten Aufruf des Linkers übergebenen Module müssen mit derselben Compileroption für die Laufzeitbibliothek kompiliert werden (/MD oder /LD).

Verwenden Sie die /ASSEMBLYRESOURCE-Linkeroption, um eine Ressource in eine Assembly einzubetten. Mit den Linkeroptionen /DELAYSIGN, /KEYCONTAINER und /KEYFILE können Sie das Erstellen einer Assembly auch anpassen.

Wenn /clr verwendet wird, wird das _MANAGED-Symbol als 1 definiert. Weitere Informationen finden Sie unter Vordefinierte Makros.

Die globalen Variablen in einer systemeigenen Objektdatei werden zuerst initialisiert (während "DllMain", wenn die ausführbare Datei eine DLL-Datei ist), bevor die globalen Variablen im verwalteten Abschnitt initialisiert werden (vor Ausführung von verwaltetem Code). #pragma init_seg wirkt sich nur auf die Reihenfolge der Initialisierung in den verwalteten und nicht verwalteten Kategorien aus.

Das Kompilieren mit /clr:safe entspricht dem Kompilieren mit /platform:anycpu in Sprachen wie C#.

safe- und pure-Abbilder

Für ein pure-Abbild wird eine CLR-Version der C-Laufzeitbibliothek (C Run-Time, CRT) verwendet. Da CRT jedoch nicht überprüft werden kann, können Sie CRT für die Kompilierung mit /clr:safe nicht verwenden. Weitere Informationen finden Sie unter CRT-Bibliotheksfunktionen.

Beispiele für systemeigenen Code, der nicht in einem pure-Abbild mit einer Inlineassembly verwendet werden kann, sind setjmp und longjmp.

Jeder Einstiegspunkt für ein pure- oder safe-Abbild ist verwalteter Code. Beim Kompilieren mit /clr ist der Einstiegspunkt systemeigener Code. Weitere Informationen finden Sie unter __clrcall.

Beim Kompilieren mit /clr:safe sind Variablen standardmäßig appdomain und können nicht prozessspezifisch sein. Für /clr:pure, obwohl appdomain der Standard ist, können Sie Prozessvariablen verwenden.

Beim Ausführen einer mit /clr oder /clr:pure unter einem 64-Bit-Betriebssystem kompilierten 32-Bit-EXE-Datei wird die Anwendung unter WOW64 ausgeführt, wodurch die Ausführung einer 32-Bit-Anwendung durch die 32-Bit-CLR unter einem 64-Bit-Betriebssystem ermöglicht wird. Standardmäßig wird eine mit /clr:safe kompilierte EXE-Datei in 64-Bit-CLR auf einem Computer mit 64-Bit-Betriebssystem ausgeführt. (Unter einem 32-Bit-Betriebssystem würde die gleiche EXE-Datei auf der 32-Bit-CLR ausgeführt.) Eine sichere Anwendung könnte jedoch eine 32-Bit-Komponente laden. In diesem Fall schlägt die Ausführung des mit 64-Bit-Unterstützung ausgeführten safe-Abbildes beim Laden der 32-Bit-Anwendung fehl (BadFormatException). Um sicherzustellen, dass das safe-Abbild beim Laden einer 32-Bit-Anwendung unter einem 64-Bit-Betriebssystem weiter ausgeführt wird, müssen Sie /CLRIMAGETYPE verwenden, um die Metadaten (.corflags) zu ändern und es für die Ausführung unter WOW64 kennzeichnen. Die folgende Befehlszeile ist ein Beispiel. (Ersetzen Sie durch ein eigenes Einstiegssymbol.)

cl /clr:safe t.cpp /link /clrimagetype:pure /entry:?main@@$$HYMHXZ /subsystem:console

Informationen zum Abrufen eines ergänzten Namens finden Sie unter Verwenden einer Auflistung für die Anzeige ergänzter Namen. Weitere Informationen zur 64-Bit-Programmierung finden Sie unter Programme zur Konfiguration von Visual C++ (64-Bit).

Beispiele, schrittweise Anweisungen und weitere Informationen finden Sie in folgenden Abschnitten:

Metadaten und unbenannte Klassen

Unbenannte Klassen werden in Metadaten, die mit werden, wie folgt: $UnnamedClass$crc-of-current-file-name$index$, wobei index eine laufende Nummer der unbenannten Klassen in der Kompilierung ist. Im folgenden Codebeispiel wird z. B. eine unbenannte Klasse in den Metadaten generiert.

// clr_unnamed_class.cpp
// compile by using: /clr /LD
class {} x;

Mit ildasm.exe können Sie Metadaten anzeigen.

So legen Sie diese Compileroption in Visual Studio fest

  1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen, und klicken Sie auf Eigenschaften, um das Dialogfeld Eigenschaftenseiten des Projekts zu öffnen.

  2. Wählen Sie den Ordner Konfigurationseigenschaften aus.

  3. Ändern Sie auf der Eigenschaftenseite Allgemein die Eigenschaft Common Language Runtime-Unterstützung.

    Hinweis

    Wenn /clr im Dialogfeld Eigenschaftenseiten aktiviert ist, werden die Eigenschaften der Compileroptionen, die nicht mit /clr kompatibel sind, gegebenenfalls auch angepasst.Wenn z. B. /RTC festgelegt ist und /clr aktiviert wird, wird /RTC deaktiviert.

    Legen Sie außerdem beim Debuggen einer /clr-Anwendung die Eigenschaft Debuggertyp auf Gemischt oder Nur verwaltet fest.Weitere Informationen finden Sie unter Projekteinstellungen für eine C++-Debugkonfiguration.

    Informationen zum Erstellen eines Moduls finden Sie unter /NOASSEMBLY (MSIL-Modul erstellen).

So legen Sie diese Compileroption programmgesteuert fest

Siehe auch

Referenz

Compileroptionen

Festlegen von Compileroptionen