dotnet run

Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höher

Name

dotnet run: Führt Quellcode ohne explizite Kompilierungs- oder Startbefehle aus.

Übersicht

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

Beschreibung

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 .

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.

Implizite Wiederherstellung

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

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.

Workload manifest downloads

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.

Optionen

• --

  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 auf win-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 und Production. 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 auf linux-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:

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

  dotnet 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] und diag[nostic]. Der Standardwert ist minimal. Weitere Informationen finden Sie unter LoggerVerbosity.

Beispiele

• Führt das Projekt im aktuellen Verzeichnis aus:

  dotnet run
  

• Führt das angegebene Projekt aus:

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

• Führen Sie das Projekt im aktuellen Verzeichnis aus und geben Sie die Release-Konfiguration an:

  dotnet 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):

  dotnet 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:

  dotnet run --verbosity m