dotnet run

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

Nom

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

Synopsis

dotnet run [-a|--arch <ARCHITECTURE>] [-c|--configuration <CONFIGURATION>]
    [-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 dotnet, consultez la rubrique Outils en ligne de commande (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.

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.

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

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

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

• -?|-h|--help

  Imprime une description de l’utilisation de la commande.

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

• --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. Pour une durée limitée à partir du Kit de développement logiciel (SDK) .NET 6 RC1, -p peut toujours être utilisé pour --project en dépit de 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.

• --tl:[auto|on|off]

  Spécifie si l’enregistreur d’événements de terminal 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.

  L’enregistreur d’événements de terminal affiche la phase de restauration suivie par 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.

Exemples

• Exécutez le projet dans le répertoire actif :

  dotnet run
  

• 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