Teilen über

dotnet run

Dieser Artikel gilt für: ✔️ .NET 6 SDK und höhere Versionen

Name

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

Übersicht

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

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 .

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 in der .NET CLI-Übersicht.

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.

Workloadmanifestdownloads

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.

Arguments

<applicationArguments>

Argumente, die an die Anwendung übergeben werden, die ausgeführt wird.

Alle Argumente, die nicht erkannt dotnet run werden, werden an die Anwendung übergeben. Verwenden Sie die dotnet run Option, um Argumente -- von Argumenten für die Anwendung zu trennen.

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.

  • --artifacts-path <ARTIFACTS_DIR>

    Alle Buildausgabedateien des ausgeführten Befehls werden in Unterordnern unter dem angegebenen Pfad, getrennt durch Das Projekt, verschoben. Weitere Informationen finden Sie unter "Artifacts Output Layout". Verfügbar ab dem .NET 8 SDK.

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

  • --disable-build-servers

    Erzwingt, dass der Befehl alle persistenten Buildserver ignoriert. Diese Option bietet eine konsistente Möglichkeit, die gesamte Verwendung von Buildcaches zu deaktivieren, wodurch die Neuerstellung eines Build von Grund auf erzwungen wird. Ein Build, der sich nicht auf Caches stützt, ist nützlich, wenn die Caches aus irgendeinem Grund beschädigt oder fehlerhaft sein können. Verfügbar ab dem .NET 7 SDK.

  • -e|--environment <KEY=VALUE>

    Legt die angegebene Umgebungsvariable im Prozess fest, der vom Befehl ausgeführt wird. Die angegebene Umgebungsvariable wird nicht auf den dotnet run Prozess angewendet.

    Durch diese Option übergebene Umgebungsvariablen haben Vorrang vor Umgebungsumgebungsvariablen, System.CommandLine-Direktiven env und environmentVariables aus dem ausgewählten Startprofil. Weitere Informationen finden Sie unter Umgebungsvariablen.

    (Diese Option wurde in .NET SDK 9.0.200 hinzugefügt.)

  • -f|--framework <FRAMEWORK>

    Erstellt und führt die Anwendung mithilfe des angegebenen Frameworks aus. Das Framework muss in der Projektdatei angegeben werden.

  • --file <FILE_PATH>

    Der Pfad zur dateibasierten App, die ausgeführt werden soll. Wenn kein Pfad angegeben ist, wird das aktuelle Verzeichnis verwendet, um die Datei zu suchen und auszuführen. Weitere Informationen zu dateibasierten Apps finden Sie unter Erstellen dateibasierter C#-Apps.

    Auf Unix können Sie dateibasierte Apps direkt ausführen, indem Sie den Quelldateinamen in der Befehlszeile anstelle von dotnet run. Stellen Sie zunächst sicher, dass die Datei über Ausführungsberechtigungen verfügt. Fügen Sie dann eine Shebang-Zeile #! als erste Zeile der Datei hinzu, z. B.:

    #!/usr/bin/env dotnet run

    Anschließend können Sie die Datei direkt über die Befehlszeile ausführen:

    ./ConsoleApp.cs

    In .NET SDK 10.0.100 eingeführt.

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

  • --interactive

    Ermöglicht dem Befehl, anzuhalten und auf Benutzereingaben oder Aktionen zu warten. Beispielsweise, um die Authentifizierung abzuschließen.

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

    Überspringen Sie die aktuellen Prüfungen, und erstellen Sie das Programm immer, bevor Sie ausgeführt werden.

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

  • --no-self-contained

    Veröffentlichen Sie Ihre Anwendung als frameworkabhängige Anwendung. Eine kompatible .NET-Runtime muss auf dem Zielcomputer installiert sein, um Ihre Anwendung auszuführen.

  • --os <OS>

    Gibt das Zielbetriebssystem an. 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 --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 einen begrenzten Zeitraum -p kann trotz der Warnwarnung weiterhin verwendet --project 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.

  • --sc|--self-contained

    Veröffentlichen Sie die .NET-Laufzeit mit Ihrer Anwendung, damit die Laufzeit nicht auf dem Zielcomputer installiert werden muss.

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

    Gibt an, ob terminal logger 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.

    Terminal Logger zeigt Ihnen die Wiederherstellungsphase gefolgt von der Buildphase. 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.

  • -?|-h|--help

    Gibt eine Beschreibung zur Verwendung des Befehls aus.

Umgebungsvariablen

Es gibt vier Mechanismen, mit denen Umgebungsvariablen auf die gestartete Anwendung angewendet werden können:

  1. Umgebungsumgebungsvariablen vom Betriebssystem, wenn der Befehl ausgeführt wird.
  2. System.CommandLine-Direktiven env , z. B [env:key=value]. . Diese gelten für den gesamten dotnet run Prozess, nicht nur für das Projekt, von dotnet rundem ausgeführt wird.
  3. environmentVariables aus dem ausgewählten Startprofil (-lp) in der launchSettings.json-Datei des Projekts, falls vorhanden. Diese gelten für das Projekt, von dotnet rundem ausgeführt wird.
  4. -e|--environment CLI-Optionswerte (hinzugefügt in .NET SDK, Version 9.0.200). Diese gelten für das Projekt, von dotnet rundem ausgeführt wird.

Die Umgebung wird in derselben Reihenfolge wie diese Liste erstellt, sodass die -e|--environment Option die höchste Priorität hat.

Beispiele

  • Führt das Projekt im aktuellen Verzeichnis aus:

    dotnet run

  • Führen Sie die angegebene dateibasierte App im aktuellen Verzeichnis aus:

    dotnet run --file ConsoleApp.cs

    Dateibasierte App-Unterstützung wurde im .NET SDK 10.0.100 hinzugefügt.

  • 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

  • Führen Sie das Projekt im aktuellen Verzeichnis mithilfe des angegebenen Frameworks aus, und übergeben Sie Argumente an die Anwendung:

    dotnet run -f net6.0 -- arg1 arg2

    Im folgenden Beispiel werden drei Argumente an die Anwendung übergeben. Ein Argument wird mithilfe von -Übergeben, und zwei Argumente werden übergeben:--

    dotnet run -f net6.0 -arg1 -- arg2 arg3
  • Last updated on