dotnet run
Cet article s’applique à : ✔️ SDK .NET Core 3.1 et versions ultérieures
dotnet run
- Exécute le code source sans commandes explicites de compilation ou de démarrage.
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
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.
Notes
dotnet run
ne respecte pas les arguments comme /property:property=value
, qui sont respectés par dotnet build
.
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é.
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.
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.
--
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 surwin-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
etProduction
. 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 surlinux-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]
etdiag[nostic]
. La valeur par défaut estminimal
. Pour plus d'informations, consultez LoggerVerbosity.
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
Commentaires sur .NET
.NET est un projet open source. Sélectionnez un lien pour fournir des commentaires :