dotnet run

Cet article s’applique à : ✔️ SDK .NET Core 6 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>] [-e|--environment <KEY=VALUE>]
  [--file <FILE_PATH>] [-f|--framework <FRAMEWORK>] [--force] [--interactive]
  [--launch-profile <NAME>] [--no-build] [--no-dependencies]
  [--no-launch-profile] [--no-restore] [--os <OS>] [--project <PATH>]
  [-r|--runtime <RUNTIME_IDENTIFIER>] [--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, consultez dotnet CLI .NET.

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, comme les 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.

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 -- .

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 Preview 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. Disponible depuis le Kit de développement logiciel (SDK) .NET 8.

• -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 le SDK .NET 7.

• -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 le Kit de développement logiciel (SDK) .NET 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, vous pouvez exécuter des applications basées sur des fichiers directement, à l’aide du nom de fichier source sur la ligne de commande au lieu de dotnet run. Tout d’abord, vérifiez que le fichier dispose d’autorisations d’exécution. Ensuite, ajoutez une ligne #! de shebang comme première ligne du fichier, par exemple :

  #!/usr/bin/env dotnet run
  

  Vous pouvez ensuite exécuter le fichier directement à partir de la ligne de commande :

  ./ConsoleApp.cs
  

  Introduit dans le Kit de développement logiciel (SDK) .NET 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. Option disponible à partir du kit SDK .NET Core 3.0.

• --launch-profile <NAME>

  Nom du profil de lancement éventuel à utiliser au lancement de l’application. Les profils de lancement sont définis dans le fichier launchSettings.json et s’appellent généralement Development, Staging et Production. Pour plus d’informations, consultez Utilisation de plusieurs environnements.

• --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 .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 de --project est déconseillée à partir du Kit de développement logiciel (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

  Publie le runtime .NET avec votre application afin que le runtime n’ait pas besoin d’être installé sur le système cible. La valeur par défaut est false. Toutefois, lors du ciblage de .NET 7 ou inférieur, la valeur par défaut est true si un identificateur d’exécution est spécifié.

• --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

Il existe quatre mécanismes par lesquels les variables d’environnement peuvent être appliquées à l’application lancée :

1. Variables d’environnement ambiantes du système d’exploitation lors de l’exécution de la commande.
2. 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.
3. environmentVariables à partir du profil de lancement choisi (-lp) dans le fichierlaunchSettings.json du projet, le cas échéant. Elles s’appliquent au projet exécuté par dotnet run.
4. -e|--environment Valeurs d’option CLI (ajoutées dans le KIT SDK .NET 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ée sur des fichiers a été ajoutée dans le Kit de développement logiciel (SDK) .NET 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