Variables d’environnement .NET

Cet article s’applique à : ✔️ SDK .NET Core 3.1 et versions ultérieures

Dans cet article, vous allez découvrir les variables d’environnement utilisées par .NET. Certaines variables d’environnement sont utilisées par le runtime .NET, tandis que d’autres sont utilisées uniquement par le Kit de développement logiciel (SDK) .NET et l’interface CLI .NET. Certaines variables d’environnement sont utilisées par ces trois composants.

Variables d’environnement du runtime .NET

DOTNET_SYSTEM_NET_HTTP_*

Il existe plusieurs paramètres de variable d’environnement HTTP globaux :

• DOTNET_SYSTEM_NET_HTTP_ENABLEACTIVITYPROPAGATION
  • Indique s’il faut activer ou non la propagation d’activité du gestionnaire de diagnostic pour les paramètres HTTP globaux.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2SUPPORT
  • Lorsque la valeur est définie sur false ou 0, désactive le support HTTP/2, qui est activé par défaut.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT
  • Lorsque la valeur est définie sur true ou 1, active le support HTTP/3, qui est désactivé par défaut.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2FLOWCONTROL_DISABLEDYNAMICWINDOWSIZING
  • Lorsque la valeur est définie sur false ou 0, remplace la valeur par défaut et désactive l’algorithme de mise à l’échelle de la fenêtre dynamique HTTP/2.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_FLOWCONTROL_MAXSTREAMWINDOWSIZE
  • La valeur par défaut est 16 Mo. Lorsqu’elle est remplacée, la taille maximale de la fenêtre de réception du flux HTTP/2 ne peut pas être inférieure à 65 535.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_FLOWCONTROL_STREAMWINDOWSCALETHRESHOLDMULTIPLIER
  • La valeur par défaut est 1.0. Lorsqu’elle est remplacée, l’utilisation de valeurs plus élevées entraîne une fenêtre plus courte, mais des téléchargements plus lents. Ne peut pas être inférieur à 0.

DOTNET_SYSTEM_GLOBALIZATION_*

• DOTNET_SYSTEM_GLOBALIZATION_INVARIANT : consultez Définir le mode invariant.
• DOTNET_SYSTEM_GLOBALIZATION_PREDEFINED_CULTURES_ONLY : spécifie s’il faut charger uniquement des cultures prédéfinies.
• DOTNET_SYSTEM_GLOBALIZATION_APPLOCALICU : indique s’il convient d’utiliser les composants internationaux de l’application locale (ICU). Pour plus d’informations, consultez ICU local de l’application.

Définir le mode invariant

Les applications peuvent activer le mode invariant de l’une des manières suivantes :

1. Dans le fichier projet :

   <PropertyGroup>
       <InvariantGlobalization>true</InvariantGlobalization>
   </PropertyGroup>
   

2. Dans le fichier runtimeconfig.json :

   {
       "runtimeOptions": {
           "configProperties": {
               "System.Globalization.Invariant": true
           }
       }
   }
   

3. En définissant la valeur de la variable d’environnement DOTNET_SYSTEM_GLOBALIZATION_INVARIANT sur true ou 1.

Pour plus d’informations, consultez Mode invariant de globalisation .NET.

DOTNET_SYSTEM_GLOBALIZATION_USENLS

Cela s’applique uniquement à Windows. Pour que la globalisation utilise le service NLS (National Language Support), affectez la valeur true ou 1 à DOTNET_SYSTEM_GLOBALIZATION_USENLS. Pour ne pas l’utiliser, affectez la valeur false ou 0 à DOTNET_SYSTEM_GLOBALIZATION_USENLS.

DOTNET_SYSTEM_NET_SOCKETS_*

Cette section se concentre sur deux variables d’environnement System.Net.Sockets :

• DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS
• DOTNET_SYSTEM_NET_SOCKETS_THREAD_COUNT

Les continuations de socket sont distribuées au System.Threading.ThreadPool à partir du thread d’événement. Cela évite que des continuations bloquent la gestion des événements. Pour permettre aux continuations de s’exécuter directement sur le thread d’événement, affectez 1 à la valeur DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS. Elle est désactivée par défaut.

À l’aide des tests d’évaluation de TechEmpower qui génèrent un grand nombre de lectures et d’écritures de sockets de petite taille dans une très grande charge, un moteur de socket unique est capable de conserver un temps d’activité jusqu’à trente cœurs de processeur x64 et de huit processeurs ARM64. La grande majorité des scénarios réels ne généreront jamais une charge aussi importante (des centaines de milliers de demandes par seconde), et le fait d’avoir un seul producteur est presque toujours suffisant. Toutefois, pour être sûr que les charges extrêmes peuvent être gérées, vous pouvez utiliser DOTNET_SYSTEM_NET_SOCKETS_THREAD_COUNT pour remplacer la valeur calculée. Lorsqu’elle n’est pas remplacée, la valeur suivante est utilisée :

• Lorsque DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS a la valeur 1, la valeur Environment.ProcessorCount est utilisée.
• Lorsque DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS n’a pas la valeur 1, RuntimeInformation.ProcessArchitecture est évalué :
  • Lorsque des cœurs ARM ou ARM64 sont utilisés, la valeur Cœurs par moteur est définie sur 8, sinon sur 30.
• En utilisant les cœurs déterminés par moteur, la valeur maximale est de 1 ou Environment.ProcessorCount sur le nombre de cœurs par moteur.

DOTNET_SYSTEM_NET_DISABLEIPV6

Permet de déterminer si la version 6 (IPv6) du protocole Internet est désactivée ou non. Lorsque la variable a la valeur true ou 1, IPv6 est désactivé, sauf indication contraire dans la classe System.AppContext.

DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER

Vous pouvez utiliser l’un des mécanismes suivants pour configurer un processus afin qu’il utilise l’ancien HttpClientHandler :

À partir du code, utilisez la classe AppContext :

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

Le commutateur AppContext peut également être défini par un fichier config. Pour plus d’informations sur la configuration des commutateurs, consultez AppContext pour les consommateurs de bibliothèque.

Le même résultat peut être obtenu via la variable d’environnement DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER. Pour annuler, définissez la valeur sur false ou 0.

DOTNET_Jit* et DOTNET_GC*

Il existe deux fonctionnalités liées à l’application de contraintes pour les informations JIT et les informations de GC générées par JIT : contrainte JIT et contrainte des trous GC. Ces fonctionnalités permettent au cours du développement de découvrir des cas de périphérie et des scénarios plus « réels » sans avoir à développer d’applications complexes. Les variables d’environnement suivantes sont disponibles :

• DOTNET_JitStress
• DOTNET_JitStressModeNamesOnly
• DOTNET_GCStress

Contrainte JIT

Il est possible d’activer la contrainte JIT de plusieurs façons. Définissez DOTNET_JitStress sur une valeur entière différente de zéro pour générer différents niveaux d’optimisations JIT en fonction d’un hachage du nom de la méthode. Pour appliquer toutes les optimisations, définissez DOTNET_JitStress=2, par exemple. Une autre façon d’activer la contrainte JIT consiste à définir DOTNET_JitStressModeNamesOnly=1 et à demander ensuite les modes de contrainte, délimités par des espaces, dans la variable DOTNET_JitStressModeNames.

Prenons l’exemple suivant :

DOTNET_JitStressModeNames=STRESS_USE_CMOV STRESS_64RSLT_MUL STRESS_LCL_FLDS

Contrainte des trous GC

L’activation de la contrainte des trous GC fait que les GC se produisent toujours dans des emplacements spécifiques, ce qui permet de localiser les trous GC. La contrainte des trous GC peut être activée à l’aide de la variable d’environnement DOTNET_GCStress.

Pour plus d’informations, consultez Effectuer des recherches sur les contraintes JIT et des trous GC.

Barrières de mémoire JIT

Le générateur de code pour Arm64 permet de supprimer toutes les instructions MemoryBarriers en définissant DOTNET_JitNoMemoryBarriers sur 1.

DOTNET_RUNNING_IN_CONTAINER et DOTNET_RUNNING_IN_CONTAINERS

Les images .NET officielles (Windows et Linux) définissent les variables d’environnement connues :

• DOTNET_RUNNING_IN_CONTAINER
• DOTNET_RUNNING_IN_CONTAINERS

Ces valeurs sont utilisées pour déterminer quand vos charges de travail ASP.NET Core sont exécutées dans le contexte d’un conteneur.

DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION

Lorsque Console.IsOutputRedirected a la valeur true, vous pouvez émettre un code couleur ANSI en affectant à DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION la valeur 1 ou true.

DOTNET_SYSTEM_DIAGNOSTICS et variables associées

• DOTNET_SYSTEM_DIAGNOSTICS_DEFAULTACTIVITYIDFORMATISHIERARCHIAL : lorsque la variable a la valeur 1 ou true, le format d’ID d’activité est hiérarchique.
• DOTNET_SYSTEM_RUNTIME_CACHING_TRACING : lors de l’exécution en mode Débogage, le suivi peut être activé lorsque la valeur est true.

DOTNET_DiagnosticPorts

Configure d’autres points de terminaison via lesquels les outils de diagnostic peuvent communiquer avec le runtime .NET. Pour plus d’informations, consultez la documentation sur le port de diagnostic.

DOTNET_DefaultDiagnosticPortSuspend

Configure le runtime de façon à ce qu’il s’interrompe au démarrage et attende la commande Diagnostics IPC ResumeStartup du port de diagnostic spécifié lorsqu’il est défini sur 1. La valeur par défaut est 0. Pour plus d’informations, consultez la documentation sur le port de diagnostic.

DOTNET_EnableDiagnostics

Une fois défini sur 0, désactive le débogage, le profilage et d’autres diagnostics via le Port de diagnostic et ne peut pas être remplacé par d’autres paramètres de diagnostic. La valeur par défaut est 1.

DOTNET_EnableDiagnostics_IPC

À compter de .NET 8, lorsqu’il est défini sur 0, désactive le Port de diagnostic et ne peut pas être remplacé par d’autres paramètres de diagnostic. La valeur par défaut est 1.

DOTNET_EnableDiagnostics_Debugger

À compter de .NET 8, lorsqu’il est défini sur 0, désactive le débogage et ne peut pas être remplacé par d’autres paramètres de diagnostic. La valeur par défaut est 1.

DOTNET_EnableDiagnostics_Profiler

À compter de .NET 8, lorsqu’il est défini sur 0, désactive le profilage et ne peut pas être remplacé par d’autres paramètres de diagnostic. La valeur par défaut est 1.

Variables EventPipe

Pour plus d’informations, consultez les variables d’environnement EventPipe.

• DOTNET_EnableEventPipe : quand la variable est définie sur 1, active le suivi via EventPipe.
• DOTNET_EventPipeOutputPath : chemin d’accès de sortie où la trace sera écrite.
• DOTNET_EventPipeOutputStreaming : lorsque la variable est définie sur 1, active la diffusion en continu vers le fichier de sortie pendant l’exécution de l’application. Par défaut, les informations de trace sont accumulées dans une mémoire tampon circulaire et le contenu est écrit à l’arrêt de l’application.

Variables d’environnement du Kit de développement logiciel (SDK) .NET et de l’interface CLI .NET

DOTNET_ROOT, , DOTNET_ROOT(x86)DOTNET_ROOT_X86, ,DOTNET_ROOT_X64

Spécifie l’emplacement des runtimes .NET, s’ils ne sont pas installés à l’emplacement par défaut. L’emplacement par défaut sur Windows est C:\Program Files\dotnet. L’emplacement par défaut sur macOS est /usr/local/share/dotnet. L’emplacement par défaut des runtimes x64 sur un système d’exploitation arm64 se trouve sous un sous-dossier x64 (ainsi C:\Program Files\dotnet\x64 sur windows et /usr/local/share/dotnet/x64 sur macOS. L’emplacement par défaut sur Linux varie en fonction de la distribution et de la méthode d’installation. L’emplacement par défaut sur Ubuntu 22.04 est /usr/share/dotnet (quand il est installé à partir de packages.microsoft.com) ou /usr/lib/dotnet (quand il est installé à partir du flux Jammy). Pour plus d’informations, consultez les ressources suivantes :

• Résoudre les échecs de lancement d’applications
• Problème GitHub dotnet/core#7699
• Problème GitHub dotnet/runtime#79237

Cette variable d’environnement est utilisée uniquement lors de l’exécution d’applications via des exécutables générés (apphosts). DOTNET_ROOT(x86) est utilisé à la place lors de l’exécution d’un fichier exécutable 32 bits sur un système d’exploitation 64 bits. DOTNET_ROOT_X64 est utilisé à la place lors de l’exécution d’un exécutable 64 bits sur un système d’exploitation ARM64.

DOTNET_HOST_PATH

Spécifie le chemin absolu d’un hôte dotnet (dotnet.exe sur Windows, dotnet sur Linux et macOS) utilisé pour lancer le processus de dotnet en cours d’exécution. Cette variable est utilisée par le kit de développement logiciel (SDK) .NET pour veiller à ce que les outils qui s’exécutent pendant les commandes du SDK .NET utilisent le même runtime dotnet pour tous les processus enfants dotnet qu’ils créent pendant la durée de la commande. Les outils et les tâches MSBuild dans le SDK qui appellent des fichiers binaires par le biais de l’hôte dotnet sont censés respecter cette variable d’environnement pour garantir une expérience cohérente.

Les outils qui appellent dotnet pendant une commande SDK doivent utiliser l’algorithme suivant pour le localiser :

• si DOTNET_HOST_PATH est défini, utiliser directement cette valeur
• sinon, utiliser dotnet via l’élément PATH du système

DOTNET_LAUNCH_PROFILE

La commande dotnet run définit cette variable sur le profil de lancement sélectionné.

Étant donné le fichier launchSettings.json suivant :

{
  "profiles": {
    "First": {
      "commandName": "Project",
    },
    "Second": {
      "commandName": "Project",
    }
  }
}

Et le fichier Program.cs suivant :

var value = Environment.GetEnvironmentVariable("DOTNET_LAUNCH_PROFILE");
Console.WriteLine($"DOTNET_LAUNCH_PROFILE={value}");

Les scénarios suivants produisent la sortie indiquée :

• Profil de lancement spécifié et existant

  $ dotnet run --launch-profile First
  DOTNET_LAUNCH_PROFILE=First
  

• Profil de lancement non spécifié, premier profil sélectionné

  $ dotnet run
  DOTNET_LAUNCH_PROFILE=First
  

• Profil de lancement spécifié mais inexistant

  $ dotnet run --launch-profile Third
  The launch profile "Third" could not be applied.
  A launch profile with the name 'Third' doesn't exist.
  DOTNET_LAUNCH_PROFILE=
  

• Lancement sans profil

  $ dotnet run --no-launch-profile
  DOTNET_LAUNCH_PROFILE=
  

NUGET_PACKAGES

Le dossier de packages global. S’il n’est pas défini, les valeurs par défaut sont ~/.nuget/packages sous Unix et %userprofile%\.nuget\packages sous Windows.

DOTNET_SERVICING

Spécifie l’emplacement de l’index de service que doit utiliser l’hôte partagé lors du chargement de l’exécution.

DOTNET_NOLOGO

Spécifie si les messages d’accueil et de télémétrie .NET sont affichés lors de la première exécution. Définissez la variable sur true pour désactiver ces messages (valeurs true, 1 ou yes acceptées) ou sur false pour les autoriser (valeurs false, 0 ou no acceptées). Si la variable n’est pas définie, la valeur par défaut est false et les messages s’affichent lors de la première exécution. Cet indicateur n’affecte pas la télémétrie (voir DOTNET_CLI_TELEMETRY_OPTOUT pour désactiver l’envoi de données de télémétrie).

DOTNET_CLI_PERF_LOG

Spécifie si les détails relatifs aux performances sur la session CLI actuelle sont enregistrés. Activé lorsque la variable est définie sur 1, true ou yes. Elle est désactivée par défaut.

DOTNET_GENERATE_ASPNET_CERTIFICATE

Spécifie s’il faut générer un certificat ASP.NET Core. La valeur par défaut est true, mais elle peut être substituée en affectant à cette variable d’environnement la valeur 0, false ou no.

DOTNET_ADD_GLOBAL_TOOLS_TO_PATH

Spécifie s’il faut ajouter des outils globaux à la variable d’environnement PATH. Par défaut, il s’agit de true. Pour ne pas ajouter d’outils globaux au chemin d’accès, définissez la variable sur 0, false ou no.

DOTNET_CLI_TELEMETRY_OPTOUT

Spécifie si les données relatives à l’utilisation des outils .NET sont collectées et envoyées à Microsoft. Définie sur true pour ne pas adhérer à la fonctionnalité de télémétrie (valeurs acceptées : true, 1 ou yes). Sinon, définissez pour false choisir les fonctionnalités de télémétrie (valeurs false, 0ou no acceptés). Si elle n’est pas définie, la valeur par défaut est false, et la fonctionnalité de télémétrie est active.

DOTNET_SKIP_FIRST_TIME_EXPERIENCE

Si DOTNET_SKIP_FIRST_TIME_EXPERIENCE a la valeur true, le dossier NuGetFallbackFolder n’est pas développé sur le disque et un message de bienvenue et un avis de télémétrie plus court s’affichent.

DOTNET_MULTILEVEL_LOOKUP

Spécifie si le runtime .NET, le framework partagé ou le SDK sont résolus à partir de l’emplacement global. Si la variable n’est pas définie, la valeur par défaut est 1 (true logique). Affectez la valeur 0 (false logique) pour ne pas résoudre à partir de l’emplacement global et avoir des installations .NET isolées. Pour plus d’informations sur la recherche multiniveau, consultez Recherche SharedFX multiniveau.

DOTNET_ROLL_FORWARD

Détermine le comportement de restauration par progression. Pour plus d’informations, consultez l’option --roll-forward de la commande dotnet.

DOTNET_ROLL_FORWARD_TO_PRERELEASE

Si la variable est définie sur 1 (activé), active la restauration par progression vers une préversion à partir d’une version commerciale. Par défaut (0 - désactivé), lorsqu’une version commerciale du runtime .NET est demandée, la restauration par progression prend uniquement en compte les versions commerciales installées.

Pour plus d’informations, consultez l’option --roll-forward de la commande dotnet

DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX

Désactive la restauration par progression d’une version mineure, si la valeur est 0. Ce paramètre est remplacé dans .NET Core 3.0 par DOTNET_ROLL_FORWARD. Les nouveaux paramètres doivent être utilisés à la place.

DOTNET_CLI_FORCE_UTF8_ENCODING

Force l’utilisation de l’encodage UTF-8 dans la console, même pour les versions antérieures de Windows 10 qui ne le prennent pas entièrement en charge. Pour plus d’informations, consultez Le kit SDK ne modifie plus l’encodage de la console à la fin de l’opération.

DOTNET_CLI_UI_LANGUAGE

Définit la langue de l’interface utilisateur CLI à l’aide d’une valeur de paramètres régionaux telle que en-us. Les valeurs prises en charge sont les mêmes que pour Visual Studio. Pour plus d’informations, consultez la section relative à la modification de la langue du programme d’installation dans la documentation d’installation de Visual Studio. Les règles du gestionnaire de ressources .NET s’appliquent. Vous n’avez donc pas besoin de choisir une correspondance exacte. Vous pouvez également choisir des descendants dans l’arborescence CultureInfo. Par exemple, si vous définissez la variable sur fr-CA, l’interface CLI trouve et utilise les traductions fr. Si vous définissez la variable sur une langue qui n’est pas prise en charge, l’interface CLI revient à l’anglais.

DOTNET_DISABLE_GUI_ERRORS

Pour les exécutables générés compatibles avec l’interface graphique utilisateur, désactive la boîte de dialogue qui s’affiche normalement pour certaines classes d’erreurs. Il écrit uniquement dans stderr et quitte dans ces cas.

DOTNET_ADDITIONAL_DEPS

Équivalent à l’option CLI --additional-deps.

DOTNET_RUNTIME_ID

Remplace le RID détecté.

DOTNET_SHARED_STORE

Emplacement du « magasin partagé » vers lequel la résolution d’assembly bascule dans certains cas.

DOTNET_STARTUP_HOOKS

Liste des assemblys à partir desquels charger et exécuter des hooks de démarrage.

DOTNET_BUNDLE_EXTRACT_BASE_DIR

Spécifie un répertoire dans lequel une application à fichier unique est extraite avant son exécution.

Pour plus d’informations, consultez Exécutables à fichier unique.

DOTNET_CLI_HOME

Spécifie l’emplacement dans lequel les fichiers de prise en charge des commandes CLI .NET doivent être écrits. Par exemple :

• Chemins accessibles en écriture par l’utilisateur pour les packs de charge de travail, les manifestes et d’autres données de prise en charge.
• Fichiers sentinel/verrou de première exécution pour les aspects des migrations et des notifications de première exécution de l’interface CLI .NET.
• Emplacement d’installation de l’outil local .NET par défaut.

DOTNET_CLI_CONTEXT_*

• DOTNET_CLI_CONTEXT_VERBOSE : pour activer un contexte détaillé, affectez la valeur true.
• DOTNET_CLI_CONTEXT_ANSI_PASS_THRU : pour activer un transfert ANSI, affectez la valeur true.

DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE

Désactive le téléchargement en arrière-plan des manifestes publicitaires pour les charges de travail. La valeur par défaut est false - non désactivé. Si la valeur true est définie, le téléchargement est désactivé. Pour plus d’informations, consultez Manifestes publicitaires.

DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_INTERVAL_HOURS

Spécifie le nombre minimal d’heures entre les téléchargements en arrière-plan des manifestes publicitaires pour les charges de travail. La valeur par défaut est 24, à savoir pas plus fréquemment qu’une fois par jour. Pour plus d’informations, consultez Manifestes publicitaires.

DOTNET_TOOLS_ALLOW_MANIFEST_IN_ROOT

Spécifie si les outils locaux du SDK .NET recherchent des fichiers manifestes d’outils dans le dossier racine sur Windows. La valeur par défaut est false.

COREHOST_TRACE

Contrôle le suivi des diagnostics à partir des composants d’hébergement, tels que dotnet.exe, hostfxr et hostpolicy.

• COREHOST_TRACE=[0/1] - La valeur par défaut est 0 - Le suivi est désactivé. Si la valeur 1 est définie, le suivi des diagnostics est activé.

• COREHOST_TRACEFILE=<file path> - A un effet uniquement si le suivi est activé via la définition de COREHOST_TRACE=1. Quand la variable est définie, les informations de suivi sont écrites dans le fichier spécifié ; sinon, les informations de suivi sont écrites dans stderr.

• COREHOST_TRACE_VERBOSITY=[1/2/3/4] - La valeur par défaut est 4. Le paramètre est utilisé uniquement lorsque le suivi est activé via COREHOST_TRACE=1.

  • 4 - Toutes les informations de suivi sont écrites
  • 3 - Seuls les messages d’information, d’avertissement et d’erreur sont écrits
  • 2 - Seuls les messages d’avertissement et d’erreur sont écrits
  • 1 - Seuls les messages d’erreur sont écrits

La méthode classique utilisée pour obtenir des informations de suivi détaillées sur le démarrage de l’application consiste à définir COREHOST_TRACE=1 et COREHOST_TRACEFILE=host_trace.txt, puis à exécuter l’application. Un nouveau fichier host_trace.txt sera créé dans le répertoire actif avec les informations détaillées.

SuppressNETCoreSdkPreviewMessage

Si la valeur true est définie, l’appel de dotnet ne génère pas d’avertissement lorsqu’un Kit de développement logiciel (SDK) en préversion est utilisé.

Configurer MSBuild dans l’interface CLI .NET

Pour exécuter MSBuild hors processus, définissez la variable d’environnement DOTNET_CLI_RUN_MSBUILD_OUTOFPROC sur 1, true ou yes. Par défaut, MSBuild s’exécute dans le processus. Pour forcer MSBuild à utiliser le processus de longue durée d’un nœud de travail externe pour la création de projets, définissez DOTNET_CLI_USE_MSBUILDNOINPROCNODE sur 1, true ou yes. Cela définit la variable d’environnement MSBUILDNOINPROCNODE sur 1 (appelée MSBuild Server V1), car le processus d’entrée transfère la plupart du travail à celui-ci.

DOTNET_MSBUILD_SDK_RESOLVER_*

Il s’agit de remplacements utilisés pour forcer les tâches et cibles résolues du SDK à provenir d’un répertoire de base donné et de signaler une version donnée à MSBuild, qui peut être null si inconnu. L’un des principaux cas d’usage est de tester les tâches et cibles du SDK sans les déployer à l’aide du SDK .NET Core.

• DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR : remplace le répertoire du Kit de développement logiciel (SDK) .NET.
• DOTNET_MSBUILD_SDK_RESOLVER_SDKS_VER : remplace la version du Kit de développement logiciel (SDK) .NET.
• DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR : remplace le chemin d’accès du répertoire dotnet.exe.

DOTNET_NEW_PREFERRED_LANG

Configure le langage de programmation par défaut pour la commande dotnet new lorsque le commutateur -lang|--language est omis. La valeur par défaut est C#. Les valeurs valides sont C#, F# ou VB. Pour plus d’informations, consultez dotnet new.

Variables d’environnement dotnet watch

Pour plus d’informations sur les paramètres dotnet watch disponibles en tant que variables d’environnement, consultez Variables d’environnement dotnet watch.

Voir aussi

• Commande dotnet
• Runtime Configuration Files
• Paramètres de configuration du runtime .NET