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"-resurser
• dotnet restore säkerhetsgranskning
• Templatemotor
• 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.

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 kompilationsutdata. Denna Terminal Logger grupperar fel tillsammans med projektet de tillhör, skiljer bättre mellan olika målapparatsramar för projekt med flera mål, och ger realtidsinformation om vad byggprocessen 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 sökvägar för olika byggartifakter. 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 uppgifter 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 arbetslaster för det körande .NET SDK-funktionsbandet och tidigare versioner.

dotnet publish och dotnet pack tillgångar

Eftersom dotnet publish och dotnet pack-kommandona är avsedda att skapa produktionsresurser, skapar de nu Release-resurser 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 omfattar:

• 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 new tillhandahåll information om mallpaketets ägare. Ägarskapet verifieras av NuGet-portalen och kan betraktas som en tillförlitlig egenskap.

• För dotnet search och dotnet uninstall anger du om en mall är installerad från ett paket som är "pålitligt", det vill säga 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.

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. Vid fristående distribution kommer detta paketerade körningspaket att refereras, vilket aktiverar funktionen för användarna.

Inbyggd AOT-konsolappmall

Standardmallen för konsolappen innehåller nu stöd för AOT out-of-the-box. Om du vill skapa ett projekt som är konfigurerat för AOT-kompilering, kör bara dotnet new console --aot. 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.

.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 bygga .NET från källkod, men det krävdes att du skapade ett "källkodspaket" från dotnet/installer-lagringsplatsen som motsvarade en utgåva. 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 dotnet-buildtools/prereqs containeravbildningarna 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.

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

• Nyheter i .NET 8