dotnet build

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

Name

dotnet build – Skapar ett projekt, en lösning eller en filbaserad app och alla dess beroenden.

Sammanfattning

dotnet build [<PROJECT>|<SOLUTION>|<FILE>] [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--no-dependencies] [--no-incremental] [--no-restore] [--nologo]
    [--no-self-contained] [-o|--output <OUTPUT_DIRECTORY>] [--os <OS>]
    [-p|--property:<PROPERTYNAME>=<VALUE>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained] [--source <SOURCE>]
    [--tl:[auto|on|off]] [ --ucr|--use-current-runtime]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet build -h|--help

beskrivning

Kommandot dotnet build skapar projektet, lösningen eller den filbaserade appen och dess beroenden i en uppsättning binärfiler. Binärfilerna innehåller projektets kod i IL-filer (Intermediate Language) med ett .dll-tillägg . Beroende på projekttyp och inställningar kan andra filer inkluderas, till exempel:

• En körbar fil som kan användas för att köra programmet.
• Symbolfiler som används för felsökning med ett .pdb-tillägg .
• En .deps.json fil som visar beroenden för programmet eller biblioteket.
• En .runtimeconfig.json fil som anger den delade körningen och dess version för ett program.
• Andra bibliotek som projektet är beroende av (via projektreferenser eller NuGet-paketreferenser).

För körbara projekt som riktar sig till .NET Core 3.0 och senare kopieras biblioteksberoenden till utdatamappen. Det innebär att om det inte finns någon annan publiceringsspecifik logik (till exempel webbprojekt har), bör byggutdata vara distribuerade.

Implicit återställning

För att skapa krävs project.assets.json-filen, som visar programmets beroenden. Filen skapas när dotnet restore den körs. Utan tillgångsfilen på plats kan verktygen inte matcha referenssammansättningar, vilket resulterar i fel.

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 kontinuerliga integreringsversioner i Azure DevOps Services eller i byggsystem som uttryckligen behöver 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.

Körbara eller biblioteksutdata

Om projektet kan köras eller inte bestäms av <OutputType> egenskapen i projektfilen. I följande exempel visas ett projekt som producerar körbar kod:

<PropertyGroup>
  <OutputType>Exe</OutputType>
</PropertyGroup>

Om du vill skapa ett bibliotek utelämnar du <OutputType> egenskapen eller ändrar dess värde till Library. IL DLL för ett bibliotek innehåller inte startpunkter och kan inte köras.

MSBuild

dotnet build använder MSBuild för att skapa projektet, lösningen eller den filbaserade appen. Den stöder både parallella och inkrementella versioner. Mer information finns i Inkrementella versioner.

Förutom dess alternativ dotnet build accepterar kommandot MSBuild-alternativ, till exempel -p för att ange egenskaper eller -l för att definiera en logger. Mer information om de här alternativen finns i kommandoradsreferensen MSBuild. Du kan också använda kommandot dotnet msbuild .

Körning dotnet build motsvarar körning dotnet msbuild -restore. Standardverositeten för utdata är dock annorlunda.

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.

Argument

PROJECT | SOLUTION | FILE

Projektet eller lösningen eller C#-filen (filbaserad app) som ska användas. Om en fil inte har angetts söker MSBuild i den aktuella katalogen efter ett projekt eller en lösning.

• PROJECT är sökvägen och filnamnet för en C#-, F#- eller Visual Basic-projektfil eller sökvägen till en katalog som innehåller en C#-, F#- eller Visual Basic-projektfil.

• SOLUTION är sökvägen och filnamnet för en lösningsfil (.sln eller .slnx- filnamnstillägg) eller sökvägen till en katalog som innehåller en lösningsfil.

• FILE är ett argument som lagts till i .NET 10. Sökvägen och filnamnet för en filbaserad app. Filbaserade appar finns i en enda fil som skapas och körs utan motsvarande projektfil (.csproj). Mer information finns i Skapa filbaserade C#-appar.

Alternativ

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

• -f|--framework <FRAMEWORK>

  Kompilerar för ett specifikt ramverk. Ramverket måste definieras i projektfilen. Exempel: net7.0, net462.

• --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. Tillgänglig sedan .NET Core 3.0 SDK.

• --no-dependencies

  Ignorerar P2P-referenser (project-to-project) och skapar endast det angivna rotprojektet.

• --no-incremental

  Markerar bygget som osäkert för inkrementell version. Den här flaggan inaktiverar inkrementell kompilering och tvingar fram en ren återskapande av projektets beroendediagram.

• --no-restore

  Kör inte en implicit återställning under bygget.

• --nologo

  Visar inte startbanderollen eller upphovsrättsmeddelandet.

• --no-self-contained

  Motsvarar --self-contained false.

• -o|--output <OUTPUT_DIRECTORY>

  Katalog där du vill placera de skapade binärfilerna. Om det inte anges är ./bin/<configuration>/<framework>/standardsökvägen . För projekt med flera målramverk (via TargetFrameworks egenskapen) måste du också definiera --framework när du anger det här alternativet.

  • .NET 7.0.200 SDK och senare

    Om du anger --output alternativet när du kör det här kommandot på en lösning genererar CLI en varning (ett fel i 7.0.200) på grund av den oklara semantiken i utdatasökvägen. Alternativet --output är inte tillåtet eftersom alla utdata från alla inbyggda projekt kopieras till den angivna katalogen, som inte är kompatibel med flera målprojekt, samt projekt som har olika versioner av direkta och transitiva beroenden. Mer information finns i Alternativet på lösningsnivå --output är inte längre giltigt för build-relaterade kommandon.

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

• -p|--property:<PROPERTYNAME>=<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>
  

• -r|--runtime <RUNTIME_IDENTIFIER>

  Anger målkörningen. En lista över Runtime-identifierare (RID) finns i RID-katalogen. Om du använder det här alternativet med .NET 6 SDK använder --self-contained du eller --no-self-contained också. Om det inte anges är standardvärdet att skapa för det aktuella operativsystemet och arkitekturen.

• --sc|--self-contained

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

• --source <SOURCE>

  URI:n för NuGet-paketkällan som ska användas under återställningsåtgärden.

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

• --ucr|--use-current-runtime

  Använd den aktuella körningen som målkörning.

• -v|--verbosity <LEVEL>

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

• --version-suffix <VERSION_SUFFIX>

  Anger värdet för egenskapen som $(VersionSuffix) ska användas när projektet skapas. Detta fungerar bara om egenskapen $(Version) inte har angetts. $(Version) Sedan anges till kombinerad $(VersionPrefix) med , avgränsad med $(VersionSuffix)ett bindestreck.

• -?|-h|--help

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

Exempel

• Skapa ett projekt och dess beroenden:

  dotnet build
  

• Skapa en filbaserad app:

  dotnet build MyProject.cs
  

  Filbaserat appstöd har lagts till i .NET SDK 10.0.100.

• Skapa ett projekt och dess beroenden med hjälp av versionskonfiguration:

  dotnet build --configuration Release
  

• Skapa ett projekt och dess beroenden för en viss körning (i det här exemplet Linux):

  dotnet build --runtime linux-x64
  

• Skapa projektet och använd den angivna NuGet-paketkällan under återställningsåtgärden:

  dotnet build --source c:\packages\mypackages
  

• Skapa projektet och ange version 1.2.3.4 som en byggparameter med hjälp av -palternativet MSBuild:

  dotnet build -p:Version=1.2.3.4