dotnet build

  • Artikel

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

Name

dotnet build – Skapar ett projekt och alla dess beroenden.

Sammanfattning

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

dotnet build -h|--help

beskrivning

Kommandot dotnet build skapar projektet 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, om projekttypen är en körbar fil för .NET Core 3.0 eller senare.
  • 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 tidigare versioner än .NET Core 3.0 kopieras vanligtvis inte biblioteksberoenden från NuGet till utdatamappen. De löses från nuget-mappen globala paket vid körning. Med det i åtanke är produkten av dotnet build inte redo att överföras till en annan dator för körning. Om du vill skapa en version av programmet som kan distribueras måste du publicera det (till exempel med kommandot dotnet publish ). Mer information finns i Distribution av .NET-program.

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, så det 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 .

Kommentar

När dotnet build körs automatiskt av dotnet run, respekteras inte argument som -property:property=value inte.

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

Projektet eller lösningsfilen som ska skapas. Om ett projekt eller en lösningsfil inte har angetts söker MSBuild i den aktuella arbetskatalogen efter en fil som har ett filnamnstillägg som slutar i antingen proj eller sln och använder filen.

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.

  • -?|-h|--help

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

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

    Publicerar programmet som ett ramverksberoende program. En kompatibel .NET-körning måste vara installerad på måldatorn för att köra programmet. Tillgänglig sedan .NET 6 SDK.

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

  • --self-contained [true|false]

    Publicerar .NET-körningen med programmet så att körningen inte behöver installeras på måldatorn. Standardvärdet är true om en körningsidentifierare har angetts. Tillgänglig sedan .NET 6.

  • --source <SOURCE>

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

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

    Anger om terminalloggaren 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.

    Terminalloggaren 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. Som standard visar MSBuild varningar och fel på alla utförliga nivåer. Om du vill undanta varningar använder du /property:WarningLevel=0. Mer information finns i LoggerVerbosity och WarningLevel.

  • --use-current-runtime, --ucr [true|false]

    RuntimeIdentifier Anger till en bärbar RuntimeIdentifier plattform baserat på en av dina datorer. Detta sker implicit med egenskaper som kräver en RuntimeIdentifier, till exempel SelfContained, PublishAot, PublishSelfContained, PublishSingleFileoch PublishReadyToRun. Om egenskapen är inställd på false sker inte längre den implicita lösningen.

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

Exempel

  • Skapa ett projekt och dess beroenden:

    dotnet build

  • 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