dotnet run

Artykuł dotyczy: ✔️ .NET 6 zestawu SDK i nowszych wersji

Nazwisko

dotnet run - Uruchamia kod źródłowy bez jawnego kompilowania lub uruchamiania poleceń.

Streszczenie

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

opis

Polecenie dotnet run zapewnia wygodną opcję uruchamiania aplikacji z kodu źródłowego za pomocą jednego polecenia. Jest to przydatne w przypadku szybkiego iteracyjnego programowania z poziomu wiersza polecenia. Polecenie zależy dotnet build od polecenia do skompilowania kodu. Wszelkie wymagania dotyczące kompilacji mają również zastosowanie dotnet run .

Pliki wyjściowe są zapisywane w domyślnej lokalizacji, czyli bin/<configuration>/<target>. Jeśli na przykład masz aplikację netcoreapp2.1 i uruchomisz dotnet runpolecenie , dane wyjściowe są umieszczane w pliku bin/Debug/netcoreapp2.1. Pliki są zastępowane zgodnie z potrzebami. Pliki tymczasowe są umieszczane w obj katalogu.

Jeśli projekt określa wiele struktur, wykonywanie dotnet run wyników powoduje błąd, chyba że -f|--framework <FRAMEWORK> opcja zostanie użyta do określenia struktury.

Polecenie dotnet run jest używane w kontekście projektów, a nie wbudowanych zestawów. Jeśli zamiast tego próbujesz uruchomić bibliotekę DLL aplikacji zależną od platformy, musisz użyć polecenia dotnet bez polecenia. Aby na przykład uruchomić polecenie myapp.dll, użyj polecenia:

dotnet myapp.dll

Aby uzyskać więcej informacji na temat sterownika dotnet, zobacz .NET omówienie interfejsu wiersza polecenia.

Aby uruchomić aplikację, dotnet run polecenie rozwiązuje zależności aplikacji, które znajdują się poza udostępnionym środowiskiem uruchomieniowym z pamięci podręcznej NuGet. Ponieważ używa on buforowanych zależności, nie zaleca się używania dotnet run ich do uruchamiania aplikacji w środowisku produkcyjnym. Zamiast tego utwórz wdrożenie przy użyciu dotnet publish polecenia i wdróż opublikowane dane wyjściowe.

Niejawne przywracanie

Nie trzeba uruchamiaćdotnet restore, ponieważ jest ona uruchamiana niejawnie przez wszystkie polecenia, które wymagają przywrócenia, takie jak dotnet new, , dotnet build, dotnet rundotnet test, , dotnet publish, i dotnet pack. Aby wyłączyć niejawne przywracanie, użyj --no-restore opcji .

Polecenie dotnet restore jest nadal przydatne w niektórych scenariuszach, w których jawne przywracanie ma sens, takie jak kontynualne kompilacje integracji w usługach Azure DevOps lub w systemach kompilacji, które muszą jawnie kontrolować, kiedy nastąpi przywracanie.

Aby uzyskać informacje na temat zarządzania kanałami informacyjnymi NuGet, zobacz dokumentacjędotnet restore.

To polecenie obsługuje dotnet restore opcje przekazywane w długim formularzu (na przykład --source). Opcje formularza krótkiego, takie jak -s, nie są obsługiwane.

Pobieranie manifestu obciążenia

Po uruchomieniu tego polecenia inicjuje asynchroniczne pobieranie manifestów reklamowych dla obciążeń. Jeśli pobieranie jest nadal uruchomione po zakończeniu tego polecenia, pobieranie zostanie zatrzymane. Aby uzyskać więcej informacji, zobacz Manifesty reklamowe.

Uruchamianie profilów

Uruchamianie profilów umożliwia skonfigurowanie sposobu dotnet run uruchamiania aplikacji podczas programowania. W przypadku projektu w stylu zestawu SDK umieść ustawienia w pliku Properties/launchSettings.json. Visual Basic projekty używają My Project/launchSettings.json zamiast tego.

Aplikacje oparte na plikach mogą używać [ApplicationName].run.json pliku obok pliku źródłowego. Aby uzyskać kolejność wyszukiwania plików i przykłady, zobacz Uruchamianie profilów dla aplikacji opartych na plikach.

Plik ustawień uruchamiania zawiera obiekt najwyższego poziomu profiles . Każda właściwość w programie profiles definiuje nazwany profil:

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

Analizator ustawień uruchamiania zestawu SDK .NET akceptuje komentarze JSON i końcowe przecinki.

Wybierz profil

Użyj --launch-profile <NAME> polecenia , aby wybrać nazwany profil. Dopasowanie nazwy jest bez uwzględniania wielkości liter. Nazwy profilów różniące się tylko wielkością liter są niejednoznaczne i powodują błąd.

Jeśli nie określisz nazwy, dotnet run wybierze pierwszy profil w kolejności plików, której commandName obsługuje. Użyj polecenia --no-launch-profile , aby pominąć plik ustawień uruchamiania.

W przypadku dotnet run zastosowania profilu ustawiana DOTNET_LAUNCH_PROFILE jest nazwa wybranego profilu w uruchomionym procesie. Późniejsze źródło zmiennej środowiskowej może zastąpić wartość.

Obsługiwane typy profilów

Zestaw SDK .NET obsługuje te commandName wartości dla elementu dotnet run. W wartościach uwzględniana jest wielkość liter.

`commandName`	Behavior
`Project`	Kompiluje projekt i uruchamia polecenie utworzone przez projekt.
`Executable`	Uruchamia polecenie określone przez `executablePath`polecenie . Jeśli nie określisz `--no-build`parametru , `dotnet run` nadal kompiluje projekt jako pierwszy.

Wspólne właściwości

dotnet run rozpoznaje te właściwości dla obu obsługiwanych typów profilów:

dotnet run %NAME% rozszerza odwołania do zmiennych środowiskowych w obsługiwanych wartościach ciągów. W .NET 11 i nowszych wersjach rozszerza również odwołania do właściwości MSBuild w wartościach używanych do uruchomienia procesu przy użyciu tego samego zastąpienia tokenu co Visual Studio. Nie rozszerza odwołań w stylu $NAME powłoki.

Property	Behavior
`commandLineArgs`	Określa argumenty dla uruchomionego procesu. Jawne argumenty aplikacji w wierszu polecenia mają pierwszeństwo. `Project` W przypadku profilu argumenty dostarczane przez project również mają pierwszeństwo.
`environmentVariables`	Określa zmienne środowiskowe dla uruchomionego procesu. Wartości profilów zastępują dziedziczone i generowane przez zestaw SDK zmienne środowiskowe, a `-e\\|--environment` wartości zastępują wartości profilów.
`dotnetRunMessages`	Gdy `true`element jest wyświetlany `Building...` przed `dotnet run` skompilowanie projektu. Wartość domyślna to `false`. Ta właściwość nie kontroluje komunikatu identyfikującego plik ustawień uruchamiania.

Służy environmentVariables do stosowania ustawień konfiguracji środowiska uruchomieniowego w czasie programowania, które mają postać zmiennej środowiskowej. Na przykład profil może ustawić ustawienia GC, takie jak DOTNET_gcServer. Aby uzyskać dostępne ustawienia, nazwy zmiennych środowiskowych i reguły pierwszeństwa, zobacz .NET ustawienia konfiguracji środowiska uruchomieniowego i opcje konfiguracji środowiska uruchomieniowego dla odzyskiwania pamięci.

Nie każde ustawienie środowiska uruchomieniowego ma postać zmiennej środowiskowej. Aby skonfigurować aplikację niezależnie od profilu uruchamiania, użyj właściwości lub RuntimeHostConfigurationOption elementu MSBuild w projekcie lub użyj runtimeconfig.template.json pliku. Niektóre ustawienia można również zmienić w kodzie za pomocą polecenia AppContext.SetSwitch. Te mechanizmy tworzą lub modyfikują konfigurację środowiska uruchomieniowego aplikacji; nie są to dodatkowe launchSettings.json właściwości.

`Project` Właściwości

dotnet runrozpoznaje te dodatkowe właściwości, gdy commandName ma wartość :Project

Property	Behavior
`applicationUrl`	Zestawy `ASPNETCORE_URLS` w uruchomionym procesie. Wartość w `environmentVariables` elemencie `ASPNETCORE_URLS` lub z `-e\\|--environment` ma pierwszeństwo.
`launchBrowser`	Informuje o uruchomieniu narzędzi, czy otworzyć przeglądarkę. `dotnet run` Zachowuje tę właściwość w przeanalizowanym profilu, ale nie otwiera przeglądarki.
`launchUrl`	Informuje o uruchomieniu narzędzia, który adres URL ma być otwarty. `dotnet run` Zachowuje tę właściwość w przeanalizowanym profilu, ale nie otwiera przeglądarki ani nie używa adresu URL.

Zachowanie applicationUrl obsługuje ASP.NET Core, ale profile uruchamiania i inne typowe właściwości mają zastosowanie do dowolnego projektu .NET w stylu zestawu SDK, który można uruchomić.

`Executable` Właściwości

dotnet runrozpoznaje te dodatkowe właściwości, gdy commandName ma wartość :Executable

Property	Behavior
`executablePath`	Required. Określa proces do uruchomienia. Zestaw SDK rozszerza obsługiwane odwołania do zmiennych, ale nie rozpoznaje wartości względnej względem pliku ustawień uruchamiania. Użyj ścieżki bezwzględnej lub polecenia, które system operacyjny może zlokalizować.
`workingDirectory`	Optional. Określa katalog roboczy dla uruchomionego procesu. Zestaw SDK rozszerza obsługiwane odwołania do zmiennych i rozpoznaje ścieżkę względną względem katalogu zawierającego plik ustawień uruchamiania. Jeśli pominiesz właściwość, katalog roboczy zostanie domyślnie wyświetlony w katalogu zawierającym projekt lub aplikację opartą na plikach.

rozszerzenia Visual Studio i debugera

launchSettings.json jest udostępnionym formatem danych wejściowych, ale każdy odbiorca decyduje, które wartości mają być obsługiwane i jak je interpretować. Visual Studio, debugery i inne narzędzia mogą rozpoznawać więcej commandName wartości i właściwości niż dotnet run.

W poniższej tabeli porównaliśmy dotnet run kontrakt z typowym zachowaniem .NET project-system w Visual Studio:

Ustawienie lub zachowanie	`dotnet run`	Visual Studio
Obsługiwane typy profilów	Obsługuje `Project` i `Executable`.	Obsługuje `Project`pustą `commandName`wartość , `Executable`i . Zainstalowane rozszerzenia systemu projektu mogą dodawać inne typy profilów.
Rozszerzanie zmiennych	`%NAME%` Rozwija odwołania do zmiennych środowiskowych. W .NET 11 i nowszych wersjach rozszerza również odwołania do właściwości MSBuild w wartościach używanych do uruchomienia procesu.	Rozszerza zmienne środowiskowe i właściwości MSBuild w `executablePath`wartościach , `commandLineArgs`, `workingDirectory`, `launchUrl`zmiennych środowiskowych i rozszerzenia o wartości ciągu.
`commandLineArgs` dla `Project`	Używa wartości profilu tylko wtedy, gdy projekt nie udostępnia argumentów uruchamiania i nie przekazuje argumentów aplikacji w wierszu polecenia.	Dołącza wartość profilu do argumentów uruchamiania z projektu.
`workingDirectory` dla `Project`	Ignoruje właściwość .	Obsługuje właściwość . Ścieżka względna jest względna względem katalogu projektu.
`workingDirectory` dla `Executable`	Ścieżka względna jest względna względem katalogu zawierającego plik ustawień uruchamiania. W przypadku pominięcia ścieżka jest domyślnie ustawiona na katalog aplikacji oparty na pliku lub projekcie.	Ścieżka względna jest względna względem katalogu projektu. W przypadku pominięcia ścieżka jest domyślna dla katalogu wyjściowego, gdy ten katalog istnieje, lub do katalogu projektu w przeciwnym razie.
Względne `executablePath`	Przekazuje wartość do systemu operacyjnego bez ponownego łączenia.	Usuwa wartość ze składnikami ścieżki z katalogu roboczego profilu. W przypadku nazwy pliku wykonywalnego na pasku Visual Studio sprawdza własny bieżący katalog, a następnie `PATH`.
`launchBrowser` i `launchUrl`	Zachowuje wartości w przeanalizowanym profilu, ale nie otwiera przeglądarki.	Udostępnia wartości dostawcy uruchamiania. Na przykład ASP.NET Core narzędzia mogą otwierać przeglądarkę.
`applicationUrl`	Ustawia wartość `ASPNETCORE_URLS`.	Udostępnia wartość zainstalowanym dostawcom uruchamiania, takim jak narzędzia ASP.NET Core.
`dotnetRunMessages`	Steruje komunikatem `Building...` .	Nie używa właściwości do kontrolowania Visual Studio danych wyjściowych.
Właściwości debugera	Ignoruje właściwości specyficzne dla debugera.	Używa właściwości, takich jak `nativeDebugging`, , `sqlDebuggingjsWebView2Debugging`, `remoteDebugEnabled`i`hotReloadEnabled`, gdy projekt i debuger obsługują tę funkcję.

W .NET 11 i nowszych wersjach obaj odbiorcy rozszerzają węzeł "$(ProjectDir)". We wcześniejszych wersjach żadna pojedyncza workingDirectory wartość nie identyfikuje katalogu projektu dla obu odbiorców. Visual Studio rozszerza "$(ProjectDir)"element , lecz dotnet run traktuje go jako tekst literału i rozpoznaje ścieżki względne z katalogu zawierającego plik ustawień uruchamiania. W związku z tym należy używać elementu ".."dotnet run z konwencjonalnym Properties/launchSettings.json plikiem lub My Project/launchSettings.json plikiem. Visual Studio rozpoznaje tę samą wartość dla elementu nadrzędnego katalogu projektu.

Windows Forms i aplikacje WPF nie dodają innego dotnet run typu profilu. Project Użyj profilu z typowymi ustawieniami, takimi jak commandLineArgs i environmentVariables. W Visual Studio te typy projektów klasycznych mogą również używać odpowiednich właściwości debugera, takich jak nativeDebugging mieszane debugowanie zarządzane i natywne lub jsWebView2Debugging WebView2. Właściwości przeglądarki i adresu URL mają wpływ tylko wtedy, gdy dostawca uruchamiania lub aplikacja z nich korzysta.

Inne typy projektów i obciążenia Visual Studio mogą instalować dostawców uruchamiania, którzy dodają typy profilów lub interpretują dodatkowe właściwości. Te rozszerzenia nie dodają obsługi : dotnet runinterfejs wiersza polecenia pomija nieobsługiwane typy profilów podczas wyboru domyślnego i zgłasza błąd po jawnym wybraniu.

Aby uzyskać informacje o obsługiwanych ustawieniach debugera Visual Studio i interfejsie użytkownika project, zobacz Project ustawienia konfiguracji debugowania .NET C#.

Arguments

<applicationArguments>

Argumenty przekazywane do uruchamianej aplikacji.

Wszystkie argumenty, które nie są rozpoznawane przez dotnet run usługę, są przekazywane do aplikacji. Aby oddzielić argumenty od dotnet run argumentów aplikacji, użyj -- opcji .

Przekazywanie argumentów do aplikacji

dotnet run przekazuje token, który nie rozpoznaje aplikacji. Przekazane tokeny zachowują oryginalną kolejność, ale dotnet run najpierw usuwa opcje, które rozumie. Gdy rozpoznana opcja pojawia się między nierozpoznaną nazwą opcji a jej wartością, usunięcie rozpoznanej opcji może zmienić znaczenie tokenów pozostałych.

Na przykład następujące polecenie przeplata rozpoznaną opcję --project między tokenami, które aplikacja ma odbierać:

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

Po dotnet run zużyje --project ConsoleApp.csprojelement , aplikacja otrzymuje wartość --app-flag --app-name A.txt. Następnie aplikacja traktuje A.txt jako wartość --app-name, która nie jest zgodna z oryginalnym wierszem polecenia.

Aby uniknąć tej niejednoznaczności, umieść argumenty aplikacji po literału --:

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

Separator -- oznacza każdy następujący token jako argument aplikacji, więc dotnet run nie zmienia kolejności ani nie interpretuje ich ponownie. Separator również skrypty sprawdzające przyszłość względem nowych dotnet run opcji, które mogą później odpowiadać tokenowi przekazanemu wcześniej do aplikacji.

Uwaga / Notatka

To samo zachowanie dotyczy dotnet build i dotnet test w Microsoft. Tryb Testing.Platform (MTP), który przekazuje nierozpoznane tokeny do programu MSBuild lub odpowiednio do aplikacji testowej. Aby uzyskać więcej informacji na temat dotnet testprogramu , zobacz Przekazywanie argumentów do aplikacji testowej.

Opcje

--

Ogranicz argumenty do dotnet run z argumentów dla uruchamianej aplikacji. Wszystkie argumenty po tym ograniczniku są przekazywane do uruchomienia aplikacji.
-a|--arch <ARCHITECTURE>

Określa architekturę docelową. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --arch x86 ustawia identyfikator RID na win-x86wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji . Dostępne od .NET 6 (wersja zapoznawcza 7).
--artifacts-path <ARTIFACTS_DIR>

Wszystkie pliki wyjściowe kompilacji z wykonanego polecenia zostaną umieszczone w podfolderach w określonej ścieżce oddzielonej przez projekt. Aby uzyskać więcej informacji, zobacz Artifacts Output Layout. Ta opcja i podana wartość muszą być jawnie kaskadowe w dowolnym dotnet poleceniu, które zależy od danych wyjściowych innego dotnet polecenia, na przykład w przypadku użycia dotnet build --no-restore i dotnet publish --no-build. Dostępne od .NET 8 zestawu SDK.
-c|--configuration <CONFIGURATION>

Definiuje konfigurację kompilacji. Wartość domyślna dla większości projektów to Debug, ale można zastąpić ustawienia konfiguracji kompilacji w projekcie.
--disable-build-servers

Wymusza zignorowanie jakichkolwiek trwałych serwerów kompilacji. Ta opcja zapewnia spójny sposób wyłączania całego użycia buforowania kompilacji, co wymusza kompilację od podstaw. Kompilacja, która nie opiera się na pamięciach podręcznych, jest przydatna, gdy pamięci podręczne mogą być uszkodzone lub niepoprawne z jakiegoś powodu. Dostępne od .NET 7 sdk.
-e|--environment <KEY=VALUE>

Ustawia określoną zmienną środowiskową w procesie, który będzie uruchamiany przez polecenie . Określona zmienna środowiskowa nie jest stosowana do dotnet run procesu.

Zmienne środowiskowe przekazywane przez tę opcję mają pierwszeństwo przed otoczenia zmiennych środowiskowych, dyrektyw System.CommandLine env i environmentVariables z wybranego profilu uruchamiania. Aby uzyskać więcej informacji, zobacz Zmienne środowiskowe.

(Ta opcja została dodana w zestawie SDK .NET 9.0.200).
-f|--framework <FRAMEWORK>

Kompiluje i uruchamia aplikację przy użyciu określonej platformy. Struktura musi być określona w pliku projektu.
--file <FILE_PATH>

Ścieżka do aplikacji opartej na plikach do uruchomienia. Jeśli ścieżka nie jest określona, bieżący katalog jest używany do znajdowania i uruchamiania pliku. Aby uzyskać więcej informacji na temat aplikacji opartych na plikach, zobacz Tworzenie aplikacji w języku C#opartych na plikach.

W systemie Unix wykonaj aplikacje oparte na plikach bezpośrednio przy użyciu nazwy pliku, dodając dyrektywę shebang (#!) i ustawiając uprawnienie do wykonywania. Aby uzyskać więcej informacji, zobacz Obsługa systemu Unix shebang (#!).

Wprowadzono w zestawie .NET SDK 10.0.100.
--force

Wymusza rozwiązanie wszystkich zależności, nawet jeśli ostatnie przywracanie zakończyło się pomyślnie. Określenie tej flagi jest takie samo jak usunięcie pliku project.assets.json .
--interactive

Umożliwia zatrzymanie polecenia i oczekiwanie na wprowadzenie lub działanie użytkownika. Na przykład w celu ukończenia uwierzytelniania.
-lp|--launch-profile <NAME>

Nazwa profilu uruchamiania do użycia podczas uruchamiania aplikacji. Aby uzyskać więcej informacji, zobacz Uruchamianie profilów.
--no-build

Nie kompiluje projektu przed uruchomieniem. Ponadto niejawnie ustawia flagę --no-restore .
--no-cache

Pomiń aktualne kontrole i zawsze kompiluj program przed uruchomieniem.
--no-dependencies

Podczas przywracania projektu przy użyciu odwołań typu project-to-project (P2P) przywraca projekt główny, a nie odwołania.
--no-launch-profile

Nie próbuje używać launchSettings.json do konfigurowania aplikacji.
--no-restore

Nie wykonuje niejawnego przywracania podczas uruchamiania polecenia.
--no-self-contained

Opublikuj aplikację jako aplikację zależną od platformy. Aby uruchomić aplikację, na maszynie docelowej musi być zainstalowany zgodny środowisko uruchomieniowe .NET.
--os <OS>

Określa docelowy system operacyjny. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --os linux ustawia identyfikator RID na linux-x64wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji . Dostępne od .NET 6.
--project <PATH>

Określa ścieżkę pliku projektu do uruchomienia (nazwa folderu lub pełna ścieżka). Jeśli nie zostanie określony, zostanie on domyślnie określony w bieżącym katalogu.

Skrót -p dla --project jest przestarzały począwszy od zestawu SDK .NET 6. Przez ograniczony czas -p można go nadal używać --project pomimo ostrzeżenia o wycofaniu. Jeśli argument podany dla opcji nie zawiera =parametru , polecenie przyjmuje -p jako skrót .--project W przeciwnym razie polecenie zakłada, że -p jest to skrót od --property. To elastyczne użycie -p dla --project zostanie wycofane w .NET 7.
--property:<NAME>=<VALUE>

Ustawia co najmniej jedną właściwości programu MSBuild. Określ wiele właściwości rozdzielonych średnikami lub powtarzając opcję:
```
--property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
```
Krótki formularz -p może być używany dla elementu --property. Jeśli argument podany dla opcji zawiera =, -p jest akceptowany jako krótki dla --property. W przeciwnym razie polecenie zakłada, że -p jest to skrót od --project.

Aby przekazać --property do aplikacji, a nie ustawić właściwości MSBuild, podaj opcję po separatorze -- składni, na przykład:
```
dotnet run -- --property name=value
```
-r|--runtime <RUNTIME_IDENTIFIER>

Określa docelowe środowisko uruchomieniowe, dla których mają być przywracane pakiety. Aby uzyskać listę identyfikatorów środowiska uruchomieniowego (RID), zobacz wykaz identyfikatorów RID.
--sc|--self-contained

Opublikuj środowisko uruchomieniowe .NET w aplikacji, aby środowisko uruchomieniowe nie musi być zainstalowane na maszynie docelowej.
--tl:[auto|on|off]

Określa, czy rejestrator terminalu ma być używany dla danych wyjściowych kompilacji. Wartość domyślna to auto, która najpierw weryfikuje środowisko przed włączeniem rejestrowania terminalu. Sprawdzanie środowiska sprawdza, czy terminal może korzystać z nowoczesnych funkcji wyjściowych i nie używa przekierowanych standardowych danych wyjściowych przed włączeniem nowego rejestratora. on Pomija sprawdzanie środowiska i włącza rejestrowanie terminalu. off Pomija sprawdzanie środowiska i używa domyślnego rejestratora konsoli.

Rejestrator terminalu pokazuje fazę przywracania, po której następuje faza kompilacji. W każdej fazie obecnie projekty budowlane są wyświetlane w dolnej części terminalu. Każdy projekt, który tworzy, generuje dane wyjściowe zarówno docelowy programu MSBuild, który jest obecnie kompilowany, jak i ilość czasu spędzonego na tym obiekcie docelowym. Możesz wyszukać te informacje, aby dowiedzieć się więcej o kompilacji. Po zakończeniu kompilowania projektu zostanie napisana pojedyncza sekcja "ukończona kompilacja", która przechwytuje:
- Nazwa utworzonego projektu.
- Struktura docelowa (jeśli jest przeznaczona dla wielu celów).
- Stan tej kompilacji.
- Podstawowe dane wyjściowe tej kompilacji (która jest hiperlinkowana).
- Każda diagnostyka wygenerowana dla tego projektu.
Ta opcja jest dostępna od .NET 8.
-v|--verbosity <LEVEL>

Ustawia poziom szczegółowości polecenia. Dozwolone wartości to q[uiet], , m[inimal]n[ormal], d[etailed], i diag[nostic]. Wartość domyślna to minimal. Aby uzyskać więcej informacji, zobacz LoggerVerbosity.
-?|-h|--help

Wyświetla opis sposobu używania polecenia .

Zmienne środowiskowe

Następujące źródła stosują zmienne środowiskowe do uruchomionej aplikacji:

Otoczenia zmiennych środowiskowych z systemu operacyjnego po uruchomieniu polecenia.
Dyrektywy System.CommandLine env , takie jak [env:key=value]. Dotyczą one całego dotnet run procesu, a nie tylko projektu uruchamianego przez dotnet runprogram .
Wartości wygenerowane na podstawie wybranego profilu uruchamiania. dotnet run zestawy , DOTNET_LAUNCH_PROFILEi applicationUrl w zestawach Project profilów ASPNETCORE_URLS.
environmentVariables z wybranego profilu uruchamiania, jeśli istnieje. Dotyczą one projektu uruchamianego przez dotnet runprogram .
-e|--environment wartości opcji interfejsu wiersza polecenia (dodane w zestawie SDK .NET w wersji 9.0.200). Dotyczą one projektu uruchamianego przez dotnet runprogram .

Środowisko jest konstruowane w tej samej kolejności co ta lista, więc -e|--environment opcja ma najwyższy priorytet.

Przykłady

Uruchom projekt w bieżącym katalogu:
```
dotnet run
```
Uruchom określoną aplikację opartą na plikach w bieżącym katalogu:
```
dotnet run --file ConsoleApp.cs
```
Dodano obsługę aplikacji opartych na plikach w zestawie SDK .NET 10.0.100.

Uruchom określony projekt:

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

Uruchom projekt w bieżącym katalogu, określając konfigurację wydania:
```
dotnet run --property:Configuration=Release
```
Uruchom projekt w bieżącym katalogu ( --help argument w tym przykładzie jest przekazywany do aplikacji, ponieważ jest używana pusta -- opcja):
```
dotnet run --configuration Release -- --help
```
Przywróć zależności i narzędzia dla projektu w bieżącym katalogu tylko z minimalnymi danymi wyjściowymi, a następnie uruchom projekt:
```
dotnet run --verbosity m
```
Uruchom projekt w bieżącym katalogu przy użyciu określonej platformy i przekaż argumenty do aplikacji:
```
dotnet run -f net6.0 -- arg1 arg2
```
W poniższym przykładzie do aplikacji są przekazywane trzy argumenty. Jeden argument jest przekazywany przy użyciu metody -, a dwa argumenty są przekazywane po --:
```
dotnet run -f net6.0 -arg1 -- arg2 arg3
```

Opinia

Czy ta strona była pomocna?

Last updated on 2026-09-08