dotnet run
Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höher
dotnet run
: Führt Quellcode ohne explizite Kompilierungs- oder Startbefehle aus.
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
Der dotnet run
-Befehl bietet eine praktische Option zum Ausführen der Anwendung aus dem Quellcode mit einem Befehl. Es empfiehlt sich für eine schnelle iterative Entwicklung aus der Befehlszeile. Der Befehl hängt vom dotnet build
-Befehl ab, um den Code zu erstellen. Alle Anforderungen für den Build gelten auch für dotnet run
.
Hinweis
dotnet run
berücksichtigt keine Argumente wie /property:property=value
, die von dotnet build
berücksichtigt werden.
Ausgabedateien werden im Standardspeicherort bin/<configuration>/<target>
geschrieben. Angenommen, Sie haben eine netcoreapp2.1
-Anwendung und Sie führen dotnet run
aus, dann wird die Ausgabe in bin/Debug/netcoreapp2.1
platziert. Dateien werden bei Bedarf überschrieben. Temporäre Dateien befinden sich im obj
-Verzeichnis.
Wenn das Projekt mehrere Frameworks angibt, führt das Ausführen von dotnet run
zu einem Fehler, wenn nicht die -f|--framework <FRAMEWORK>
-Option verwendet wird, um das Framework anzugeben.
Der Befehl dotnet run
wird im Kontext von Projekten verwendet, nicht von erstellten Assemblys. Wenn Sie stattdessen eine Framework-abhängige DLL-Anwendung ausführen möchten, müssen Sie dotnet ohne einen Befehl verwenden. Zum Ausführen von myapp.dll
verwenden Sie z.B.:
dotnet myapp.dll
Weitere Informationen zum dotnet
-Treiber finden Sie unter .NET-Befehlszeilentools (CLI).
Der Befehl dotnet run
löst die Abhängigkeiten der Anwendungen außerhalb der freigegebenen Laufzeit aus dem NuGet-Cache, um die Anwendung auszuführen. Da sie zwischengespeicherte Abhängigkeiten verwendet, wird nicht empfohlen, dotnet run
zur Ausführung der Anwendungen in der Produktion zu verwenden. Stattdessen erstellen Sie eine Bereitstellung mithilfe des dotnet publish
-Befehls und stellen die veröffentlichte Ausgabe bereit.
Sie müssen dotnet restore
nicht ausführen, da der Befehl implizit von allen Befehlen ausgeführt wird, die eine Wiederherstellung erfordern. Zu diesen zählen z. B. dotnet new
, dotnet build
, dotnet run
, dotnet test
, dotnet publish
und dotnet pack
. Verwenden Sie die Option --no-restore
, um die implizite Wiederherstellung zu deaktivieren.
In bestimmten Fällen eignet sich der dotnet restore
-Befehl dennoch. Dies ist etwa bei Szenarios der Fall, in denen die explizite Wiederherstellung sinnvoll ist. Beispiele hierfür sind Continuous Integration-Builds in Azure DevOps Services oder Buildsysteme, die den Zeitpunkt für die Wiederherstellung explizit steuern müssen.
Informationen zum Verwalten von NuGet-Feeds finden Sie in der dotnet restore
Dokumentation.
Dieser Befehl unterstützt die dotnet restore
-Optionen, wenn sie in der Langform (z. B. --source
) übergeben werden. Optionen in Kurzform wie z.B. -s
werden nicht unterstützt.
Wenn Sie diesen Befehl ausführen, wird im Hintergrund ein asynchroner Download initiiert, der Ankündigungsmanifeste für Workloads herunterlädt. Wenn der Download noch ausgeführt wird, wenn der Befehl abgeschlossen ist, wird der Download angehalten. Weitere Informationen finden Sie unter Ankündigungsmanifeste.
--
Grenzt Argumente für
dotnet run
von Argumenten für die ausgeführte Anwendung ab. Alle Argumente nach diesem Trennzeichen werden an die Anwendungsausführung übergeben.
-a|--arch <ARCHITECTURE>
Legt die Zielarchitektur fest. Dies ist eine Kurzsyntax zum Setzen des Runtimebezeichners (RID), wobei der angegebene Wert mit dem Standard-RID kombiniert wird. Auf einem
win-x64
Rechner wird beispielsweise durch die Angabe von--arch x86
der RID aufwin-x86
gesetzt. Wenn Sie diese Option verwenden, dürfen Sie Option-r|--runtime
nicht verwenden. Verfügbar seit .NET 6 Preview 7.
-c|--configuration <CONFIGURATION>
Legt die Buildkonfiguration fest. Der Standardwert für die meisten Projekte ist
Debug
, aber Sie können die Buildkonfigurationseinstellungen in Ihrem Projekt überschreiben.
-f|--framework <FRAMEWORK>
Erstellt und führt die Anwendung mithilfe des angegebenen Frameworks aus. Das Framework muss in der Projektdatei angegeben werden.
--force
Erzwingt das Auflösen aller Abhängigkeiten, auch wenn die letzte Wiederherstellung erfolgreich war. Dieses Flag anzugeben, entspricht dem Löschen der Datei project.assets.json.
-?|-h|--help
Gibt eine Beschreibung zur Verwendung des Befehls aus.
--interactive
Ermöglicht dem Befehl, anzuhalten und auf Benutzereingaben oder Aktionen zu warten. Beispielsweise, um die Authentifizierung abzuschließen. Verfügbar seit .NET Core 3.0 SDK.
--launch-profile <NAME>
Der Name des beim Start einer Anwendung zu verwendenden Startprofils (falls vorhanden). Startprofile werden in der Datei launchSettings.json definiert und heißen normalerweise
Development
,Staging
undProduction
. Weitere Informationen finden Sie unter Working with multiple environments (Verwenden von mehreren Umgebungen).--no-build
Erstellt das Projekt nicht vor der Ausführung. Zudem wird das Flag
--no-restore
implizit festgelegt.--no-dependencies
Wenn Sie ein Projekt mit Projekt-zu-Projekt-Verweisen (P2P) wiederherstellen, stellen Sie das Stammprojekt wieder her und nicht die Verweise.
--no-launch-profile
Versucht nicht, die Anwendung mit launchSettings.json zu konfigurieren.
--no-restore
Führt keine implizite Wiederherstellung aus, wenn der Befehl ausgeführt wird.
--os <OS>
Gibt das Zielbetriebssystem an. Dies ist eine Kompaktsyntax zum Festlegen des Runtimebezeichners (RID), wobei der angegebene Wert mit der Standard-RID kombiniert wird. Auf einem
win-x64
Rechner wird beispielsweise durch die Angabe von--os linux
der RID auflinux-x64
gesetzt. Wenn Sie diese Option verwenden, dürfen Sie Option-r|--runtime
nicht verwenden. Verfügbar seit .NET 6.
--project <PATH>
Gibt den Pfad der auszuführenden Projektdatei an (Ordnername oder vollständiger Pfad). Wenn nicht angegeben, wird standardmäßig das aktuelle Verzeichnis gewählt.
Die
-p
-Abkürzung für--project
ist ab dem .NET 6 SDK veraltet. Für eine begrenzte Zeit, beginnend mit .NET 6 RC1 SDK, kann-p
trotz der Warnung vor Veraltung weiterhin für--project
verwendet werden. Wenn das für die Option angegebene Argument kein=
enthält, akzeptiert der Befehl-p
als Abkürzung für--project
. Andernfalls nimmt der Befehl an, dass-p
die Abkürzung für--property
ist. Diese flexible Verwendung von-p
für--project
wird in .NET 7 auslaufen.--property:<NAME>=<VALUE>
Legt eine oder mehrere MSBuild Eigenschaften fest. Geben Sie mehrere Eigenschaften an, die durch Semikolons getrennt sind, oder wiederholen Sie die Option:
.NET CLI--property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2> --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
Die Kurzform
-p
kann für--property
verwendet werden. Wenn das für die Option angegebene Argument=
enthält, wird-p
als Abkürzung für--property
akzeptiert. Andernfalls nimmt der Befehl an, dass-p
die Abkürzung für--project
ist.Um
--property
an die Anwendung zu übergeben, statt eine MSBuild-Eigenschaft zu setzen, geben Sie die Option z. B. nach dem Syntaxtrennzeichen--
an:.NET CLIdotnet run -- --property name=value
-r|--runtime <RUNTIME_IDENTIFIER>
Gibt die Ziellaufzeit an, für die Pakete wiederhergestellt werden sollen Eine Liste der Runtime-IDs (RIDs) finden Sie unter RID-Katalog.
--tl:[auto|on|off]
Gibt an, ob die Terminalprotokollierung für die Buildausgabe verwendet werden soll. Der Standardwert ist
auto
, mit den zunächst die Umgebung überprüft wird, bevor die Terminalprotokollierung aktiviert wird. Die Umgebungsprüfung testet, ob das Terminal moderne Ausgabefeatures verwenden kann und keine umgeleitete Standardausgabe verwendet, bevor die neue Protokollierung aktiviert wird.on
überspringt die Umgebungsprüfung und aktiviert die Terminalprotokollierung.off
überspringt die Umgebungsprüfung und verwendet die Standardkonsolenprotokollierung.Die Terminalprotokollierung zeigt die Wiederherstellungsphase gefolgt von der Buildphase an. Während jeder Phase werden am unteren Rand des Terminals die derzeit erstellten Projekte angezeigt. Für jedes erstellte Projekt wird sowohl das MSBuild-Ziel für den Build als auch die Zeit ausgegeben, die für dieses Ziel aufgewendet wurde. Sie können diese Informationen durchsuchen, um mehr über den Build zu erfahren. Wenn die Erstellung eines Projekts abgeschlossen ist, wird ein einzelner Abschnitt „Build abgeschlossen“ geschrieben, in dem Folgendes erfasst wird:
- Der Name des erstellten Projekts
- Das Zielframework (bei mehreren Zielen)
- Der Status dieses Builds
- Die primäre Ausgabe dieses Builds (als Link)
- Alle für dieses Projekt generierten Diagnoseinformationen
Diese Option ist ab .NET 8 verfügbar.
-v|--verbosity <LEVEL>
Legt den Ausführlichkeitsgrad für den Befehl fest. Zulässige Werte sind
q[uiet]
,m[inimal]
,n[ormal]
,d[etailed]
unddiag[nostic]
. Der Standardwert istminimal
. Weitere Informationen finden Sie unter LoggerVerbosity.
Führt das Projekt im aktuellen Verzeichnis aus:
.NET CLIdotnet run
Führt das angegebene Projekt aus:
.NET CLIdotnet run --project ./projects/proj1/proj1.csproj
Führen Sie das Projekt im aktuellen Verzeichnis aus und geben Sie die Release-Konfiguration an:
.NET CLIdotnet run --property:Configuration=Release
Führt das Projekt im aktuellen Verzeichnis aus (das Argument
--help
in diesem Beispiel wird der Anwendung übergeben, da die leere Option--
verwendet wird):.NET CLIdotnet run --configuration Release -- --help
Stellt Abhängigkeiten und Tools für das Projekt im aktuellen Verzeichnis wieder her, wobei nur eine minimale Ausgabe angezeigt wird, und führt das Projekt dann aus:
.NET CLIdotnet run --verbosity m
Feedback zu .NET
.NET ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben: