/clr (Compilation pour le Common Language Runtime)

Article
05/17/2015

Permet aux applications et aux composants d'utiliser les fonctionnalités du Common Language Runtime (CLR).

/clr[:options]

Arguments

options
Un ou plusieurs des commutateurs suivants, séparés par une virgule.
- /clr
  Crée des métadonnées pour l'application. Les métadonnées peuvent être consommées par d'autres applications CLR et permettent à l'application de consommer des types et des données dans les métadonnées d'autres composants CLR.
  
  Pour plus d'informations, consultez
  
  Assemblys mixtes (natif et managé) et
  
  Comment : effectuer une migration vers /clr.
- /clr:pure
  Produit un fichier de sortie MSIL (Microsoft Intermediate Language) uniquement qui n'a aucun code exécutable natif. Toutefois, il peut contenir des types natifs compilés dans MSIL.
  
  Pour plus d'informations, consultez Code pur et vérifiable (C++/CLI).
- /clr:safe
  Produit un fichier de sortie MSIL seul (aucun code exécutable natif) et vérifiable. /clr:safe permet les diagnostics de vérification (Outil PEVerify (Peverify.exe)).
  
  Pour plus d'informations, consultez Writing Verifiably Type-Safe Code.
- /clr:oldSyntax
  Active la syntaxe des extensions managées pour C++, la syntaxe Visual C++ d'origine pour la programmation CLR.
  
  La syntaxe des extensions managées pour C++ est déconseillée. Utilisez /clr:oldSyntax uniquement si vous maintenez une application qui utilise les extensions managées pour C++. Si vous développez une nouvelle application, utilisez la syntaxe mise à jour. Pour plus d'informations, consultez Fonctionnalités de langage pour cibler le CLR.
  
  Si vous possédez une application d'extensions managées pour C++, vous pouvez mettre à niveau le projet pour utiliser la nouvelle syntaxe. Pour plus d'informations, consultez Portage et mise à niveau de programmes.
- /clr:noAssembly
  Indique qu'un manifeste d'assembly ne doit pas être inséré dans le fichier de sortie. Par défaut, l'option noAssembly n'est pas activée.
  
  L'option noAssembly est déconseillée. Utilisez plutôt /LN (Créer le module MSIL). Pour plus d'informations, consultez Deprecated Compiler Options.
  
  Un programme managé qui ne possède pas de métadonnées d'assembly dans le manifeste est appelé module. L'option noAssembly peut être utilisée uniquement pour produire un module. Si vous compilez à l'aide de /c et /clr:noAssembly, spécifiez l'option /NOASSEMBLY dans la phase de l'éditeur de liens pour créer un module.
  
  Avant Visual C++ 2005, /clr:noAssembly /clr implicite. Toutefois, /clr prend désormais également en charge /clr:oldSyntax ; vous devez donc spécifier un formulaire /clr lorsque vous spécifiez /clr:noAssembly. Par exemple, /clr:noAssembly /clr crée un module à l'aide de la nouvelle syntaxe CLR Visual C++ et /clr:noAssembly,oldSyntax crée un module à l'aide des extensions managées pour C++.
  
  Avant Visual C++ 2005, /clr:noAssembly est obligatoire /LD. /LD est désormais implicite lorsque vous spécifiez /clr:noAssembly.
- /clr:initialAppDomain
  Permet à une application Visual C++ de fonctionner sur la version 1 du CLR. Si vous utilisez initialAppDomain, vous pouvez voir certains des problèmes évoqués dans BUG: AppDomainUnloaded exception lorsque vous utilisez des extensions managées pour des composants Visual C++ sur le site Web du Support technique Microsoft.
  
  Une application compilée à l'aide d'initialAppDomain ne doit pas être utilisée par une application qui utilise ASP.NET parce qu'il n'est pas pris en charge dans la version 1 du CLR.
- /clr:nostdlib
  Indique au compilateur d'ignorer le répertoire \clr par défaut. Le compilateur produit des erreurs si vous incluez plusieurs versions d'une DLL telle que System.dll. Cette option vous permet de spécifier l'infrastructure spécifique à utiliser pendant la compilation.

Notes

Le code managé est du code qui peut être inspecté et géré par le CLR. Ce code peut accéder aux objets managés. Pour plus d'informations, consultez Restrictions de /clr.

Pour plus d'informations sur le développement d'applications qui définissent et utilisent des types managés, consultez Fonctionnalités de langage pour cibler le CLR.

Une application compilée avec /clr peut contenir ou non des données managées.

Pour permettre le débogage sur une application managée, consultez /ASSEMBLYDEBUG (Ajouter DebuggableAttribute).

Seuls les types CLR seront instanciés sur le tas récupéré par le garbage collector. Pour plus d'informations, consultez Classes et structures (géré). Pour compiler une fonction en code natif, utilisez le pragma unmanaged. Pour plus d'informations, consultez managé, non managé.

Par défaut, l'option /clr n'est pas activée. Lorsque /clr est utilisé, /MD est également utilisé. Pour plus d'informations, consultez /MD, /MT, /LD (Utiliser la bibliothèque Runtime). /MD garantit que les versions dynamiquement liées, multithreads des routines d'exécution sont sélectionnées des fichiers d'en-tête standard (.h). Le multithreading est requis pour la programmation managée en partie parce que le garbage collector CLR exécute des finaliseurs dans un thread secondaire.

Si vous compilez avec /c, vous pouvez spécifier le type CLR (IJW, safe ou pure) du fichier de sortie résultant avec /CLRIMAGETYPE.

/clr implique /EHa, et aucune autre option /EH n'est prise en charge avec /clr. Pour plus d'informations, consultez /EH (Modèle de gestion des exceptions).

Pour plus d'informations sur la façon de déterminer le type d'image CLR d'un fichier, consultez /CLRHEADER.

Tous les modules passés à un appel donné de l'éditeur de liens doivent être compilés avec la même option du compilateur de bibliothèque Runtime (/MD ou /LD).

Utilisez l'option de l'éditeur de liens /ASSEMBLYRESOURCE pour incorporer une ressource dans un assembly. Les options de l'éditeur de liens /DELAYSIGN, /KEYCONTAINER et /KEYFILE vous permettent également de personnaliser la manière dont un assembly est créé.

Lorsque /clr est utilisé, le symbole _MANAGED est défini pour être 1. Pour plus d'informations, consultez Macros prédéfinies.

Les variables globales dans un fichier objet natif seront initialisées en premier (pendant DllMain si le fichier exécutable est une DLL), puis, les variables globales dans la section managée seront initialisées (avant que tout code managé soit exécuté). #pragmainit_seg affecte uniquement l'ordre d'initialisation dans les catégories managées et non managées.

La compilation à l'aide de /clr:safe est analogue à la compilation en utilisant /platform: anycpu dans les langages tels que C#.

Images safe et pure

Une image pure utilise une version CLR de la bibliothèque Runtime C. Toutefois, le CRT n'est pas vérifiable ; vous ne pouvez donc pas l'utiliser lors de la compilation avec /clr:safe. Pour plus d'informations, consultez Fonctions des bibliothèque CRT.

Les exemples de code natif qui ne peuvent pas s'afficher dans une image pure incluent assembleur inline, setjmp et longjmp.

Chaque point d'entrée d'une image pure ou safe est managé. Lorsque vous compilez à l'aide de /clr, le point d'entrée est natif. Pour plus d'informations, consultez __clrcall.

Lorsque vous compilez en utilisant /clr:safe, par défaut, les variables sont appdomain et ne peuvent pas être par processus. Pour /clr:pure, bien que appdomain soit la valeur par défaut, vous pouvez utiliser des variables process.

Lors de l'exécution d'un fichier .exe 32 bits compilé avec /clr ou avec /clr:pure sur un système d'exploitation 64 bits, l'application s'exécute sous WOW64, ce qui permet à une application 32 bits d'être exécutée par le CLR 32 bits sur un système d'exploitation 64 bits. Par défaut, un fichier .exe compilé à l'aide de /clr:safe sera exécuté sur le CLR 64 bits sur un ordinateur qui exécute un système d'exploitation 64 bits. (Sur un système d'exploitation 32 bits, le même fichier .exe s'exécuterait sur le CLR 32 bits.) Toutefois, une application sécurisée pourrait charger un composant 32 bits. Dans ce cas, une image safe qui s'exécute sous la prise en charge 64 bits du système d'exploitation échoue lors du chargement de l'application 32 bits (BadFormatException). Pour garantir qu'une image safe continuera de s'exécuter lors du chargement d'une image 32 bits sur un système d'exploitation 64 bits, vous devez utiliser /CLRIMAGETYPEafin de modifier les métadonnées (.corflags), en les marquant pour une exécution sous WOW64. La ligne de commande suivante est un exemple. (Substituez votre propre symbole d'entrée.)

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

Pour plus d'informations sur l'obtention d'un nom décoré, consultez Utilisation d'un listing pour afficher les noms décorés. Pour plus d'informations sur la programmation 64 bits, consultez Configuration des programmes pour 64 bits (Visual C++).

Pour obtenir des exemples, des procédures pas à pas et davantage d'informations, consultez :

Métadonnées et classes sans nom

Les classes sans nom apparaitront dans les métadonnées nommées comme suit : $UnnamedClass$crc-of-current-file-name$index$, où index est un compteur séquentiel des classes sans nom dans la compilation. Ainsi, l'exemple de code suivant génère une classe sans nom dans les métadonnées.

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

Utilisez ildasm.exe pour afficher les métadonnées.

Pour définir cette option de compilateur dans Visual Studio.

Dans Explorateur de solutions, cliquez avec le bouton droit sur le nom du projet, puis cliquez sur Propriétés pour ouvrir la boîte de dialogue Pages de propriétés du projet.
Sélectionnez le dossier Propriétés de configuration.
Dans la page de propriété Général, modifiez la propriété Prise en charge du Common Language Runtime.

Notes

Lorsque /clr est activé dans la boîte de dialogue Pages de propriétés, les propriétés d'option du compilateur qui ne sont pas compatibles avec /clr sont également ajustées, comme requis.Par exemple, si /RTC est défini et si /clr est activé ensuite, /RTC est désactivé.

De même, lorsque vous déboguez une application /clr, la propriété Type de débogueur doit être définie avec la valeur Mixte or Managé uniquement.Pour plus d'informations, consultez Paramètres de projet pour une configuration Debug C++.

Pour plus d'informations sur la création d'un module, consultez /NOASSEMBLY (Créer un module MSIL).