dotnet-körning

Den här artikeln gäller för: ✔️ .NET 6 SDK och senare versioner

Name

dotnet run – Kör källkod utan några explicita kompilerings- eller startkommandon.

Sammanfattning

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

beskrivning

Kommandot dotnet run ger ett praktiskt alternativ för att köra programmet från källkoden med ett kommando. Det är användbart för snabb iterativ utveckling från kommandoraden. Kommandot är beroende av kommandot dotnet build för att skapa koden. Alla krav för bygget gäller även för dotnet run .

Utdatafiler skrivs till standardplatsen, som är bin/<configuration>/<target>. Om du till exempel har ett netcoreapp2.1 program och kör dotnet runplaceras utdata i bin/Debug/netcoreapp2.1. Filer skrivs över efter behov. Temporära filer placeras i obj katalogen.

Om projektet anger flera ramverk resulterar körningen dotnet run i ett fel om inte -f|--framework <FRAMEWORK> alternativet används för att ange ramverket.

Kommandot dotnet run används i kontexten för projekt, inte i byggda sammansättningar. Om du försöker köra en ramverksberoende program-DLL i stället måste du använda dotnet utan kommando. Om du till exempel vill köra myapp.dllanvänder du:

dotnet myapp.dll

Mer information om drivrutinen dotnet finns i .NET CLI-översikt.

För att köra programmet dotnet run löser kommandot beroendena för programmet som ligger utanför den delade körningen från NuGet-cachen. Eftersom den använder cachelagrade beroenden rekommenderar vi inte att du använder dotnet run för att köra program i produktion. Skapa i stället en distribution med kommandot dotnet publish och distribuera de publicerade utdata.

Implicit återställning

Du behöver inte köra dotnet restore eftersom den körs implicit av alla kommandon som kräver en återställning, till exempel dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishoch dotnet pack. Om du vill inaktivera implicit återställning använder du alternativet --no-restore .

Kommandot dotnet restore är fortfarande användbart i vissa scenarier där det är meningsfullt att uttryckligen återställa, till exempel kontinuerlig integrering i Azure DevOps Services eller i byggsystem som uttryckligen måste styra när återställningen sker.

Information om hur du hanterar NuGet-feeds finns i dokumentationendotnet restore.

Det här kommandot stöder alternativen dotnet restore när det skickas i det långa formuläret (till exempel --source). Korta formuläralternativ, till exempel -s, stöds inte.

Nedladdningar av arbetsbelastningsmanifest

När du kör det här kommandot initieras en asynkron bakgrundsnedladdning av annonseringsmanifest för arbetsbelastningar. Om nedladdningen fortfarande körs när det här kommandot är klart stoppas nedladdningen. Mer information finns i Annonseringsmanifest.

Starta profiler

Starta profiler konfigurerar hur dotnet run startar en app under utvecklingen. För ett SDK-projekt placerar du inställningarna i Properties/launchSettings.json. Visual Basic projekt används My Project/launchSettings.json i stället.

Filbaserade appar kan använda en [ApplicationName].run.json fil bredvid källfilen. Information om ordningen och exemplen på filsökning finns i Starta profiler för filbaserade appar.

Startinställningsfilen innehåller ett objekt på den översta nivån profiles . Varje egenskap i profiles definierar en namngiven profil:

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

Parsern .NET SDK-startinställningar accepterar JSON-kommentarer och avslutande kommatecken.

Välj en profil

Använd --launch-profile <NAME> för att välja en namngiven profil. Namnmatchningen är skiftlägeskänslig. Profilnamn som endast skiljer sig åt från fall till fall är tvetydiga och ger upphov till ett fel.

Om du inte anger något namn dotnet run väljer du den första profilen i filordningen vars commandName den stöder. Använd --no-launch-profile för att hoppa över startinställningsfilen.

När dotnet run en profil tillämpas ställs den in DOTNET_LAUNCH_PROFILE på det valda profilnamnet i den startade processen. En senare miljövariabelkälla kan åsidosätta värdet.

Profiltyper som stöds

.NET SDK stöder dessa commandName värden för dotnet run. Värdena är skiftlägeskänsliga.

commandName Behavior
Project Skapar projektet och startar kommandot som skapas av projektet.
Executable Startar kommandot som anges av executablePath. Om du inte anger --no-buildskapar dotnet run fortfarande projektet först.

Gemensamma egenskaper

dotnet run identifierar dessa egenskaper för båda profiltyperna som stöds:

dotnet run expanderar miljövariabelreferenser %NAME% i strängvärden som stöds. I .NET 11 och senare versioner expanderar den även MSBuild-egenskapsreferenser i värden som används för att starta processen med samma tokenersättning som Visual Studio. Den expanderar inte gränssnittsreferenser $NAME .

Property Behavior
commandLineArgs Anger argument för den startade processen. Explicita programargument på kommandoraden har företräde. För en Project profil har argument som anges av project också företräde.
environmentVariables Anger miljövariabler för den startade processen. Profilvärden åsidosätter ärvda och SDK-genererade miljövariabler och -e\|--environment värden åsidosätter profilvärden.
dotnetRunMessages När trueskriver ut Building... innan dotnet run projektet byggs. Standardvärdet är false. Den här egenskapen styr inte meddelandet som identifierar startinställningsfilen.

Använd environmentVariables för att tillämpa konfigurationsinställningar för utvecklingstidskörning som har ett miljövariabelformulär. En profil kan till exempel ange GC-inställningar som DOTNET_gcServer. Tillgängliga inställningar, miljövariabelnamn och prioritetsregler finns i .NET inställningar för körningskonfiguration och Körningskonfigurationsalternativ för skräpinsamling.

Alla körningsinställningar har inte ett miljövariabelformulär. Om du vill konfigurera en app oberoende av startprofilen använder du en MSBuild-egenskap eller RuntimeHostConfigurationOption ett objekt i projektet eller använder en runtimeconfig.template.json fil. Vissa inställningar kan också ändras i kod med AppContext.SetSwitch. Dessa mekanismer skapar eller ändrar appens körningskonfiguration. de är inte ytterligare launchSettings.json egenskaper.

Project Egenskaper

dotnet run identifierar dessa ytterligare egenskaper när commandName är Project:

Property Behavior
applicationUrl Uppsättningar ASPNETCORE_URLS i den startade processen. Ett ASPNETCORE_URLS värde i environmentVariables eller från -e\|--environment har företräde.
launchBrowser Talar om för startverktyget om du vill öppna en webbläsare. dotnet run Behåller den här egenskapen i den parsade profilen men öppnar inte en webbläsare.
launchUrl Anger vilken URL som ska öppnas för startverktyget. dotnet run Behåller den här egenskapen i den parsade profilen men öppnar inte en webbläsare eller använder URL:en.

Beteendet applicationUrl stöder ASP.NET Core, men startprofiler och andra vanliga egenskaper gäller för alla körbara SDK-format .NET projekt.

Executable Egenskaper

dotnet run identifierar dessa ytterligare egenskaper när commandName är Executable:

Property Behavior
executablePath Required. Anger vilken process som ska startas. SDK:t expanderar variabelreferenser som stöds, men det löser inte ett relativt värde mot startinställningsfilen. Använd en absolut sökväg eller ett kommando som operativsystemet kan hitta.
workingDirectory Optional. Anger arbetskatalogen för den startade processen. SDK:et expanderar variabelreferenser som stöds och löser en relativ sökväg mot katalogen som innehåller filen med startinställningar. Om du utelämnar egenskapen är arbetskatalogen som standard den katalog som innehåller projektet eller den filbaserade appen.

Visual Studio- och felsökningstillägg

launchSettings.json är ett delat indataformat, men varje konsument bestämmer vilka värden som ska stödjas och hur de ska tolkas. Visual Studio, felsökningsprogram och andra verktyg kan identifiera fler commandName värden och egenskaper än dotnet run.

I följande tabell jämförs dotnet run kontraktet med det vanliga .NET projektsystembeteendet i Visual Studio:

Miljö eller beteende dotnet run Visual Studio
Profiltyper som stöds Stöder Project och Executable. Stöder Project, Executableoch en tom commandName. Installerade projektsystemtillägg kan lägga till andra profiltyper.
Variabelexpansion Expanderar miljövariabelreferenser %NAME% . I .NET 11 och senare versioner expanderar även MSBuild-egenskapsreferenser i värden som används för att starta processen. Expanderar miljövariabler och MSBuild-egenskaper i executablePath, commandLineArgs, workingDirectory, launchUrlmiljövariabelvärden och strängvärdestilläggsinställningar.
commandLineArgs för Project Använder profilvärdet endast när projektet inte tillhandahåller körningsargument och du inte skickar programargument på kommandoraden. Lägger till profilvärdet i körningsargumenten från projektet.
workingDirectory för Project Ignorerar egenskapen. Stöder egenskapen. En relativ sökväg är relativ till projektkatalogen.
workingDirectory för Executable En relativ sökväg är relativ till katalogen som innehåller startinställningsfilen. Om den utelämnas är sökvägen som standard för projektet eller den filbaserade appkatalogen. En relativ sökväg är relativ till projektkatalogen. Om den utelämnas används sökvägen som standard i utdatakatalogen när katalogen finns eller till projektkatalogen på annat sätt.
Relativ executablePath Skickar värdet till operativsystemet utan att göra det på nytt. Löser ett värde med sökvägskomponenter från profilens arbetskatalog. För ett namn utan körbar fil kontrollerar Visual Studio sin egen aktuella katalog och sedan PATH.
launchBrowser och launchUrl Behåller värdena i den parsade profilen men öppnar inte en webbläsare. Gör värdena tillgängliga för en startprovider. Till exempel kan ASP.NET Core verktyg öppna en webbläsare.
applicationUrl Anger ASPNETCORE_URLS. Gör värdet tillgängligt för installerade startproviders, till exempel ASP.NET Core verktyg.
dotnetRunMessages Styr meddelandet Building... . Använder inte egenskapen för att styra Visual Studio utdata.
Felsökningsegenskaper Ignorerar felsökningsspecifika egenskaper. Använder egenskaper som nativeDebugging, sqlDebugging, jsWebView2Debugging, remoteDebugEnabledoch hotReloadEnabled när projektet och felsökningsprogrammet stöder funktionen.

I .NET 11 och senare versioner expanderar "$(ProjectDir)"båda konsumenterna . I tidigare versioner identifierar inget enskilt workingDirectory värde projektkatalogen för båda konsumenterna. Visual Studio expanderar "$(ProjectDir)", medan dotnet run behandlar den som literaltext och löser relativa sökvägar från katalogen som innehåller filen med startinställningar. Använd ".." därför för dotnet run med en konventionell Properties/launchSettings.json fil eller My Project/launchSettings.json fil. Visual Studio löser samma värde som den överordnade projektkatalogen.

Windows Forms och WPF appar lägger inte till någon annan dotnet run profiltyp. Använd en Project profil med vanliga inställningar som commandLineArgs och environmentVariables. I Visual Studio kan dessa typer av skrivbordsprojekt också använda tillämpliga felsökningsegenskaper, till exempel nativeDebugging för blandad hanterad och intern felsökning eller jsWebView2Debugging för WebView2. Webbläsar- och URL-egenskaper har bara en effekt när en startprovider eller programmet använder dem.

Andra projekttyper och Visual Studio arbetsbelastningar kan installera startprovidrar som lägger till profiltyper eller tolkar extra egenskaper. Dessa tillägg lägger inte till stöd för dotnet run: CLI hoppar över profiltyper som inte stöds under standardvalet och rapporterar ett fel när du väljer en explicit.

Information om Visual Studio felsökningsinställningar som stöds och project användargränssnitt finns i Project inställningar för en felsökningskonfiguration för .NET C#.

Arguments

<applicationArguments>

Argument som skickas till det program som körs.

Argument som inte känns igen av dotnet run skickas till programmet. Om du vill separera argument för dotnet run från argument för programmet använder du alternativet -- .

Vidarebefordra argument till programmet

dotnet run vidarebefordrar en token som den inte känner igen till programmet. De vidarebefordrade token behåller sin ursprungliga ordning, men dotnet run tar först bort de alternativ som den förstår. När ett identifierat alternativ visas mellan ett okänt alternativnamn och dess värde kan borttagning av det identifierade alternativet ändra innebörden av de överblivna token.

Följande kommando mellanläser till exempel det identifierade alternativet --project mellan token som programmet är avsett att ta emot:

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

Efter dotnet run användning --project ConsoleApp.csprojtar programmet emot --app-flag --app-name A.txt. Programmet behandlar A.txt sedan som värdet --app-name, som inte matchar den ursprungliga kommandoraden.

Undvik den här tvetydigheten genom att placera programargument efter en literal --:

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

Avgränsaren -- markerar varje följande token som ett programargument, så dotnet run ändra inte ordning på eller omtolka dem. Avgränsaren framtidssäkrar även skript mot nya dotnet run alternativ som senare kan matcha en token som tidigare vidarebefordrats till programmet.

Note

Samma beteende gäller för dotnet build och för dotnet test i Microsoft. Testing.Platform (MTP)-läge, som vidarebefordrar okända token till MSBuild eller till testprogrammet. Mer information om dotnet testfinns i Vidarebefordra argument till testprogrammet.

Alternativ

  • --

    Avgränsar argument till dotnet run från argument för programmet som körs. Alla argument efter att den här avgränsare har skickats till programkörningen.

  • -a|--arch <ARCHITECTURE>

    Anger målarkitekturen. Det här är en kortsyntax för att ange Körtidsidentifierare (RID) där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du --arch x86 till exempel RID till win-x86. Om du använder det här alternativet ska du inte använda alternativet -r|--runtime . Tillgänglig sedan .NET 6 Förhandsversion 7.

  • --artifacts-path <ARTIFACTS_DIR>

    Alla build-utdatafiler från det körda kommandot kommer att gå i undermappar under den angivna sökvägen, avgränsade med projekt. Mer information finns i Artefaktutdatalayout. Det här alternativet och det angivna värdet måste uttryckligen överlappas i alla dotnet kommandon som är beroende av utdata från ett annat dotnet kommando, till exempel när du använder dotnet build --no-restore och dotnet publish --no-build. Tillgänglig sedan .NET 8 SDK.

  • -c|--configuration <CONFIGURATION>

    Definierar byggkonfigurationen. Standardvärdet för de flesta projekt är Debug, men du kan åsidosätta konfigurationsinställningarna för bygget i projektet.

  • --disable-build-servers

    Tvingar kommandot att ignorera alla beständiga byggservrar. Det här alternativet är ett konsekvent sätt att inaktivera all användning av cachelagring av versioner, vilket tvingar fram en version från grunden. En version som inte förlitar sig på cacheminnen är användbar när cacheminnena kan vara skadade eller felaktiga av någon anledning. Tillgänglig sedan .NET 7 SDK.

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

    Anger den angivna miljövariabeln i den process som ska köras av kommandot. Den angivna miljövariabeln tillämpas inte på dotnet run processen.

    Miljövariabler som skickas via det här alternativet har företräde framför miljövariabler, System.CommandLine-direktiv env och environmentVariables från den valda startprofilen. Mer information finns i Miljövariabler.

    (Det här alternativet lades till i .NET SDK 9.0.200.)

  • -f|--framework <FRAMEWORK>

    Skapar och kör appen med det angivna ramverket. Ramverket måste anges i projektfilen.

  • --file <FILE_PATH>

    Sökvägen till den filbaserade app som ska köras. Om en sökväg inte har angetts används den aktuella katalogen för att hitta och köra filen. Mer information om filbaserade appar finns i Skapa filbaserade C#-appar.

    På Unix kör du filbaserade appar direkt med filnamnet genom att lägga till ett shebang-direktiv (#!) och ange körningsbehörigheten. Mer information finns i Stöd för Unix shebang (#!).

    Introducerades i .NET SDK 10.0.100.

  • --force

    Tvingar alla beroenden att lösas även om den senaste återställningen lyckades. Att ange den här flaggan är detsamma som att ta bort project.assets.json-filen.

  • --interactive

    Tillåter att kommandot stoppar och väntar på användarens indata eller åtgärd. Till exempel för att slutföra autentiseringen.

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

    Namnet på den startprofil som ska användas när programmet startas. Mer information finns i Starta profiler.

  • --no-build

    Skapar inte projektet innan det körs. Den anger --no-restore också implicit flaggan.

  • --no-cache

    Hoppa över uppdaterade kontroller och skapa alltid programmet innan du kör det.

  • --no-dependencies

    När du återställer ett projekt med P2P-referenser (project-to-project) återställer rotprojektet och inte referenserna.

  • --no-launch-profile

    Försöker inte använda launchSettings.json för att konfigurera programmet.

  • --no-restore

    Kör inte en implicit återställning när kommandot körs.

  • --no-self-contained

    Publicera ditt program som ett ramverksberoende program. En kompatibel .NET körning måste vara installerad på måldatorn för att köra programmet.

  • --os <OS>

    Anger måloperativsystemet (OS). Det här är en kortsyntax för att ange Körtidsidentifierare (RID) där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du --os linux till exempel RID till linux-x64. Om du använder det här alternativet ska du inte använda alternativet -r|--runtime . Tillgänglig sedan .NET 6.

  • --project <PATH>

    Anger sökvägen till projektfilen som ska köras (mappnamn eller fullständig sökväg). Om det inte anges används den aktuella katalogen som standard.

    Förkortningen -p för --project är inaktuell från och med .NET 6 SDK. Under en begränsad tid -p kan fortfarande användas för --project trots utfasningsvarningen. Om argumentet som anges för alternativet inte innehåller =accepterar -p kommandot som en förkortning för --project. Annars förutsätter kommandot att det -p är en förkortning för --property. Den här flexibla användningen av -p för --project fasas ut i .NET 7.

  • --property:<NAME>=<VALUE>

    Anger en eller flera MSBuild-egenskaper. Ange flera egenskaper avgränsade med semikolon eller genom att upprepa alternativet:

    --property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

    Det korta formuläret -p kan användas för --property. Om argumentet som anges för alternativet innehåller , accepteras =-p som en förkortning för --property. Annars förutsätter kommandot att det -p är en förkortning för --project.

    Om du vill skicka --property till programmet i stället för att ange en MSBuild-egenskap anger du alternativet efter -- syntaxavgränsaren, till exempel:

    dotnet run -- --property name=value

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Anger den målkörning som paketen ska återställas för. En lista över Runtime-identifierare (RID) finns i RID-katalogen.

  • --sc|--self-contained

    Publicera .NET-körningen med ditt program så att körningen inte behöver installeras på måldatorn.

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

    Anger om Terminal Logger ska användas för byggutdata. Standardvärdet är auto, som först verifierar miljön innan du aktiverar terminalloggning. Miljökontrollen verifierar att terminalen kan använda moderna utdatafunktioner och inte använder en omdirigerad standardutdata innan den nya loggaren aktiveras. on hoppar över miljökontrollen och aktiverar terminalloggning. off hoppar över miljökontrollen och använder standardkonsolloggaren.

    TerminalLogger visar återställningsfasen följt av byggfasen. Under varje fas visas de pågående byggprojekten längst ned i terminalen. Varje projekt som skapar utdata både det MSBuild-mål som för närvarande skapas och hur lång tid som spenderas på det målet. Du kan söka efter den här informationen om du vill veta mer om bygget. När ett projekt är färdigt skrivs ett enda "build completed"-avsnitt som samlar in:

    • Namnet på det skapade projektet.
    • Målramverket (om det är flera mål).
    • Status för bygget.
    • Den primära utdatan för den versionen (som är hyperlänkad).
    • Diagnostik som genereras för projektet.

    Det här alternativet är tillgängligt från och med .NET 8.

  • -v|--verbosity <LEVEL>

    Anger kommandots verbositetsnivå. Tillåtna värden är q[uiet], m[inimal], n[ormal], d[etailed]och diag[nostic]. Standardvärdet är minimal. Mer information finns i LoggerVerbosity.

  • -?|-h|--help

    Skriver ut en beskrivning av hur du använder kommandot.

Miljövariabler

Följande källor tillämpar miljövariabler på det lanserade programmet:

  1. Miljövariabler från operativsystemet när kommandot körs.
  2. System.CommandLine-direktiv env , till exempel [env:key=value]. Dessa gäller för hela dotnet run processen, inte bara det projekt som körs av dotnet run.
  3. Värden som genereras från den valda startprofilen. dotnet runanger DOTNET_LAUNCH_PROFILEoch applicationUrl i en Project profiluppsättning .ASPNETCORE_URLS
  4. environmentVariables från den valda startprofilen, om någon. Dessa gäller för projektet som körs av dotnet run.
  5. -e|--environment CLI-alternativvärden (läggs till i .NET SDK version 9.0.200). Dessa gäller för projektet som körs av dotnet run.

Miljön är konstruerad i samma ordning som den -e|--environment här listan, så alternativet har högsta prioritet.

Exempel

  • Kör projektet i den aktuella katalogen:

    dotnet run

  • Kör den angivna filbaserade appen i den aktuella katalogen:

    dotnet run --file ConsoleApp.cs

    Filbaserat appstöd lades till i .NET SDK 10.0.100.

  • Kör det angivna projektet:

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

  • Kör projektet i den aktuella katalogen och ange Versionskonfiguration:

    dotnet run --property:Configuration=Release

  • Kör projektet i den aktuella katalogen ( --help argumentet i det här exemplet skickas till programmet eftersom det tomma -- alternativet används):

    dotnet run --configuration Release -- --help

  • Återställ beroenden och verktyg för projektet i den aktuella katalogen som bara visar minimala utdata och kör sedan projektet:

    dotnet run --verbosity m

  • Kör projektet i den aktuella katalogen med det angivna ramverket och skicka argument till programmet:

    dotnet run -f net6.0 -- arg1 arg2

    I följande exempel skickas tre argument till programmet. Ett argument skickas med , -och två argument skickas efter --:

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