/clr (Compilation pour le Common Language Runtime)

Article
08/21/2008

Mise à jour : novembre 2007

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

/clr[:options]

Arguments

options
Un ou plusieurs des éléments suivants, séparés par une virgule :
- /clr
  Crée pour votre application des métadonnées qui peuvent être utilisées par d'autres applications CLR et permet à votre application d'utiliser les types et données contenus dans les métadonnées d'autres composants CLR.
  
  Pour plus d'informations, consultez :
  - Assemblys mixtes (natif et managé)
  - Comment : effectuer une migration vers /clr
- /clr:pure
  Produit un fichier de sortie MSIL uniquement sans code exécutable natif, même s'il peut contenir des types natifs compilés en MSIL.
  
  Pour plus d'informations, consultez Code pur et vérifiable.
- /clr:safe
  Produit un fichier de sortie MSIL uniquement (aucun code exécutable natif) et vérifiable. /clr:safe active les diagnostics de vérification (Outil PEVerify Tool (Peverify.exe)).
  
  Pour plus d'informations, consultez Écriture de code de type sécurisé vérifié.
- /clr:oldSyntax
  Active la syntaxe des extensions managées pour C++, la syntaxe Visual C++ d'origine pour la programmation CLR.
  
  Remarque La syntaxe des extensions managées pour C++ est désapprouvée dans Microsoft Visual C++ 2005. Vous devez utiliser uniquement /clr:oldSyntax si vous gérez une application Visual C++ qui utilise les extensions managées pour C++. Si vous créez une nouvelle application, utilisez la syntaxe mise à jour ; pour plus d'informations, consultez Language Features for Targeting the CLR.
  
  Si vous possédez une application d'extensions managées pour C++, vous pouvez commencer à porter votre projet pour utiliser la nouvelle syntaxe ; pour plus d'informations, consultez Portage et mise à niveau de programmes.
- /clr:noAssembly
  L'option 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.
  
  Remarque L'option noAssembly est désapprouvée dans Visual C++ 2005. Utilisez /LN (Créer le module MSIL) à la place. Pour plus d'informations, consultez Options du compilateur désapprouvées dans Visual C++ 2005.
  
  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 (Compiler sans liaison) et de /clr:noAssembly, spécifiez l'option /NOASSEMBLY (Créer un module MSIL) dans la phase de l'éditeur de liens pour créer un module.
  
  Avant Visual C++ 2005, /clr:noAssembly impliquait /clr. 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 exigeait /LD. /LD est désormais implicite lorsque vous spécifiez /clr:noAssembly.
- /clr:initialAppDomain
  Permet à une application Visual C++ de s'exécuter sous la version 1 du Common Language Runtime. Si vous utilisez initialAppDomain, vous pouvez rencontrer certains des problèmes décrits dans l'article Q309694 de la Base de connaissances. Vous trouverez les articles de la Base de connaissances sur le média de MSDN Library ou à l'adresse https://www.microsoft.com/france/support/.
  
  Une application compilée avec initialAppDomain ne doit jamais être utilisée par une application utilisant ASP.NET ; passez à un runtime plus récent pour effectuer un travail ASP.NET avec C++.

Notes

Le code managé est un code qui peut être inspecté et managé par le Common Language Runtime. Ce code peut accéder aux objets managés.

Voir aussi Restrictions de /clr.

Pour plus d'informations sur le développement d'applications qui définissent et utilisent des types managés, consultez Language Features for Targeting the 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 and Structs (Managed). Pour compiler une fonction en code natif, utilisez le pragma unmanaged. Pour plus d'informations, consultez managed, unmanaged.

Par défaut, l'option /clr n'est pas activée. Lorsque /clr est activé, /MD l'est également (pour plus d'informations, consultez /MD). /MD vérifie que les versions multithread liées dynamiquement des routines runtime sont sélectionnées à partir des fichiers d'en-tête standard (.h). Le multithreading est nécessaire 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 résultant avec /CLRIMAGETYPE (Spécifier le type d'une image CLR).

/clr implique /EHa, et aucune autre option /EH n'est autorisée 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 ont dû ê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 (Incorporer une ressource managée) pour incorporer une ressource dans un assembly. Les options de l'éditeur de liens /DELAYSIGN (Signer partiellement un assembly), /KEYCONTAINER (Spécifier un conteneur de clé pour signer un assembly) et /KEYFILE (Spécifier une clé ou une paire de clés pour signer un assembly) vous permettent également de personnaliser la manière dont un assembly est créé.

Lorsque /clr est utilisé, le symbole _MANAGED a la valeur 1. Pour plus d'informations, consultez Predefined Macros.

Les variables globales contenues dans un fichier objet natif seront initialisées en premier (pendant DllMain si le fichier exécutable est une DLL), suivies des variables globales contenues dans la section managée (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 avec /clr:safe est analogue à la compilation avec /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 C Run-Time Libraries.

Citons comme exemples de code natif qui ne peut pas apparaître dans une image pure l'assembly inline, setjmp ou longjmp.

Chaque point d'entrée d'une image pure ou safe est managé. Lors de la compilation avec /clr, le point d'entrée est natif. Pour plus d'informations, consultez __clrcall.

Lors de la compilation avec /clr:safe, les variables sont appdomain par défaut et ne peuvent pas être par processus. Avec /clr:pure, appdomain est la valeur par défaut, mais 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é avec /clr:safe s'exécute dans le CLR 64 bits sur un ordinateur utilisant un système d'exploitation 64 bits (sur un système d'exploitation 32 bits, le même fichier .exe s'exécuterait dans le CLR 32 bits). Toutefois, il est possible que votre application safe charge 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 /CLRIMAGETYPE (Spécifier le type d'une image CLR) afin de modifier les métadonnées (.corflags), en les marquant pour une exécution sous WOW64. Vous trouverez ci-dessous un exemple de ligne de commande (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 Programmation 64 bits (Comment faire dans 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 s'afficheront dans les métadonnées comme suit : $UnnamedClass$crc-of-current-file-name$index$, où index désigne le nombre 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 with: /clr /LD
class {} x;

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

Pour définir cette option du compilateur dans l'environnement de développement Visual Studio

Ouvrez la boîte de dialogue Pages de propriété du projet. Pour plus d'informations, consultez Comment : ouvrir les pages de propriétés d'un projet.
Cliquez sur le dossier Propriétés de configuration.
Cliquez sur la page de propriétés Général.

Modifiez la propriété Prise en charge du Common Language Runtime.

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

Remarque :
Lorsque /clr est activé dans une boîte de dialogue Pages de propriétés d'un projet, les propriétés des options du compilateur qui ne sont pas compatibles avec /clr seront ajustées, si nécessaire. 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++.