Läs på engelska

Dela via

Nyheter i SDK och verktyg för .NET 8

  • Artikel

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

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 publishoch 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 restorevisas 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 installoch dotnet 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 newanger du information om mallpaketets ägare. Ägarskapet verifieras av NuGet-portalen och kan betraktas som en tillförlitlig egenskap.

  • För dotnet search och dotnet uninstallanger du om en mall är installerad från ett paket som är "betrott", dvs. det använder ett reserverat prefix.

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.

Anteckning

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 --aotdu 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, Counteller 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.

Se även