dotnet run

Dieser Artikel bezieht sich auf: ✔️ .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>] [--disable-build-servers]
  [-e|--environment <KEY=VALUE>] [--file <FILE_PATH>]
  [-f|--framework <FRAMEWORK>] [--force] [--interactive]
  [-lp|--launch-profile <NAME>] [--no-build] [--no-cache]
  [--no-dependencies] [--no-launch-profile] [--no-restore] [--os <OS>]
  [-p|--property:<PROPERTYNAME>=<VALUE>]
  [--project <PATH>] [-r|--runtime <RUNTIME_IDENTIFIER>]
  [--sc|--self-contained] [--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 treiber dotnet finden Sie unter .NET CLI overview.

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.

Der Befehl dotnet restore ist in bestimmten Szenarien weiterhin nützlich, in denen die explizite Wiederherstellung sinnvoll ist, z. B. kontinierende Integrationsbuilds in Azure DevOps Services oder in Buildsystemen, die explizit steuern müssen, wann die Wiederherstellung erfolgt.

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.

Profile starten

Starten Sie Profile, die konfigurieren, wie dotnet run eine App während der Entwicklung gestartet wird. Legen Sie für ein PROJEKT im SDK-Stil die Einstellungen in Properties/launchSettings.json. Visual Basic Projekte stattdessen verwendenMy Project/launchSettings.json.

Dateibasierte Apps können eine [ApplicationName].run.json Datei neben der Quelldatei verwenden. Die Dateisuchreihenfolge und Beispiele finden Sie unter Startprofile für dateibasierte Apps.

Die Starteinstellungsdatei enthält ein Objekt der obersten Ebene profiles . Jede Eigenschaft in profiles definiert ein benanntes Profil:

{
  "profiles": {
    "Local": {
      "commandName": "Project",
      "commandLineArgs": "--input sample.txt",
      "dotnetRunMessages": true,
      "environmentVariables": {
        "APP_MODE": "local"
      }
    }
  }
}

Der .NET SDK-Starteinstellungen-Parser akzeptiert JSON-Kommentare und nachfolgende Kommas.

Profil auswählen

Wird --launch-profile <NAME> verwendet, um ein benanntes Profil auszuwählen. Bei der Namensbesprechung wird die Groß-/Kleinschreibung nicht beachtet. Profilnamen, die sich nur nach Groß-/Kleinschreibung unterscheiden, sind mehrdeutig und erzeugen einen Fehler.

Wenn Sie keinen Namen angeben, dotnet run wählt das erste Profil in der Dateireihenfolge aus, deren commandName Unterstützung sie unterstützt. Verwenden Sie --no-launch-profile diese Einstellungsdatei, um die Starteinstellungsdatei zu überspringen.

Wenn dotnet run ein Profil angewendet wird, wird er im gestarteten Prozess auf den ausgewählten Profilnamen festgelegt DOTNET_LAUNCH_PROFILE . Eine spätere Umgebungsvariablenquelle kann den Wert überschreiben.

Unterstützte Profiltypen

Das .NET SDK unterstützt diese commandName Werte für dotnet run. Bei den Werten wird die Groß-/Kleinschreibung beachtet.

commandName Behavior
Project Erstellt das Projekt und startet den vom Projekt erstellten Befehl.
Executable Startet den befehl, der durch executablePath. Es sei denn, Sie geben --no-buildan, dotnet run dass das Projekt zuerst erstellt wird.

Allgemeine Eigenschaften

dotnet run erkennt diese Eigenschaften für beide unterstützten Profiltypen:

dotnet run erweitert umgebungsvariable %NAME% Verweise in unterstützten Zeichenfolgenwerten. In .NET 11 und neueren Versionen werden auch MSBuild-Eigenschaftsverweise in Werten erweitert, die zum Starten des Prozesses verwendet werden, wobei die gleiche Tokenersetzung wie Visual Studio verwendet wird. Es werden keine Verweise im Shellstil $NAME erweitert.

Property Behavior
commandLineArgs Gibt Argumente für den gestarteten Prozess an. Explizite Anwendungsargumente in der Befehlszeile haben Vorrang. Für ein Project Profil haben auch argumente, die vom project bereitgestellt werden, Vorrang.
environmentVariables Gibt Umgebungsvariablen für den gestarteten Prozess an. Profilwerte überschreiben geerbte und vom SDK generierte Umgebungsvariablen und -e\|--environment Werte überschreiben Profilwerte.
dotnetRunMessages Wenn true, druckt Building... vor dotnet run dem Erstellen des Projekts. Der Standardwert ist false. Diese Eigenschaft steuert nicht die Nachricht, die die Starteinstellungsdatei identifiziert.

Hiermit wenden Sie environmentVariables Konfigurationseinstellungen für die Entwicklungszeitlaufzeit an, die über ein Umgebungsvariablenformular verfügen. Beispielsweise kann ein Profil GC-Einstellungen festlegen, z DOTNET_gcServer. B. . Die verfügbaren Einstellungen, Namen von Umgebungsvariablen und Rangfolgeregeln finden Sie unter .NET Laufzeitkonfigurationseinstellungen und Laufzeitkonfigurationsoptionen für die Garbage Collection.

Nicht jede Laufzeiteinstellung verfügt über ein umgebungsvariables Formular. Um eine App unabhängig von ihrem Startprofil zu konfigurieren, verwenden Sie eine MSBuild-Eigenschaft oder RuntimeHostConfigurationOption ein Element im Projekt, oder verwenden Sie eine runtimeconfig.template.json Datei. Einige Einstellungen können auch im Code mit AppContext.SetSwitchgeändert werden. Diese Mechanismen erzeugen oder ändern die Laufzeitkonfiguration der App; sie sind keine zusätzlichen launchSettings.json Eigenschaften.

Project Eigenschaften

dotnet run erkennt diese zusätzlichen Eigenschaften in folgenden Fällen commandNameProject:

Property Behavior
applicationUrl Legt ASPNETCORE_URLS im gestarteten Prozess fest. Ein ASPNETCORE_URLS Wert in environmentVariables oder aus -e\|--environment ihm hat Vorrang.
launchBrowser Teilt dem Starttool mit, ob ein Browser geöffnet werden soll. dotnet run behält diese Eigenschaft im analysierten Profil bei, öffnet jedoch keinen Browser.
launchUrl Teilt dem Starttool mit, welche URL geöffnet werden soll. dotnet run behält diese Eigenschaft im analysierten Profil bei, öffnet aber keinen Browser oder verwendet die URL.

Das applicationUrl Verhalten unterstützt ASP.NET Core, aber Startprofile und die anderen allgemeinen Eigenschaften gelten für jedes ausgeführte SDK-Format .NET Projekt.

Executable Eigenschaften

dotnet run erkennt diese zusätzlichen Eigenschaften in folgenden Fällen commandNameExecutable:

Property Behavior
executablePath Required. Gibt den zu startenden Prozess an. Das SDK erweitert unterstützte Variablenverweise, löst jedoch keinen relativen Wert für die Starteinstellungsdatei auf. Verwenden Sie einen absoluten Pfad oder einen Befehl, den das Betriebssystem finden kann.
workingDirectory Optional. Gibt das Arbeitsverzeichnis für den gestarteten Prozess an. Das SDK erweitert unterstützte Variablenverweise und löst einen relativen Pfad für das Verzeichnis auf, das die Starteinstellungsdatei enthält. Wenn Sie die Eigenschaft weglassen, wird das Arbeitsverzeichnis standardmäßig auf das Verzeichnis festgelegt, das das Projekt oder die dateibasierte App enthält.

Visual Studio- und Debuggererweiterungen

launchSettings.json ist ein gemeinsames Eingabeformat, aber jeder Verbraucher entscheidet, welche Werte unterstützt werden sollen und wie sie interpretiert werden sollen. Visual Studio, Debugger und andere Tools können mehr commandName Werte und Eigenschaften erkennen als dotnet run.

In der folgenden Tabelle wird der dotnet run Vertrag mit dem allgemeinen .NET Projektsystemverhalten in Visual Studio verglichen:

Einstellung oder Verhalten dotnet run Visual Studio
Unterstützte Profiltypen Unterstützt Project und Executable. Unterstützt Project, Executable, und eine leere commandName. Installierte Projektsystemerweiterungen können weitere Profiltypen hinzufügen.
Variable Erweiterung Erweitert Umgebungsvariablenverweise %NAME% . In .NET 11 und höheren Versionen werden auch MSBuild-Eigenschaftsverweise in Werten erweitert, die zum Starten des Prozesses verwendet werden. Erweitert Umgebungsvariablen und MSBuild-Eigenschaften in executablePath, , commandLineArgsworkingDirectorylaunchUrl, Umgebungsvariablenwerten und Zeichenfolgenwerterweiterungseinstellungen.
commandLineArgs für Project Verwendet den Profilwert nur, wenn das Projekt keine Ausführungsargumente bereitstellt und Sie keine Anwendungsargumente in der Befehlszeile übergeben. Fügt den Profilwert an die ausgeführten Argumente aus dem Projekt an.
workingDirectory für Project Ignoriert die Eigenschaft. Unterstützt die Eigenschaft. Ein relativer Pfad ist relativ zum Projektverzeichnis.
workingDirectory für Executable Ein relativer Pfad ist relativ zum Verzeichnis, das die Starteinstellungsdatei enthält. Wenn dieser Parameter nicht angegeben wird, wird der Pfad standardmäßig im Projekt- oder dateibasierten App-Verzeichnis gespeichert. Ein relativer Pfad ist relativ zum Projektverzeichnis. Wenn dieser Wert nicht angegeben wird, wird der Pfad standardmäßig für das Ausgabeverzeichnis verwendet, wenn dieses Verzeichnis vorhanden ist, oder andernfalls zum Projektverzeichnis.
Relativ executablePath Übergibt den Wert an das Betriebssystem, ohne ihn neu zubasieren. Löst einen Wert mit Pfadkomponenten aus dem Arbeitsverzeichnis des Profils auf. Bei einem namen einer offenen ausführbaren Datei überprüft Visual Studio sein eigenes aktuelles Verzeichnis und dann PATH.
launchBrowser und launchUrl Behält die Werte im analysierten Profil bei, aber öffnet keinen Browser. Macht die Werte für einen Startanbieter verfügbar. Beispielsweise kann ASP.NET Core Tools einen Browser öffnen.
applicationUrl Legt fest ASPNETCORE_URLS. Macht den Wert für installierte Startanbieter verfügbar, z. B. ASP.NET Core Tooling.
dotnetRunMessages Steuert die Building... Nachricht. Verwendet die Eigenschaft nicht zum Steuern Visual Studio Ausgabe.
Debuggereigenschaften Ignoriert debuggerspezifische Eigenschaften. Verwendet Eigenschaften wie nativeDebugging, sqlDebugging, jsWebView2Debugging, remoteDebugEnabledund hotReloadEnabled wenn das Projekt und der Debugger das Feature unterstützen.

In .NET 11 und höheren Versionen erweitern "$(ProjectDir)"beide Verbraucher . In früheren Versionen identifiziert kein einzelner workingDirectory Wert das Projektverzeichnis für beide Verbraucher. Visual Studio wird erweitert "$(ProjectDir)"und dotnet run behandelt ihn als Literaltext und löst relative Pfade aus dem Verzeichnis auf, das die Starteinstellungsdatei enthält. Verwenden Sie ".." daher für dotnet run eine herkömmliche Properties/launchSettings.json Datei oder My Project/launchSettings.json datei. Visual Studio löst denselben Wert in das übergeordnete Element des Projektverzeichnisses auf.

Windows Forms und WPF Apps fügen keinen anderen dotnet run Profiltyp hinzu. Verwenden Sie ein Project Profil mit allgemeinen Einstellungen wie commandLineArgs z. B. und environmentVariables. In Visual Studio können diese Desktopprojekttypen auch anwendbare Debuggereigenschaften verwenden, znativeDebugging. B. für gemischt verwaltetes und systemeigenes Debuggen oder jsWebView2Debugging für WebView2. Browser- und URL-Eigenschaften wirken sich nur aus, wenn ein Startanbieter oder die Anwendung sie nutzt.

Andere Projekttypen und Visual Studio Workloads können Startanbieter installieren, die Profiltypen hinzufügen oder zusätzliche Eigenschaften interpretieren. Diese Erweiterungen fügen keine Unterstützung hinzu dotnet run: Die CLI überspringt während der Standardauswahl nicht unterstützte Profiltypen und meldet einen Fehler, wenn Sie eine explizite Auswahl auswählen.

Informationen zu Visual Studio unterstützten Debuggereinstellungen und project Ui finden Sie unter Project Einstellungen für eine .NET C#-Debugkonfiguration.

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.

Weiterleiten von Argumenten an die Anwendung

dotnet run leitet jedes Token weiter, das er an die Anwendung nicht erkennt. Die weitergeleiteten Token behalten ihre ursprüngliche Reihenfolge bei, entfernen jedoch dotnet run zuerst die von ihr verstandenen Optionen. Wenn eine erkannte Option zwischen einem unbekannten Optionsnamen und seinem Wert angezeigt wird, kann das Entfernen der erkannten Option die Bedeutung der Linksovertoken ändern.

Mit dem folgenden Befehl wird beispielsweise die erkannte Option --project zwischen Token interleasiert, die die Anwendung empfangen soll:

dotnet run --app-flag --app-name --project ConsoleApp.csproj A.txt

Nach dotnet run der Nutzung --project ConsoleApp.csprojerhält --app-flag --app-name A.txtdie Anwendung . Die Anwendung wird dann als Wert behandelt A.txt , der --app-namenicht mit der ursprünglichen Befehlszeile übereinstimmt.

Um diese Mehrdeutigkeit zu vermeiden, platzieren Sie Anwendungsargumente nach einem Literal --:

dotnet run --project ConsoleApp.csproj -- --app-flag --app-name A.txt

Das -- Trennzeichen kennzeichnet jedes folgende Token als Anwendungsargument, ordnet dotnet run sie also nicht neu an oder interpretiert sie erneut. Das Trennzeichen stellt auch zukunftssichere Skripts für neue dotnet run Optionen bereit, die später mit einem Token übereinstimmen können, das zuvor an die Anwendung weitergeleitet wurde.

Note

Das gleiche Verhalten gilt für dotnet build und für dotnet test in Microsoft. Testing.Platform (MTP)-Modus, der nicht erkannte Token an MSBuild oder an die Testanwendung weiterleitet. Weitere Informationen dotnet testfinden Sie unter Weiterleiten von Argumenten an die Testanwendung.

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". Diese Option und der bereitgestellte Wert müssen in jedem dotnet Befehl explizit kaskadiert werden, der von der Ausgabe eines anderen dotnet Befehls abhängt, z. B. bei Verwendung dotnet build --no-restore und dotnet publish --no-build. Verfügbar seit .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 seit .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.

    Führen Sie auf Unix dateibasierte Apps direkt unter Verwendung des Dateinamens aus, indem Sie eine Shebang-Direktive (#!) hinzufügen und die Ausführungsberechtigung festlegen. Weitere Informationen finden Sie unter Unix shebang (#!) Support.

    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.

  • -lp|--launch-profile <NAME>

    Der Name des Startprofils, das beim Starten der Anwendung verwendet werden soll. Weitere Informationen finden Sie unter "Launch profiles".

  • --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 Laufzeit 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 Abkürzung -p für --project ist veraltet beginnend mit .NET 6 SDK. 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 eingestellt.

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

Die folgenden Quellen wenden Umgebungsvariablen auf die gestartete Anwendung an:

  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. Vom ausgewählten Startprofil generierte Werte. dotnet runlegt DOTNET_LAUNCH_PROFILEund in einem Project Profilsatz festASPNETCORE_URLSapplicationUrl.
  4. environmentVariables aus dem ausgewählten Startprofil, falls vorhanden. Diese gelten für das Projekt, von dotnet rundem ausgeführt wird.
  5. -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 in .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