dotnet run

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

Nom

dotnet run - Exécute le code source sans commandes explicites de compilation ou de démarrage.

Synopsis

dotnet run [<applicationArguments>]
  [-a|--arch <ARCHITECTURE>] [--artifacts-path <ARTIFACTS_DIR>]
  [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
  [-e|--environment <KEY=VALUE>] [--file <FILE_PATH>]
  [-f|--framework <FRAMEWORK>] [--force] [--interactive]
  [-lp|--launch-profile <NAME>] [--no-build] [--no-cache]
  [--no-dependencies] [--no-launch-profile] [--no-restore] [--os <OS>]
  [-p|--property:<PROPERTYNAME>=<VALUE>]
  [--project <PATH>] [-r|--runtime <RUNTIME_IDENTIFIER>]
  [--sc|--self-contained] [--tl:[auto|on|off]] [-v|--verbosity <LEVEL>]
  [[--] [application arguments]]

dotnet run -h|--help

Description

La commande dotnet run fournit une option pratique pour exécuter votre application à partir du code source à l’aide d’une seule commande. Elle est utile pour le développement itératif rapide en ligne de commande. Elle dépend de la commande dotnet build pour générer le code. Toutes les exigences de la build s’appliquent dotnet run également.

Les fichiers de sortie sont écrits dans l’emplacement par défaut, à savoir bin/<configuration>/<target>. Par exemple, si vous avez une application netcoreapp2.1 et que vous exécutez dotnet run, la sortie est placée dans bin/Debug/netcoreapp2.1. Les fichiers sont remplacés, si nécessaire. Les fichiers temporaires sont placés dans le répertoire obj.

Si le projet spécifie plusieurs frameworks, l’exécution de dotnet run entraîne une erreur, sauf si l’option -f|--framework <FRAMEWORK> est utilisée pour spécifier le framework.

La commande dotnet run est utilisée pour des projets, et pas pour des assemblys générés. Si vous tentez d’exécuter plutôt une DLL d’applications dépendantes du framework, vous devez utiliser dotnet sans commande. Par exemple, pour exécuter myapp.dll, utilisez :

dotnet myapp.dll

Pour plus d’informations sur le pilote dotnet, consultez .NET vue d’ensemble de l’interface CLI.

Pour exécuter l’application, la commande dotnet run résout les dépendances de l’application externes au runtime partagé à partir du cache NuGet. Dans la mesure où elle utilise la mise en cache des dépendances, il n’est pas recommandé d’utiliser dotnet run pour exécuter des applications en production. Créez plutôt un déploiement à l’aide de la commande dotnet publish et déployez le résultat publié.

Restauration implicite

Vous n’avez pas besoin d’exécuter dotnet restore, car il est exécuté implicitement par toutes les commandes qui nécessitent une restauration pour se produire, comme dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish et dotnet pack. Pour désactiver la restauration implicite, utilisez l’option --no-restore .

La commande dotnet restore est toujours utile dans certains scénarios où la restauration explicite est logique, par exemple builds d’intégration continue dans Azure DevOps Services ou dans les systèmes de génération qui doivent contrôler explicitement le moment où la restauration se produit.

Pour plus d’informations sur la gestion des flux NuGet, consultez la documentation dotnet restore.

Cette commande prend en charge les options de dotnet restore quand elles sont transférées sous leur forme longue (par exemple --source). Les options sous forme abrégée, comme -s, ne sont pas prises en charge.

Téléchargement de manifestes de charge de travail

Lorsque vous exécutez cette commande, elle lance en arrière-plan un téléchargement asynchrone des manifestes publicitaires des charges de travail. Si le téléchargement est toujours en cours lorsque cette commande se termine, celui-ci est arrêté. Pour plus d’informations, consultez Manifestes publicitaires.

Profils de lancement

Les profils de lancement configurent le démarrage dotnet run d’une application pendant le développement. Pour un projet de style SDK, placez les paramètres dans Properties/launchSettings.json. Visual Basic projets utilisent My Project/launchSettings.json à la place.

Les applications basées sur des fichiers peuvent utiliser un [ApplicationName].run.json fichier en regard du fichier source. Pour obtenir l’ordre et les exemples de recherche de fichiers, consultez Les profils de lancement pour les applications basées sur des fichiers.

Le fichier de paramètres de lancement contient un objet de niveau profiles supérieur. Chaque propriété dans profiles définit un profil nommé :

{
  "profiles": {
    "Local": {
      "commandName": "Project",
      "commandLineArgs": "--input sample.txt",
      "dotnetRunMessages": true,
      "environmentVariables": {
        "APP_MODE": "local"
      }
    }
  }
}

L’analyseur de paramètres de lancement du KIT de développement logiciel (SDK) .NET accepte les commentaires JSON et les virgules de fin.

Sélectionner un profil

Permet --launch-profile <NAME> de sélectionner un profil nommé. La correspondance de nom ne respecte pas la casse. Les noms de profil qui diffèrent uniquement par cas sont ambigus et produisent une erreur.

Si vous ne spécifiez pas de nom, dotnet run sélectionne le premier profil dans l’ordre de fichier dont commandName il prend en charge. Permet --no-launch-profile d’ignorer le fichier de paramètres de lancement.

En dotnet run cas d’application d’un profil, il définit DOTNET_LAUNCH_PROFILE le nom du profil sélectionné dans le processus lancé. Une source de variable d’environnement ultérieure peut remplacer la valeur.

Types de profils pris en charge

Le SDK .NET prend en charge ces commandName valeurs pour dotnet run. Les valeurs respectent la casse.

`commandName`	Behavior
`Project`	Génère le projet et démarre la commande produite par le projet.
`Executable`	Démarre la commande spécifiée par `executablePath`. Sauf si vous spécifiez `--no-build`, `dotnet run` génère toujours le projet en premier.

Propriétés communes

dotnet run reconnaît ces propriétés pour les deux types de profil pris en charge :

dotnet run développe les références de variable d’environnement dans les %NAME% valeurs de chaîne prises en charge. Dans .NET 11 et versions ultérieures, il développe également les références de propriétés MSBuild dans les valeurs qu’elle utilise pour lancer le processus, en utilisant le même remplacement de jeton que Visual Studio. Il ne développe pas les références de style $NAME shell.

Property	Behavior
`commandLineArgs`	Spécifie les arguments du processus lancé. Les arguments d’application explicites sur la ligne de commande sont prioritaires. Pour un `Project` profil, les arguments fournis par le project sont également prioritaires.
`environmentVariables`	Spécifie des variables d’environnement pour le processus lancé. Les valeurs de profil remplacent les variables d’environnement héritées et générées par le SDK et `-e\\|--environment` les valeurs remplacent les valeurs de profil.
`dotnetRunMessages`	Lorsque `true`, imprime `Building...` avant `dotnet run` de générer le projet. La valeur par défaut est `false`. Cette propriété ne contrôle pas le message qui identifie le fichier de paramètres de lancement.

Permet environmentVariables d’appliquer les paramètres de configuration du runtime au moment du développement qui ont un formulaire de variable d’environnement. Par exemple, un profil peut définir des paramètres GC tels que DOTNET_gcServer. Pour connaître les paramètres disponibles, les noms de variables d’environnement et les règles de précédence, consultez .NET paramètres de configuration du runtime et options de configuration runtime pour le garbage collection.

Tous les paramètres d’exécution ne possèdent pas de formulaire de variable d’environnement. Pour configurer une application indépendamment de son profil de lancement, utilisez une propriété ou RuntimeHostConfigurationOption un élément MSBuild dans le projet, ou utilisez un runtimeconfig.template.json fichier. Certains paramètres peuvent également être modifiés dans le code avec AppContext.SetSwitch. Ces mécanismes produisent ou modifient la configuration du runtime de l’application ; ils ne sont pas des propriétés supplémentaires launchSettings.json .

`Project` Propriétés

dotnet run reconnaît ces propriétés supplémentaires lorsqu’il commandName s’agit Projectde :

Property	Behavior
`applicationUrl`	Définit `ASPNETCORE_URLS` dans le processus lancé. Une `ASPNETCORE_URLS` valeur dans `environmentVariables` ou à partir est `-e\\|--environment` prioritaire.
`launchBrowser`	Indique à l’outil de lancement s’il faut ouvrir un navigateur. `dotnet run` conserve cette propriété dans le profil analysé, mais n’ouvre pas de navigateur.
`launchUrl`	Indique à l’outil de lancement l’URL à ouvrir. `dotnet run` conserve cette propriété dans le profil analysé, mais n’ouvre pas de navigateur ni n’utilise l’URL.

Le applicationUrl comportement prend en charge ASP.NET Core, mais les profils de lancement et les autres propriétés courantes s’appliquent à tout projet de .NET de style SDK exécutable.

`Executable` Propriétés

dotnet run reconnaît ces propriétés supplémentaires lorsqu’il commandName s’agit Executablede :

Property Behavior

executablePath Obligatoire. Spécifie le processus à démarrer. Le Kit de développement logiciel (SDK) développe les références de variables prises en charge, mais ne résout pas une valeur relative par rapport au fichier de paramètres de lancement. Utilisez un chemin d’accès absolu ou une commande que le système d’exploitation peut localiser.

workingDirectory Optional. Spécifie le répertoire de travail du processus lancé. Le Kit de développement logiciel (SDK) développe les références de variables prises en charge et résout un chemin relatif par rapport au répertoire qui contient le fichier de paramètres de lancement. Si vous omettez la propriété, le répertoire de travail est défini par défaut sur le répertoire qui contient l’application basée sur le projet ou le fichier.

Property	Behavior
`executablePath`	Obligatoire. Spécifie le processus à démarrer. Le Kit de développement logiciel (SDK) développe les références de variables prises en charge, mais ne résout pas une valeur relative par rapport au fichier de paramètres de lancement. Utilisez un chemin d’accès absolu ou une commande que le système d’exploitation peut localiser.
`workingDirectory`	Optional. Spécifie le répertoire de travail du processus lancé. Le Kit de développement logiciel (SDK) développe les références de variables prises en charge et résout un chemin relatif par rapport au répertoire qui contient le fichier de paramètres de lancement. Si vous omettez la propriété, le répertoire de travail est défini par défaut sur le répertoire qui contient l’application basée sur le projet ou le fichier.

extensions Visual Studio et débogueur

launchSettings.json est un format d’entrée partagé, mais chaque consommateur décide des valeurs à prendre en charge et comment les interpréter. Visual Studio, les débogueurs et d’autres outils peuvent reconnaître plus commandName de valeurs et de propriétés que dotnet run.

Le tableau suivant compare le dotnet run contrat avec le comportement commun .NET du système de projet dans Visual Studio :

Contexte ou comportement	`dotnet run`	Visual Studio
Types de profils pris en charge	Prend en charge `Project` et `Executable`.	Prend en charge `Project`, `Executable`et un objet vide `commandName`. Les extensions de système de projet installées peuvent ajouter d’autres types de profils.
Extension des variables	Développe les références `%NAME%` de variables d’environnement. Dans .NET versions 11 et ultérieures, développe également les références de propriétés MSBuild dans les valeurs qu’elle utilise pour lancer le processus.	Développe les variables d’environnement et les propriétés MSBuild dans `executablePath`, `commandLineArgsworkingDirectory`, `launchUrl`, valeurs de variable d’environnement et paramètres d’extension à valeur chaîne.
`commandLineArgs` pour `Project`	Utilise la valeur de profil uniquement lorsque le projet ne fournit pas d’arguments d’exécution et que vous ne transmettez pas d’arguments d’application sur la ligne de commande.	Ajoute la valeur de profil aux arguments d’exécution du projet.
`workingDirectory` pour `Project`	Ignore la propriété.	Prend en charge la propriété. Un chemin relatif est relatif au répertoire du projet.
`workingDirectory` pour `Executable`	Un chemin relatif est relatif au répertoire qui contient le fichier de paramètres de lancement. S’il est omis, le chemin d’accès est défini par défaut dans le répertoire d’application basé sur le projet ou le fichier.	Un chemin relatif est relatif au répertoire du projet. S’il est omis, le chemin d’accès correspond par défaut au répertoire de sortie lorsque ce répertoire existe ou au répertoire du projet dans le cas contraire.
Relative `executablePath`	Transmet la valeur au système d’exploitation sans la rebaser.	Résout une valeur avec des composants de chemin d’accès à partir du répertoire de travail du profil. Pour un nom exécutable nu, Visual Studio vérifie son propre répertoire actif, puis `PATH`.
`launchBrowser` et `launchUrl`	Conserve les valeurs dans le profil analysé, mais n’ouvre pas de navigateur.	Met les valeurs à la disposition d’un fournisseur de lancement. Par exemple, ASP.NET Core outils peuvent ouvrir un navigateur.
`applicationUrl`	Définit `ASPNETCORE_URLS`.	Rend la valeur disponible pour les fournisseurs de lancement installés, tels que ASP.NET Core outils.
`dotnetRunMessages`	Contrôle le `Building...` message.	N'utilise pas la propriété pour contrôler Visual Studio sortie.
Propriétés du débogueur	Ignore les propriétés spécifiques au débogueur.	Utilise des propriétés telles que `nativeDebugging`, , `sqlDebuggingjsWebView2Debugging`, `remoteDebugEnabled`, et `hotReloadEnabled` lorsque le projet et le débogueur prennent en charge la fonctionnalité.

Dans .NET 11 et versions ultérieures, les deux consommateurs s’étendent"$(ProjectDir)". Dans les versions antérieures, aucune valeur unique workingDirectory n’identifie le répertoire du projet pour les deux consommateurs. Visual Studio s’étend"$(ProjectDir)", tandis qu’elle dotnet run le traite comme du texte littéral et résout les chemins relatifs du répertoire qui contient le fichier de paramètres de lancement. Par conséquent, utilisez-le ".." avec dotnet run un fichier ou My Project/launchSettings.json un fichier conventionnelProperties/launchSettings.json. Visual Studio résout la même valeur en parent du répertoire du projet.

Windows Forms et les applications WPF n'ajoutent pas un autre dotnet run type de profil. Utilisez un Project profil avec des paramètres courants tels que commandLineArgs et environmentVariables. Dans Visual Studio, ces types de projets de bureau peuvent également utiliser des propriétés de débogueur applicables, telles que nativeDebugging pour le débogage managé et natif mixte ou jsWebView2Debugging pour WebView2. Les propriétés du navigateur et de l’URL n’ont qu’un effet lorsqu’un fournisseur de lancement ou l’application les consomme.

D’autres types de projets et charges de travail Visual Studio peuvent installer des fournisseurs de lancement qui ajoutent des types de profil ou interprètent des propriétés supplémentaires. Ces extensions n’ajoutent pas de prise en charge à dotnet run: l’interface CLI ignore les types de profils non pris en charge pendant la sélection par défaut et signale une erreur lorsque vous en sélectionnez un explicitement.

Pour connaître les paramètres de débogueur pris en charge par Visual Studio et l'interface utilisateur project, consultez Project paramètres d'une configuration de débogage C# .NET.

Arguments

<applicationArguments>

Arguments passés à l’application en cours d’exécution.

Tous les arguments qui ne sont pas reconnus par dotnet run sont passés à l’application. Pour séparer les arguments des dotnet run arguments de l’application, utilisez l’option -- .

Transférer des arguments à l’application

dotnet run transfère tout jeton qu’il ne reconnaît pas à l’application. Les jetons transférés conservent leur ordre d’origine, mais dotnet run suppriment d’abord les options qu’il comprend. Lorsqu’une option reconnue apparaît entre un nom d’option non reconnu et sa valeur, la suppression de l’option reconnue peut modifier la signification des jetons de gauche.

Par exemple, la commande suivante entrelace l’option --project reconnue entre les jetons que l’application est destinée à recevoir :

dotnet run --app-flag --app-name --project ConsoleApp.csproj A.txt

Une fois dotnet run consommée --project ConsoleApp.csproj, l’application reçoit --app-flag --app-name A.txt. L’application traite A.txt ensuite comme la valeur de , qui ne correspond pas à la ligne de --app-namecommande d’origine.

Pour éviter cette ambiguïté, placez les arguments d’application après un littéral --:

dotnet run --project ConsoleApp.csproj -- --app-flag --app-name A.txt

Le -- séparateur marque chaque jeton suivant en tant qu’argument d’application. dotnet run Il ne les réorganise ni ne les réinterpret. Le séparateur vérifie également les scripts à venir par rapport aux nouvelles dotnet run options susceptibles de correspondre ultérieurement à un jeton précédemment transféré à l’application.

Note

Le même comportement s’applique à dotnet build et à dotnet test dans Microsoft. Mode Test.Platform (MTP), qui transfèrent respectivement des jetons non reconnus à MSBuild ou à l’application de test. Pour plus d’informations sur dotnet test, consultez Transférer des arguments à l’application de test.

Options

--

Délimite les arguments à dotnet run parmi les arguments de l’application en cours d’exécution. Tous les arguments après ce délimiteur sont passés à l’application exécutée.
-a|--arch <ARCHITECTURE>

Spécifie l’architecture cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --arch x86 définit le RID sur win-x86. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6 préversion 7.
--artifacts-path <ARTIFACTS_DIR>

Tous les fichiers de sortie de build de la commande exécutée vont dans les sous-dossiers sous le chemin spécifié, séparés par projet. Pour plus d’informations, consultez disposition de sortie d’artefacts. Cette option et la valeur fournie doivent être explicitement en cascade dans n’importe quelle dotnet commande qui dépend de la sortie d’une autre dotnet commande, par exemple, lors de l’utilisation dotnet build --no-restore et dotnet publish --no-build. Disponible depuis .NET 8 SDK.
-c|--configuration <CONFIGURATION>

Définit la configuration de build. La valeur par défaut pour la plupart des projets est Debug, mais vous pouvez remplacer les paramètres de configuration de build dans votre projet.
--disable-build-servers

Force la commande à ignorer tous les serveurs de build persistants. Cette option offre un moyen cohérent de désactiver toute utilisation de la mise en cache de build, ce qui force une build à partir de zéro. Une build qui ne repose pas sur des caches est utile quand les caches peuvent être endommagés ou incorrects pour une raison quelconque. Disponible depuis .NET 7 SDK.
-e|--environment <KEY=VALUE>

Définit la variable d’environnement spécifiée dans le processus qui sera exécutée par la commande. La variable d’environnement spécifiée n’est pas appliquée au dotnet run processus.

Les variables d’environnement transmises par cette option sont prioritaires sur les variables d’environnement ambiantes, les directives System.CommandLine env et environmentVariables à partir du profil de lancement choisi. Pour en savoir plus, voir Variables d’environnement.

(Cette option a été ajoutée dans .NET SDK 9.0.200.)
-f|--framework <FRAMEWORK>

Crée et exécute l’application à l’aide du framework spécifié. Le framework doit être spécifié dans le fichier projet.
--file <FILE_PATH>

Chemin d’accès à l’application basée sur des fichiers à exécuter. Si aucun chemin d’accès n’est spécifié, le répertoire actif est utilisé pour rechercher et exécuter le fichier. Pour plus d’informations sur les applications basées sur des fichiers, consultez Créer des applications C# basées sur des fichiers.

Sur Unix, exécutez des applications basées sur des fichiers directement à l’aide du nom de fichier en ajoutant une directive shebang (#!) et en définissant l’autorisation d’exécution. Pour plus d’informations, consultez la prise en charge du shebang Unix (#!).

Introduit dans .NET SDK 10.0.100.
--force

Force la résolution de toutes les dépendances même si la dernière restauration a réussi. Définir cet indicateur revient à supprimer le fichier project.assets.json.
--interactive

Permet à la commande de s’arrêter et d’attendre une action ou une entrée utilisateur. Par exemple, pour effectuer une authentification.
-lp|--launch-profile <NAME>

Nom du profil de lancement à utiliser lors du lancement de l’application. Pour plus d’informations, consultez Profils de lancement.
--no-build

Ne génère pas le projet avant l’exécution. L’indicateur --no-restore est également défini implicitement.
--no-cache

Ignorez les vérifications à jour et générez toujours le programme avant l’exécution.
--no-dependencies

En cas de restauration d’un projet avec des références entre projets (P2P), restaure le projet racine et non les références.
--no-launch-profile

N’essaie pas d’utiliser launchSettings.json pour configurer l’application.
--no-restore

N’effectue pas de restauration implicite à l’exécution de la commande.
--no-self-contained

Publiez votre application en tant qu’application dépendante de l’infrastructure. Un runtime de .NET compatible doit être installé sur l’ordinateur cible pour exécuter votre application.
--os <OS>

Spécifie le système d’exploitation cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --os linux définit le RID sur linux-x64. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6.
--project <PATH>

Spécifie le chemin du fichier projet à exécuter (nom de dossier ou chemin complet). Si aucune valeur n’est spécifiée, le répertoire actif est utilisé par défaut.

L’abréviation -p pour --project est déconseillée à partir du KIT SDK .NET 6. Pendant une durée limitée, -p il est toujours possible d’utiliser cette --project option malgré l’avertissement de dépréciation. Si l’argument fourni pour l’option ne contient pas =, la commande accepte -p comme abréviation de --project. Sinon, la commande suppose que -p est l’abréviation de --property. Cette utilisation flexible de -p pour --project sera progressivement supprimée dans .NET 7.
--property:<NAME>=<VALUE>

Définit une ou plusieurs propriétés de MSBuild. Spécifiez plusieurs propriétés délimitées par des points-virgules ou en répétant l’option :
```
--property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
```
La forme abrégée -p peut être utilisée pour --property. Si l’argument fourni pour l’option contient =, -p est accepté comme abréviation de --property. Sinon, la commande suppose que -p est l’abréviation de --project.

Pour transférer --property vers l’application plutôt que de définir une propriété MSBuild, fournissez l’option après le séparateur de syntaxe --, par exemple :
```
dotnet run -- --property name=value
```
-r|--runtime <RUNTIME_IDENTIFIER>

Spécifie le runtime cible pour lequel restaurer les packages. Pour connaître les identificateurs de runtime, consultez le catalogue des identificateurs de runtime.
--sc|--self-contained

Publiez le runtime .NET avec votre application afin que le runtime n'ait pas besoin d'être installé sur l'ordinateur cible.
--tl:[auto|on|off]

Spécifie si Terminal Logger doit être utilisé pour la sortie de build. La valeur par défaut est auto, qui vérifie d’abord l’environnement avant d’activer la journalisation du terminal. La vérification de l’environnement vérifie que le terminal est capable d’utiliser des fonctionnalités de sortie modernes et n’utilise pas une sortie standard redirigée avant d’activer le nouvel enregistreur d’événements. on ignore la vérification de l’environnement et active la journalisation du terminal. off ignore la vérification de l’environnement et utilise l’enregistreur d’événements de console par défaut.

Terminal Logger vous montre la phase de restauration suivie de la phase de génération. Au cours de chaque phase, les projets en cours de génération apparaissent en bas du terminal. Chaque projet en cours de génération génère à la fois la cible MSBuild en cours de génération et le temps consacré à cette cible. Vous pouvez rechercher ces informations pour en savoir plus sur la génération. Lorsque la génération d’un projet est terminée, une unique section « build terminée » est écrite et capture :
- Le nom du projet généré.
- Le framework cible (si plusieurs cibles).
- L’état de cette build.
- La sortie principale de cette génération (qui est un lien hypertexte).
- Les diagnostics générés pour ce projet.
Cette option est disponible à partir de .NET 8.
-v|--verbosity <LEVEL>

Définit le niveau de détail de la commande. Les valeurs autorisées sont q[uiet], m[inimal], n[ormal], d[etailed] et diag[nostic]. La valeur par défaut est minimal. Pour plus d'informations, consultez LoggerVerbosity.
-?|-h|--help

Imprime une description de l’utilisation de la commande.

Variables d'environnement

Les sources suivantes appliquent des variables d’environnement à l’application lancée :

Variables d’environnement ambiantes du système d’exploitation lors de l’exécution de la commande.
Directives System.CommandLine env , comme [env:key=value]. Elles s’appliquent à l’ensemble dotnet run du processus, pas seulement au projet exécuté par dotnet run.
Valeurs générées à partir du profil de lancement choisi. dotnet run définit DOTNET_LAUNCH_PROFILEet applicationUrl dans un Project jeu de ASPNETCORE_URLSprofils .
environmentVariables à partir du profil de lancement choisi, le cas échéant. Elles s’appliquent au projet exécuté par dotnet run.
-e|--environment valeurs d’option CLI (ajoutées dans .NET SDK version 9.0.200). Elles s’appliquent au projet exécuté par dotnet run.

L’environnement est construit dans le même ordre que cette liste, de sorte que l’option -e|--environment a la priorité la plus élevée.

Exemples

Exécutez le projet dans le répertoire actif :
```
dotnet run
```
Exécutez l’application basée sur des fichiers spécifiée dans le répertoire actif :
```
dotnet run --file ConsoleApp.cs
```
La prise en charge des applications basées sur des fichiers a été ajoutée dans .NET SDK 10.0.100.

Exécutez le projet spécifié :

dotnet run --project ./projects/proj1/proj1.csproj

Exécutez le projet dans le répertoire actif, en spécifiant la configuration Release :
```
dotnet run --property:Configuration=Release
```
Exécutez le projet dans le répertoire actuel (l’argument --help de cet exemple est passé à l’application, puisque l’option -- vide est utilisée) :
```
dotnet run --configuration Release -- --help
```
Restaurez les dépendances et les outils pour le projet dans le répertoire actif en affichant uniquement une sortie minimale, puis exécutez le projet :
```
dotnet run --verbosity m
```
Exécutez le projet dans le répertoire actif à l’aide de l’infrastructure spécifiée et passez des arguments à l’application :
```
dotnet run -f net6.0 -- arg1 arg2
```
Dans l’exemple suivant, trois arguments sont passés à l’application. Un argument est passé à l’aide -, et deux arguments sont passés après --:
```
dotnet run -f net6.0 -arg1 -- arg2 arg3
```

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-09-08