Freigeben über

/clr (Common Language Runtime-Kompilierung)

  • Artikel

Aktualisiert: November 2007

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

/clr[:options]

Argumente

  • options
    Eine oder mehrere der folgenden, getrennt durch ein Komma:

    • /clr
      Erstellt Metadaten für die Anwendung, 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 folgenden Themen:

    • /clr:pure
      Erzeugt eine reine MSIL-Ausgabedatei ohne systemeigenen ausführbaren Code, auch wenn zu MSIL kompilierte systemeigene Typen enthalten sein können.

      Weitere Informationen finden Sie unter Reiner und überprüfbarer Code.

    • /clr:safe
      Erzeugt eine reine und überprüfbare MSIL-Ausgabedatei (ohne systemeigenen ausführbaren Code). /clr:safe ermöglicht die Prüfdiagnose (PEVerify-Tool (Peverify.exe)).

      Weitere Informationen finden Sie unter Schreiben von überprüfbar typsicherem Code.

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

      Hinweis   Managed Extensions for C++-Syntax ist in Microsoft Visual C++ 2005 veraltet. Sie sollten daher /clr:oldSyntax nur verwenden, wenn Sie eine Visual C++-Anwendung beibehalten möchten, die Managed Extensions for C++ verwendet. Wenn Sie eine neue Anwendung entwickeln, verwenden Sie die aktualisierte Syntax. Weitere Informationen finden Sie unter Language Features for Targeting the CLR.

      Wenn eine Anwendung mit Managed Extensions für C++ vorhanden ist, können Sie Ihr Projekt zunächst portieren, um die neue Syntax zu verwenden. Weitere Informationen finden Sie unter Portieren und Aktualisieren von Programmen

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

      Hinweis   Die noAssembly-Option ist in Visual C++ 2005 veraltet. Stattdessen sollte /LN (Erstellen eines MSIL-Moduls) verwendet werden. Weitere Informationen finden Sie unter Veraltete Compileroptionen in Visual C++ 2005.

      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 (Kompilieren ohne Verknüpfen) und /clr:noAssembly kompilieren, legen Sie in der Linkerphase die /NOASSEMBLY (MSIL-Modul erstellen)-Option fest, um ein Modul zu erstellen.

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

      Vor der Einführung von Visual C++ 2005 erforderte /clr:noAssembly die Option /LD. /LD ist nun impliziert, wenn Sie /clr:noAssembly angeben.

    • /clr:initialAppDomain
      Ermöglicht die Ausführung einer Visual C++-Anwendung auf Version 1 der Common Language Runtime. Wenn Sie initialAppDomain verwenden, erhalten Sie möglicherweise einige der Fehler, die in Knowledge Base-Artikel Q309694 beschrieben werden. Knowledge Base-Artikel finden Sie auf der MSDN Library-CD-ROM oder unter https://support.microsoft.com/support.

      Eine mit initialAppDomain kompilierte Anwendung sollte keinesfalls von einer Anwendung genutzt werden, die ASP.NET verwendet. Um ASP.NET zusammen mit C++ zu verwenden, sollten Sie auf eine aktuellere Laufzeitversion aktualisieren.

Hinweise

Unter verwaltetem Code versteht man Code, der von der Common Language Runtime überprüft und verwaltet werden kann. Verwalteter Code kann auf verwaltete Objekte zugreifen.

Siehe auch Einschränkungen für "/clr".

Informationen zur Entwicklung von Anwendungen, die verwaltete Typen definieren und verwenden, finden Sie unter Language Features for Targeting the CLR.

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

Informationen zum Debuggen 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 Classes and Structs (Managed). 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 aktiviert ist, ist /MD ebenfalls aktiviert (weitere Informationen finden Sie unter /MD). /MD stellt sicher, dass die dynamisch verknüpften Multithreadversionen der Laufzeitroutinen aus den Standardheaderdateien (.h) ausgewählt werden. Multithreading ist für die verwaltete Programmierung zum Teil erforderlich, da der CLR-Garbage Collector Finalizer in einem Hilfsthread ausführt.

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

/clr impliziert /EHa, und keine anderen /EH-Optionen sind mit /clr zulässig. Weitere Informationen finden Sie unter /EH (Ausnahmebehandlungsmodell).

Weitere Informationen zur Bestimmung des CLR-Bildtyps 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 worden sein (/MD oder /LD).

Verwenden Sie die /ASSEMBLYRESOURCE (Verwaltete Ressource einbetten)-Linkeroption, um eine Ressource in eine Assembly einzubetten. Mit den Linkeroptionen /DELAYSIGN (Assembly teilweise signieren), /KEYCONTAINER (Schlüsselcontainer zum Signieren einer Assembly festlegen) und /KEYFILE (Schlüsselcontainer oder Schlüsselpaar zum Signieren einer Assembly festlegen) können Sie auch einstellen, wie eine Assembly erstellt wird.

Bei Verwendung von /clr wird das _MANAGED-Symbol als 1 definiert. Weitere Informationen finden Sie unter Predefined Macros.

Die globalen Variablen in systemeigenen Objektdateien werden zuerst initialisiert (während DllMain, wenn die ausführbare Datei eine DLL ist), anschließend die globalen Variablen im verwalteten Bereich (vor jeder Ausführung von verwaltetem Code). #pragmainit_seg betrifft nur die Reihenfolge der Initialisierung innerhalb der verwalteten und nicht verwalteten Kategorien.

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

safe- und pure-Abbilder

Ein pure-Abbild verwendet eine CLR-Version der C-Laufzeitbibliothek. Da CRT jedoch nicht überprüfbar ist, können Sie CRT für die Kompilierung mit /clr:safe nicht verwenden. Weitere Informationen finden Sie unter C Run-Time Libraries.

Beispiele für systemeigenen Code, der nicht in einem pure-Abbild mit einer Inlineassembly verwendet werden kann, sind setjmp oder 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. Mit /clr:pure ist appdomain der Standardwert, Sie können jedoch process-Variablen 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, das die Ausführung einer 32-Bit-Anwendung durch 32-Bit-CLR unter einem 64-Bit-Betriebssystem ermöglicht. Standardmäßig wird eine mit /clr:safe kompilierte EXE-Datei in 64-Bit-CLR auf einem Computer mit 64-Bit-Betriebssystem kompiliert (unter einem 32-Bit-Betriebssystem würde dieselbe EXE-Datei in 32-Bit-CLR ausgeführt). Es ist jedoch möglich, dass von der safe-Anwendung eine 32-Bit-Komponente geladen wird. 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 (Angeben des CLR-Bildtyps) verwenden, um die Metadaten (.corflags) zu ändern und es für die Ausführung unter WOW64 kennzeichnen. Im Folgenden eine Beispielbefehlszeile (setzen Sie Ihr eigenes Einstiegssymbol ein):

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 64-Bit-Programmierung (Vorgehensweise in Visual C++).

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

Metadaten und unbenannte Klassen

Unbenannte Klassen werden in Metadaten mit folgender Benennung angezeigt: $UnnamedClass$crc des aktuellen Dateinamens$Index$, wobei Index für eine sequenzielle Anzahl unbenannter Klassen in der Kompilierung steht. Im folgenden Codebeispiel wird z. B. eine unbenannte Klasse in den Metadaten erstellt:

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

Mit ildasm.exe können Sie Metadaten anzeigen.

So legen Sie diese Compileroption in der Visual Studio-Entwicklungsumgebung fest

  1. Öffnen Sie das Dialogfeld Eigenschaftenseiten des Projekts. Ausführliche Informationen finden Sie unter Gewusst wie: Öffnen von Projekteigenschaftenseiten.

  2. Klicken Sie auf den Ordner Konfigurationseigenschaften.

  3. Klicken Sie auf die Eigenschaftenseite Allgemein.

  4. Ändern Sie die Common Language Runtime-Unterstützung-Eigenschaft.

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

    Hinweis:

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

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

So legen Sie diese Compileroption programmgesteuert fest

Siehe auch

Referenz

Compileroptionen

Festlegen von Compileroptionen