Nyheter i SDK och verktyg för .NET 8
I den här artikeln beskrivs nya funktioner i .NET SDK och verktyg för .NET 8.
SDK
Det här avsnittet innehåller följande underavsnitt:
- CLI-baserad projektutvärdering
- Utdata för terminalbygge
- Förenklade utdatasökvägar
- Kommandot "dotnet workload clean" (rensa arbetsbelastning i dotnet)
- "dotnet publish" och "dotnet pack"-tillgångar
- Mallmotor
- Källlänk
- SDK för källbygge
CLI-baserad projektutvärdering
MSBuild innehåller en ny funktion som gör det enklare att införliva data från MSBuild i dina skript eller verktyg. Följande nya flaggor är tillgängliga för CLI-kommandon som dotnet publish för att hämta data för användning i CI-pipelines och på andra platser.
Flagga | beskrivning |
---|---|
--getProperty:<PROPERTYNAME> |
Hämtar egenskapen MSBuild med det angivna namnet. |
--getItem:<ITEMTYPE> |
Hämtar MSBuild-objekt av den angivna typen. |
--getTargetResults:<TARGETNAME> |
Hämtar utdata från att köra det angivna målet. |
Värden skrivs till standardutdata. Flera eller komplexa värden matas ut som JSON, enligt följande exempel.
>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\
>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
"Properties": {
"GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
"GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
}
}
>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
"Items": {
"ContainerImageTags": [
{
"Identity": "latest",
...
]
}
}
Utdata för terminalbygge
dotnet build
har ett nytt alternativ för att skapa mer moderniserade byggutdata. Den här terminalloggaren utdatagrupper fel med projektet de kom från, bättre skiljer de olika målramverken för flera målprojekt och ger realtidsinformation om vad bygget gör. Om du vill välja de nya utdata använder du alternativet --tl
. Mer information om det här alternativet finns i dotnet-byggalternativ.
Förenklade utdatasökvägar
.NET 8 introducerar ett alternativ för att förenkla utdatasökvägen och mappstrukturen för byggutdata. Tidigare skapade .NET-appar en djup och komplex uppsättning utdatasökvägar för olika byggartefakter. Den nya förenklade utdatasökvägsstrukturen samlar alla byggutdata till en gemensam plats, vilket gör det enklare för verktyg att förutse.
Mer information finns i Artefaktutdatalayout.
dotnet workload clean
kommando`
.NET 8 introducerar ett nytt kommando för att rensa arbetsbelastningspaket som kan lämnas över via flera .NET SDK- eller Visual Studio-uppdateringar. Om du stöter på problem när du hanterar arbetsbelastningar bör du överväga att använda workload clean
för att återställa till ett känt tillstånd på ett säkert sätt innan du försöker igen. Kommandot har två lägen:
dotnet workload clean
Kör skräpinsamling för arbetsbelastningar för filbaserade eller MSI-baserade arbetsbelastningar, vilket rensar överblivna paket. Överblivna paket kommer från avinstallerade versioner av .NET SDK eller paket där installationsposter för paketet inte längre finns.
Om Visual Studio är installerat visar kommandot även alla arbetsbelastningar som du bör rensa manuellt med Hjälp av Visual Studio.
dotnet workload clean --all
Det här läget är mer aggressivt och rensar varje paket på datorn som är av den aktuella installationstypen för SDK-arbetsbelastningen (och det är inte från Visual Studio). Den tar också bort alla installationsposter för arbetsbelastningar för det .NET SDK-funktionsband som körs och nedan.
dotnet publish
och dotnet pack
tillgångar
dotnet publish
Eftersom kommandona och dotnet pack
är avsedda att producera produktionstillgångar skapar Release
de nu tillgångar som standard.
Följande utdata visar det olika beteendet mellan dotnet build
och dotnet publish
och hur du kan återgå till att publicera Debug
tillgångar genom att ange PublishRelease
egenskapen till false
.
/app# dotnet new console
/app# dotnet build
app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
app -> /app/bin/Release/net8.0/app.dll
app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
app -> /app/bin/Debug/net8.0/app.dll
app -> /app/bin/Debug/net8.0/publish/
Mer information finns i "dotnet pack" använder Versionskonfiguration och "dotnet publish" använder Versionskonfiguration.
dotnet restore
säkerhetsgranskning
Från och med .NET 8 kan du välja säkerhetskontroller för kända säkerhetsrisker när beroendepaket återställs. Den här granskningsåtgärden genererar en rapport över säkerhetsrisker med det berörda paketnamnet, sårbarhetens allvarlighetsgrad och en länk till rekommendationen för mer information. När du kör dotnet add
eller dotnet restore
visas varningar nu1901-NU1904 för eventuella säkerhetsrisker som hittas. Mer information finns i Granskning av säkerhetsrisker.
Mallmotor
Mallmotorn ger en säkrare upplevelse i .NET 8 genom att integrera några av NuGets säkerhetsrelaterade funktioner. Förbättringarna innefattar:
Förhindra att paket laddas ned från
http://
feeds som standard. Följande kommando kan till exempel inte installera mallpaketet eftersom käll-URL:en inte använder HTTPS.dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"
Du kan åsidosätta den här begränsningen
--force
med hjälp av flaggan.För
dotnet new
,dotnet new install
ochdotnet new update
, kontrollerar du om det finns kända säkerhetsrisker i mallpaketet. Om säkerhetsrisker hittas och du vill fortsätta måste du använda--force
flaggan.För
dotnet new
anger du information om mallpaketets ägare. Ägarskapet verifieras av NuGet-portalen och kan betraktas som en tillförlitlig egenskap.För
dotnet search
ochdotnet uninstall
anger du om en mall är installerad från ett paket som är "betrott", dvs. det använder ett reserverat prefix.
Källlänk
Source Link ingår nu i .NET SDK. Målet är att genom att paketera Source Link i SDK:t, i stället för att kräva en separat <PackageReference>
för paketet, innehåller fler paket den här informationen som standard. Den informationen förbättrar IDE-upplevelsen för utvecklare.
Kommentar
Som en bieffekt av den här ändringen ingår incheckningsinformation i InformationalVersion
värdet för inbyggda bibliotek och program, även de som riktar sig mot .NET 7 eller en tidigare version. Mer information finns i Källlänk som ingår i .NET SDK.
SDK för källbygge
Linux-distributionsbyggda SDK :et (source-build) har nu möjlighet att skapa fristående program med hjälp av källversionskörningspaketen. Det distributionsspecifika körningspaketet paketeras med källversionens SDK. Under den fristående distributionen refereras det här paketerade körningspaketet till, vilket aktiverar funktionen för användare.
Internt AOT-stöd
Alternativet att publicera som intern AOT introducerades först i .NET 7. När du publicerar en app med intern AOT skapas en helt fristående version av din app som inte behöver någon körning – allt ingår i en enda fil. .NET 8 ger följande förbättringar av intern AOT-publicering:
Lägger till stöd för x64- och Arm64-arkitekturerna i macOS.
Minskar storleken på interna AOT-appar i Linux med upp till 50 %. I följande tabell visas storleken på en "Hello World"-app som publicerats med intern AOT som innehåller hela .NET-körningen på .NET 7 jämfört med .NET 8:
Operativsystem .NET 7 .NET 8 Linux x64 (med -p:StripSymbols=true
)3,76 MB 1,84 MB Windows x64 2,85 MB 1,77 MB Gör att du kan ange en optimeringsinställning: storlek eller hastighet. Som standard väljer kompilatorn att generera snabb kod samtidigt som den är medveten om programmets storlek. Du kan dock använda
<OptimizationPreference>
egenskapen MSBuild för att optimera specifikt för den ena eller den andra. Mer information finns i Optimera AOT-distributioner.
Mall för konsolapp
Standardmallen för konsolappen innehåller nu stöd för AOT out-of-the-box. Om du vill skapa ett projekt som har konfigurerats för AOT-kompilering kör dotnet new console --aot
du bara . Projektkonfigurationen som läggs till av --aot
har tre effekter:
- Genererar en intern fristående körbar fil med intern AOT när du publicerar projektet, till exempel med
dotnet publish
eller Visual Studio. - Aktiverar kompatibilitetsanalysverktyg för trimning, AOT och enskild fil. Dessa analysverktyg varnar dig för potentiellt problematiska delar av projektet (om det finns några).
- Aktiverar felsökningstidsemulering av AOT så att du får en liknande upplevelse som AOT när du felsöker projektet utan AOT-kompilering. Om du till exempel använder System.Reflection.Emit i ett NuGet-paket som inte har kommenterats för AOT (och därför missades av kompatibilitetsanalysatorn) innebär emuleringen att du inte får några överraskningar när du försöker publicera projektet med AOT.
Rikta in dig på iOS-liknande plattformar med inbyggd AOT
.NET 8 startar arbetet med att aktivera internt AOT-stöd för iOS-liknande plattformar. Nu kan du skapa och köra .NET iOS- och .NET MAUI-program med intern AOT på följande plattformar:
ios
iossimulator
maccatalyst
tvos
tvossimulator
Preliminära tester visar att appstorleken på disken minskar med cirka 35 % för .NET iOS-appar som använder intern AOT i stället för Mono. Appstorleken på disken för .NET MAUI iOS-appar minskar med upp till 50 %. Dessutom är starttiden också snabbare. .NET iOS-appar har ungefär 28 % snabbare starttid, medan .NET MAUI iOS-appar har ungefär 50 % bättre startprestanda jämfört med Mono. .NET 8-stödet är experimentellt och bara det första steget för funktionen som helhet. Mer information finns i blogginlägget om prestandaförbättringar för .NET 8 i .NET MAUI.
Inbyggt AOT-stöd är tillgängligt som en opt-in-funktion som är avsedd för appdistribution. Mono är fortfarande standardkörningen för apputveckling och distribution. Om du vill skapa och köra ett .NET MAUI-program med intern AOT på en iOS-enhet använder du dotnet workload install maui
för att installera .NET MAUI-arbetsbelastningen och dotnet new maui -n HelloMaui
för att skapa appen. Ange sedan egenskapen PublishAot
MSBuild till true
i projektfilen.
<PropertyGroup>
<PublishAot>true</PublishAot>
</PropertyGroup>
När du anger den obligatoriska egenskapen och kör dotnet publish
som i följande exempel distribueras appen med hjälp av intern AOT.
dotnet publish -f net8.0-ios -c Release -r ios-arm64 /t:Run
Begränsningar
Alla iOS-funktioner är inte kompatibla med intern AOT. På samma sätt är inte alla bibliotek som ofta används i iOS kompatibla med NativeAOT. Utöver de befintliga begränsningarna för intern AOT-distribution visar följande lista några av de andra begränsningarna när du riktar in dig på iOS-liknande plattformar:
- Användning av intern AOT aktiveras endast under appdistribution (
dotnet publish
). - Felsökning av hanterad kod stöds endast med Mono.
- Kompatibiliteten med .NET MAUI-ramverket är begränsad.
AOT-kompilering för Android-appar
För att minska appstorleken använder .NET- och .NET MAUI-appar som riktar sig mot Android profilerat i förväg (AOT) kompileringsläge när de är inbyggda i versionsläge. Profilerad AOT-kompilering påverkar färre metoder än vanlig AOT-kompilering. .NET 8 introducerar egenskapen <AndroidStripILAfterAOT>
där du kan välja ytterligare AOT-kompilering för Android-appar för att minska appstorleken ännu mer.
<PropertyGroup>
<AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>
Som standard åsidosätter inställningen AndroidStripILAfterAOT
true
standardinställningen AndroidEnableProfiledAot
så att (nästan) alla metoder som AOT-kompilerats kan trimmas. Du kan också använda profilerad AOT- och IL-borttagning genom att uttryckligen ange båda egenskaperna till true
:
<PropertyGroup>
<AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
<AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>
Korsbyggda Windows-appar
När du skapar appar som riktar in sig på Windows på icke-Windows-plattformar uppdateras den resulterande körbara filen nu med alla angivna Win32-resurser, till exempel programikon, manifest, versionsinformation.
Tidigare var program tvungna att byggas på Windows för att ha sådana resurser. Att åtgärda den här klyftan i stöd för korsbyggande har varit en populär begäran, eftersom det var en betydande smärtpunkt som påverkade både infrastrukturkomplexitet och resursanvändning.
.NET på Linux
Lägsta stödbaslinjer för Linux
De minsta stödbaslinjerna för Linux har uppdaterats för .NET 8. .NET har skapats för Ubuntu 16.04 för alla arkitekturer. Det är främst viktigt för att definiera den lägsta glibc
versionen för .NET 8. .NET 8 startar inte på distributionsversioner som innehåller en äldre glibc, till exempel Ubuntu 14.04 eller Red Hat Enterprise Linux 7.
Mer information finns i Stöd för Red Hat Enterprise Linux-familjen.
Skapa din egen .NET på Linux
I tidigare .NET-versioner kunde du skapa .NET från källan, men det krävdes att du skapade en "källtarball" från dotnet/installer-lagringsplatsen som motsvarade en version. I .NET 8 är det inte längre nödvändigt och du kan skapa .NET på Linux direkt från dotnet-/dotnet-lagringsplatsen . Den lagringsplatsen använder dotnet/source-build för att skapa .NET-runtimes, verktyg och SDK:er. Det här är samma version som Red Hat och Canonical använder för att skapa .NET.
Att skapa i en container är den enklaste metoden för de flesta, eftersom containeravbildningarna dotnet-buildtools/prereqs
innehåller alla nödvändiga beroenden. Mer information finns i bygginstruktionerna.
NuGet-signaturverifiering
Från och med .NET 8 verifierar NuGet signerade paket i Linux som standard. NuGet fortsätter även att verifiera signerade paket i Windows.
De flesta användare bör inte märka verifieringen. Men om du har ett befintligt rotcertifikatpaket som finns på /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, kan du se förtroendefel tillsammans med varnings-NU3042.
Du kan avregistrera dig från verifieringen genom att ange miljövariabeln DOTNET_NUGET_SIGNATURE_VERIFICATION
till false
.
Kodanalys
.NET 8 innehåller flera nya kodanalysverktyg och korrigeringar som hjälper dig att kontrollera att du använder .NET-biblioteks-API:er korrekt och effektivt. I följande tabell sammanfattas de nya analysverktygen.
Regel-ID | Kategori | beskrivning |
---|---|---|
CA1856 | Prestanda | Utlöses ConstantExpectedAttribute när attributet inte tillämpas korrekt på en parameter. |
CA1857 | Prestanda | Utlöses när en parameter kommenteras med ConstantExpectedAttribute men det angivna argumentet inte är en konstant. |
CA1858 | Prestanda | För att avgöra om en sträng börjar med ett angivet prefix är det bättre att anropa String.StartsWith än att anropa String.IndexOf och sedan jämföra resultatet med noll. |
CA1859 | Prestanda | Den här regeln rekommenderar att du uppgraderar typen av specifika lokala variabler, fält, egenskaper, metodparametrar och metodreturtyper från gränssnittstyper eller abstrakta typer till konkreta typer när det är möjligt. Användning av konkreta typer leder till kod som genereras av högre kvalitet. |
CA1860 | Prestanda | För att avgöra om en samlingstyp har några element är det bättre att använda Length , Count eller IsEmpty än att anropa Enumerable.Any. |
CA1861 | Prestanda | Konstanta matriser som skickas som argument återanvänds inte när de anropas upprepade gånger, vilket innebär att en ny matris skapas varje gång. För att förbättra prestandan bör du överväga att extrahera matrisen till ett statiskt skrivskyddat fält. |
CA1865-CA1867 | Prestanda | Överlagringen av tecken är en bättre överlagring för en sträng med ett enda tecken. |
CA2021 | Tillförlitlighet | Enumerable.Cast<TResult>(IEnumerable) och Enumerable.OfType<TResult>(IEnumerable) kräver kompatibla typer för att fungera korrekt. Breddning och användardefinierade konverteringar stöds inte med generiska typer. |
CA1510-CA1513 | Underhållsmöjlighet | Throw-hjälpen är enklare och effektivare än ett if block som skapar en ny undantagsinstans. Dessa fyra analysverktyg skapades för följande undantag: ArgumentNullException, ArgumentExceptionoch ArgumentOutOfRangeException ObjectDisposedException. |
Diagnostik
C# Hot Reload har stöd för att ändra generiska filer
Från och med .NET 8 stöder C# Frekvent omläsning ändring av generiska typer och generiska metoder. När du felsöker konsol-, skrivbords-, mobil- eller WebAssembly-program med Visual Studio kan du tillämpa ändringar på allmänna klasser och generiska metoder i C#-kod eller Razor-sidor. Mer information finns i den fullständiga listan över redigeringar som stöds av Roslyn.