Options du compilateur C# qui contrôlent la sortie du compilateur.

Les options suivantes contrôlent la génération de sortie du compilateur.

DocumentationFile

L’option DocumentationFile vous permet de placer des commentaires de documentation dans un fichier XML. Pour en savoir plus sur la documentation de votre code, consultez Balises recommandées pour les commentaires de documentation. La valeur spécifie le chemin d’accès au fichier XML de sortie. Le fichier XML contient les commentaires contenus dans les fichiers de code source de la compilation.

<DocumentationFile>path/to/file.xml</DocumentationFile>

Le fichier de code source qui contient les instructions principales ou de niveau supérieur est généré en premier dans le code XML. Il est souvent souhaitable d’utiliser le fichier .xml généré avec IntelliSense. Le nom du fichier .xml doit être identique au nom de l’assembly. Le fichier .xml doit figurer dans le même répertoire que l’assembly. Quand l’assembly est référencé dans un projet Visual Studio, le fichier .xml est également trouvé. Pour plus d’informations sur la génération de commentaires de code, consultez Fourniture de commentaires de code. À moins que vous compiliez avec <TargetType:Module>, file contiendra des balises <assembly> et </assembly> spécifiant le nom du fichier qui contient le manifeste d’assembly pour le fichier de sortie. Pour obtenir des exemples, consultez Comment utiliser les fonctionnalités de documentation XML.

Cette option peut être utilisée dans n’importe quel projet de style SDK .NET. Pour plus d’informations, consultez la propriété DocumentationFile.

OutputAssembly

L’option OutputAssembly spécifie le nom du fichier de sortie. Le chemin de sortie spécifie le dossier dans lequel la sortie du compilateur est placée.

<OutputAssembly>folder</OutputAssembly>

Spécifiez le nom complet et l’extension du fichier que vous voulez créer. Si vous ne spécifiez pas le nom du fichier de sortie, MSBuild utilise le nom du projet pour spécifier le nom de l’assembly de sortie. Les anciens projets de style utilisent les règles suivantes :

• Un fichier .exe prend son nom du fichier de code source qui contient la méthode Main ou les instructions de niveau supérieur.
• Un fichier .dll ou .netmodule prend le nom du premier fichier de code source.

Les modules générés dans le cadre d’une compilation deviennent des fichiers associés à un assembly également généré pendant la compilation. Utilisez ildasm.exe pour afficher le manifeste d’assembly et identifier les fichiers associés.

L’option de compilateur OutputAssembly est nécessaire pour faire d’un fichier exe la cible d’un assembly friend.

PlatformTarget

Spécifie la version du CLR qui peut exécuter l’assembly.

<PlatformTarget>anycpu</PlatformTarget>

• anycpu (valeur par défaut) compile votre assembly pour qu’il s’exécute sur n’importe quelle plateforme. Votre application s’exécute en tant que processus 64 bits dans la mesure du possible et repasse en 32 bits quand seul ce mode est disponible.
• anycpu32bitpreferred compile votre assembly pour qu’il s’exécute sur n’importe quelle plateforme. Votre application s’exécute en mode 32 bits sur les systèmes qui prennent en charge les applications 64 bits et 32 bits. Vous pouvez spécifier cette option uniquement pour les projets qui ciblent .NET Framework 4.5 ou version ultérieure.
• ARM compile votre assembly pour qu’il s’exécute sur un ordinateur doté d’un processeur ARM (Advanced RISC Machine).
• ARM64 compile votre assembly pour s’exécuter par le CLR 64 bits sur un ordinateur qui dispose d’un processeur Advanced RISC Machine (ARM) qui prend en charge le jeu d’instructions A64.
• x64 compile votre assembly pour qu’il soit exécuté par le CLR 64 bits sur un ordinateur qui prend en charge le jeu d’instructions AMD64 ou EM64T.
• x86 compile votre assembly pour qu’il soit exécuté par le CLR 32 bits x86.
• Itanium compile votre assembly pour qu’il soit exécuté par le CLR 64 bits sur un ordinateur doté d’un processeur Itanium.

Sur un système d'exploitation Windows 64 bits :

• Les assemblys compilés avec x86 s'exécutent sur le CLR 32 bits fonctionnant sous WOW64.
• Une DLL compilée avec anycpu s’exécute sur le même CLR que le processus dans lequel elle est chargée.
• Les fichiers exécutables compilés avec anycpu s’exécutent sur le CLR 64 bits.
• Les fichiers exécutables compilés avec anycpu32bitpreferred s’exécutent sur le CLR 32 bits.

Le paramètre anycpu32bitpreferred est valide uniquement pour les fichiers exécutables (.EXE) et nécessite .NET Framework 4.5 ou version ultérieure. Pour plus d’informations sur le développement d’une application s’exécutant sur un système d’exploitation Windows 64 bits, consultez Applications 64 bits.

Vous définissez l’option PlatformTarget à partir de la page de propriétés Build de votre projet dans Visual Studio.

Le comportement de anycpu présente des nuances supplémentaires sur .NET Core et .NET 5 et versions ultérieures. Lorsque vous définissez anycpu, publiez votre application et exécutez-la avec le x86 dotnet.exe ou le x64 dotnet.exe. Pour les applications autonomes, l’étape dotnet publish empaquète l’exécutable pour le RID de configuration.

ProduceReferenceAssembly

L’option ProduceReferenceAssembly spécifie si le compilateur produit des assemblys de référence.

<ProduceReferenceAssembly>true</ProduceReferenceAssembly>

Les assemblys de référence sont un type spécial d’assembly qui contiennent uniquement la quantité minimale de métadonnées requise pour représenter la surface d’API publique de la bibliothèque. Ils incluent des déclarations pour tous les membres qui sont significatifs lors du référencement d’un assembly dans les outils de génération. Les assemblys de référence excluent toutes les implémentations de membres et toutes les déclarations de membres privés. Ces membres n’ont aucun impact observable sur leur contrat d’API. Pour plus d’informations, consultez Assemblys de référence dans le Guide de .NET.

Les options ProduceReferenceAssembly et ProduceOnlyReferenceAssembly s’excluent mutuellement.

En règle générale, vous n’avez pas besoin d’utiliser directement les fichiers d’assembly de référence. Par défaut, les assemblys de référence sont générés dans un sous-dossier ref du chemin intermédiaire (c’est-à-dire obj/ref/). Pour les générer plutôt sous le répertoire de sortie (c’est-à-dire bin/ref/), définissez ProduceReferenceAssemblyInOutDir sur true dans votre projet.

Le kit SDK .NET 6.0.200 a apporté une modification en déplaçant les assemblys de référence du répertoire de sortie vers le répertoire intermédiaire par défaut.

TargetType

L’option du compilateur TargetType peut être spécifiée sous l’une des formes différentes :

• library : pour créer une bibliothèque de code. library est la valeur par défaut.
• exe : pour créer un fichier .exe.
• module : pour créer un module.
• winexe : pour créer un programme Windows.
• winmdobj : pour créer un fichier .winmdobj intermédiaire.
• appcontainerexe : pour créer un fichier .exe pour les applications du Windows 8.x Store.

<TargetType>library</TargetType>

Le compilateur crée un seul manifeste d’assembly par compilation. Les informations sur tous les fichiers d’une compilation sont placées dans le manifeste de l’assembly. Lorsque vous générez plusieurs fichiers de sortie sur la ligne de commande, un seul manifeste d’assembly peut être créé et il doit aller dans le premier fichier de sortie spécifié sur la ligne de commande.

Si vous créez un assembly, vous pouvez indiquer que tout ou partie de votre code est conforme CLS avec l’attribut CLSCompliantAttribute.

bibliothèque

L’option library indique au compilateur de créer une bibliothèque de liens dynamiques (DLL) à la place d’un fichier exécutable (EXE). La DLL est créée avec l’extension .dll. À moins que l’option OutputAssembly spécifie autre chose, le fichier de sortie prend le nom du premier fichier d’entrée. Lors de la création d’un fichier .dll, une méthode Main n’est pas obligatoire.

exe

L’option exe indique au compilateur de créer une application console exécutable (EXE). Le fichier exécutable est créé avec l’extension .exe. Utilisez winexe pour créer un exécutable de programme Windows. À moins que l’option OutputAssembly spécifie autre chose, le fichier de sortie prend le nom du fichier d’entrée qui contient le point d'entrée (méthode Main ou instructions de niveau supérieur). Un seul et unique point d'entrée est requis dans les fichiers de code source qui sont compilés dans un fichier .exe. L’option de compilateur StartupObject vous permet de spécifier la classe contenant la méthode Main, au cas où votre code possède plusieurs classes avec une méthode Main.

module

Cette option empêche le compilateur de générer un manifeste d’assembly. Par défaut, le fichier de sortie créé en effectuant une compilation avec cette option porte l’extension .netmodule. Un fichier qui n’a pas de manifeste d’assembly ne peut pas être chargé par le runtime .NET. Toutefois, un tel fichier peut être incorporé dans le manifeste d’un assembly avec AddModules. Si plusieurs modules sont créés dans une seule compilation, les types internal d’un module sont accessibles à d’autres modules dans la compilation. Quand le code d’un module référence des types internal dans un autre module, les deux modules doivent être incorporés dans un manifeste d’assembly, avec AddModules. La création d’un module n’est pas prise en charge dans l’environnement de développement Visual Studio.

winexe

L’option winexe indique au compilateur de créer un exécutable (EXE) de programme Windows. Le fichier exécutable est créé avec l’extension .exe. Un programme Windows est un programme qui fournit une interface utilisateur à partir de la bibliothèque .NET ou avec les API Windows. Utilisez exe pour créer une application console. À moins que l’option OutputAssembly spécifie autre chose, le fichier de sortie prend le nom du fichier d’entrée qui contient la méthode Main. Une seule et unique méthode Main est requise dans les fichiers de code source qui sont compilés dans un fichier .exe. L’option StartupObject vous permet de spécifier la classe contenant la méthode Main, au cas où votre code possède plusieurs classes avec une méthode Main.

winmdobj

Si vous utilisez l'option winmdobj, le compilateur crée un fichier .winmdobj intermédiaire que vous pouvez convertir en fichier binaire Windows Runtime (.winmd). Le fichier .winmd peut ensuite être consommé par des programmes JavaScript et C++, en plus des programmes en langage managé.

Le paramètre winmdobj signale au compilateur qu’un module intermédiaire est requis. Le fichier .winmdobj peut ensuite être acheminé via l'outil d'exportation WinMDExp pour produire un fichier de métadonnées Windows (.winmd). Le fichier .winmd contient à la fois le code de la bibliothèque d'origine et les métadonnées WinMD utilisées par JavaScript ou C++ et par le Windows Runtime. La sortie d'un fichier compilé à l'aide de l'option de compilateur winmdobj est utilisée uniquement comme entrée pour l'outil d'exportation WimMDExp. Le fichier .winmdobj lui-même n’est pas référencé directement. À moins que vous utilisiez l’option OutputAssembly, le fichier de sortie adopte le nom du premier fichier d’entrée. Une méthode Main n’est pas nécessaire.

appcontainerexe

Si vous utilisez l’option de compilateur appcontainerexe, le compilateur crée un fichier exécutable Windows (.exe) qui doit être exécuté dans un conteneur d’application. Cette option est équivalente à -target:winexe, mais elle est destinée aux applications du Windows 8.x Store.

Pour exiger que l’application s’exécute dans un conteneur d’application, cette option définit un bit dans le fichier Portable Executable (PE). Lorsque ce bit est défini, une erreur se produit si la méthode CreateProcess tente de lancer l'exécutable en dehors d'un conteneur d'application. À moins que vous utilisiez l’option OutputAssembly, le fichier de sortie prend le nom du fichier d’entrée qui contient la méthode Main.