dotnet build
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 publish
och 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 tillwin-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 (viaTargetFrameworks
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 tilllinux-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]
ochdiag[nostic]
. Standardvärdet ärminimal
. 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ärbarRuntimeIdentifier
plattform baserat på en av dina datorer. Detta sker implicit med egenskaper som kräver enRuntimeIdentifier
, till exempelSelfContained
,PublishAot
,PublishSelfContained
,PublishSingleFile
ochPublishReadyToRun
. 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
-p
alternativet MSBuild:dotnet build -p:Version=1.2.3.4