Dela via

Nyheter i SDK och verktyg för .NET 9

  • Artikel

Den här artikeln beskriver nya funktioner i .NET SDK och verktyg för .NET 9.

Enhetstestning

I det här avsnittet beskrivs uppdateringar av enhetstestning i .NET 9: köra tester parallellt och utdata från terminalloggningstest.

Köra tester parallellt

I .NET 9 är dotnet test mer fullständigt integrerat med MSBuild. Eftersom MSBuild stöder att bygga parallelltkan du köra tester för samma projekt i olika målramverk parallellt. Som standard begränsar MSBuild antalet parallella processer till antalet processorer på datorn. Du kan också ange en egen gräns med växeln -maxcpucount. Om du vill avregistrera parallelliteten anger du MSBuild-egenskapen TestTfmsInParallel till false.

Testvisning för terminalloggare

Testresultatrapportering för dotnet test stöds nu direkt i MSBuild-terminalloggaren. Du får mer fullständig testrapportering både medan tester körs (visar namnet på testet som körs) och när tester har slutförts (eventuella testfel presenteras på ett bättre sätt).

Mer information om terminalloggaren finns i dotnet build-alternativ.

.NET-verktyget rullar framåt

.NET-verktyg är ramverksberoende appar som du kan installera globalt eller lokalt. Kör sedan med .NET SDK och installerade .NET-körningar. Dessa verktyg, precis som alla .NET-appar, riktar sig till en specifik huvudversion av .NET. Som standard körs inte appar på nyare versioner av .NET. Verktygsförfattare har valt att köra sina verktyg på nyare versioner av .NET-körningen genom att ange egenskapen RollForward MSBuild. Men det gör inte alla verktyg.

Med ett nytt alternativ för dotnet tool install kan användare bestämma hur .NET-verktyg ska köras. När du installerar ett verktyg via dotnet tool installeller när du kör verktyget via dotnet tool run <toolname>kan du ange en ny flagga med namnet --allow-roll-forward. Det här alternativet konfigurerar verktyget med framåtrullningsläge Major. Med det här läget kan verktyget köras på en nyare huvudversion av .NET om den matchande .NET-versionen inte är tillgänglig. Den här funktionen hjälper tidiga användare att använda .NET-verktyg utan att verktygsförfattare behöver ändra någon kod.

Terminalloggare

Terminalloggaren är nu aktiverad som standard och har även förbättrad användbarhet.

Aktiverad som standard

Från och med .NET 9 är standardupplevelsen för alla .NET CLI-kommandon som använder MSBuild terminallogger, den förbättrade loggningsupplevelsen som släpptes i .NET 8. Dessa nya utdata använder funktionerna i moderna terminaler för att tillhandahålla funktioner som:

  • Klickbara länkar
  • Varaktighetstimers för MSBuild-uppgifter
  • Färgkodning av varnings- och felmeddelanden

Utdata är mer komprimerade och användbara än den befintliga MSBuild-konsolloggaren.

Den nya loggaren försöker identifiera automatiskt om den kan användas, men du kan också manuellt styra om terminalloggaren används. Ange kommandoradsalternativet --tl:off för att inaktivera terminallogger för ett specifikt kommando. Om du vill inaktivera terminallogger mer allmänt anger du MSBUILDTERMINALLOGGER miljövariabeln till off.

Den uppsättning kommandon som använder terminallogger som standard är:

  • build
  • clean
  • msbuild
  • pack
  • publish
  • restore
  • test

Användbarhet

Terminalloggaren sammanfattar nu det totala antalet fel och varningar i slutet av en version. Den visar också fel som innehåller radbrytningar. (Mer information om terminalloggaren finns i "dotnet build"-alternativ, särskilt alternativet --tl.)

Tänk på följande projektfil som genererar en varning när projektet skapas:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <Target Name="Error" BeforeTargets="Build">
    <Warning Code="ECLIPSE001" Text="Black Hole Sun, won't you come
  And wash away the rain
    Black Hole Sun, won't you come
      won't you come" />
  </Target>
</Project>

När du kör dotnet build -tl på .NET 8 SDK visas utdata enligt det här stycket. Varje rad i flerradsvarningen är en separat rad med ett fullständigt prefix för felmeddelande i utmatningen, vilket är svårt att läsa. Den slutliga byggsammanfattningen säger också att det fanns varningar, men inte hur många det fanns. Den information som saknas kan göra det svårt att avgöra om en viss version är bättre eller sämre än tidigare versioner.

$ dotnet build -tl
MSBuild version 17.8.5+b5265ef37 for .NET
Restore complete (0.5s)
  multiline-error-example succeeded with warnings (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001: Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:   And wash away the rain
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:     Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:       won't you come
Build succeeded with warnings in 0.9s

När du skapar samma projekt med hjälp av .NET 9 SDK är utdata så här:

> dotnet build -tl
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  multiline-error-example succeeded with 3 warning(s) (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:
      Black Hole Sun, won't you come
        And wash away the rain
          Black Hole Sun, won't you come
            won't you come
Build succeeded with 3 warning(s) in 0.8s

Meddelanderaderna i varningen har inte längre den upprepade projekt- och platsinformation som belamrade visningen. Dessutom visar byggsammanfattningen hur många varningar (och fel, om det finns några) som genererades under bygget.

Om du har feedback om terminalloggaren kan du ange den på MSBuild-lagringsplats.

Snabbare NuGet-beroendematchning för stora lagringsplatser

NuGet-beroendelösaren har setts över för att förbättra prestanda och skalbarhet för alla <PackageReference> projekt. Den nya algoritmen är aktiverad som standard och påskyndar återställningsåtgärderna utan att kompromissa med funktionaliteten, och följer strikt de grundläggande reglerna för beroendematchning.

Om du stöter på problem, till exempel återställningsfel eller oväntade paketversioner, kan du återgå till den äldre lösaren.

MSBuild-skriptanalysverktyg ("BuildChecks")

.NET 9 introducerar en funktion som skyddar mot defekter och regressioner i dina byggskript. Om du vill köra byggkontrollerna lägger du till flaggan /check i alla kommandon som anropar MSBuild. Till exempel skapar dotnet build myapp.sln /checkmyapp-lösningen och kör alla konfigurerade byggkontroller.

.NET 9 SDK innehåller ett litet antal inledande kontroller, till exempel BC0101 och BC0102. En fullständig lista finns i BuildCheck-koder.

När ett problem identifieras skapas en diagnostik i byggutdata för projektet som innehåller problemet.

Mer information finns i designdokumentation.

Matchningsfel för Analyzer

Många användare installerar .NET SDK och Visual Studio i olika takter. Även om den här flexibiliteten är önskvärd kan det leda till problem för verktyg som behöver samarbeta mellan de två miljöerna. Ett exempel på den här typen av verktyg är Roslyn Analyzeers. Analyzer-författare måste koda för specifika versioner av Roslyn, men vilka versioner som är tillgängliga och vilka som används av en viss version är ibland oklart.

Den här typen av versionskonflikt mellan .NET SDK och MSBuild kallas för en osammanhängande SDK. När du är i detta läge kan du se fel som det här:

CSC : varning CS9057: Analysatorsammansättningen '..\dotnet\sdk\8.0.200\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.CodeAnalysis.Razor.Compiler.SourceGenerators.dll' refererar till version ’4.9.0.0’ av kompilatorn, vilket är nyare än den för närvarande körande versionen ’4.8.0.0’.

.NET 9 kan identifiera och justera automatiskt för det här problemscenariot. SDK:ns MSBuild-logik bäddar in den version av MSBuild som den levererades med, och den informationen kan användas för att identifiera när SDK:n körs i en miljö med en annan version. När det händer infogar SDK en implicit nedladdning av ett supportpaket med namnet Microsoft.Net.Sdk.Compilers.Toolset som säkerställer en konsekvent analysupplevelse.

Arbetsbelastningsuppsättningar

arbetsbelastningsuppsättningar är en SDK-funktion som är avsedd att ge användarna mer kontroll över de arbetsbelastningar som de installerar och hur snabba arbetsbelastningarna ändras. I tidigare versioner uppdaterades arbetsbelastningar regelbundet när nya versioner av enskilda arbetsbelastningar släpptes till alla konfigurerade NuGet-feeds. Nu alla av dina arbetsbelastningar behålla en specifik, enskild version tills du gör en explicit uppdateringsgest.

Du kan se vilket läge din SDK-installation är i genom att köra dotnet workload --info:

> dotnet workload --info
Workload version: 9.0.100-manifests.400dd185
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: VS 17.10.35027.167, VS 17.11.35111.106
   Manifest Version:    8.0.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.2\WorkloadManifest.json
   Install Type:              Msi

I det här exemplet är SDK-installationen i manifestläge, där uppdateringar installeras när de är tillgängliga. Om du vill välja det nya läget lägger du till ett --version alternativ i ett dotnet workload install- eller dotnet workload update-kommando. Du kan också uttryckligen styra åtgärdsläget med hjälp av det nya kommandot dotnet workload config:

> dotnet workload config --update-mode workload-set
Successfully updated workload install mode to use workload-set.

Om du behöver ändra tillbaka av någon anledning kan du köra samma kommando med manifests i stället för workload-set. Du kan också använda dotnet workload config --update-mode för att kontrollera det aktuella driftsläget.

Mer information finns i .NET SDK-arbetsbelastningsuppsättningar.

Arbetsbelastningshistorik

.NET SDK-arbetsbelastningar är en integrerad del av .NET MAUI och Blazor WebAssembly. I standardkonfigurationen kan du uppdatera arbetsbelastningar oberoende av varandra när .NET-verktygsförfattare släpper nya versioner. Dessutom installerar .NET SDK-installationer som görs via Visual Studio en parallell uppsättning versioner. Utan att vara försiktig kan arbetsbelastningsinstallationsstatusen för en viss .NET SDK-installation glida över tid, men det har inte funnits något sätt att visualisera den här driften.

För att åtgärda detta lägger .NET 9 till ett nytt dotnet workload history kommando i .NET SDK. dotnet workload history skriver ut en tabell med historiken för arbetsbelastningsinstallationer och ändringar för den aktuella .NET SDK-installationen. Tabellen visar datumet för installationen eller ändringen, kommandot som kördes, de arbetsbelastningar som installerades eller ändrades och relevanta versioner för kommandot. Dessa utdata kan hjälpa dig att förstå avvikelsen i arbetsbelastningsinstallationer över tid och hjälpa dig att fatta välgrundade beslut om vilka arbetsbelastningsversioner som installationen ska ställas in på. Du kan tänka på det som git reflog för arbetsbelastning.

> dotnet workload history

Id  Date                         Command       Workloads                                        Global.json Version  Workload Version
-----------------------------------------------------------------------------------------------------------------------------------------------
1   1/1/0001 12:00:00 AM +00:00  InitialState  android, ios, maccatalyst, maui-windows                               9.0.100-manifests.6d3c8f5d
2   9/4/2024 8:15:33 PM -05:00   install       android, aspire, ios, maccatalyst, maui-windows                       9.0.100-rc.1.24453.3

I det här exemplet installerades SDK:t ursprungligen med arbetsbelastningarna android, ios, maccatalystoch maui-windows. Sedan användes kommandot dotnet workload install aspire --version 9.0.100-rc.1.24453.3 för att installera aspire-arbetsbelastningen och växla till arbetsbelastningsuppsättningsläge. Om du vill återgå till föregående tillstånd kan du använda ID:t från den första kolumnen i historiktabellen, till exempel dotnet workload update --from-history 1.

Behållare

Publiceringsstöd för osäkra register

SDK:ets inbyggda stöd för containerpublicering kan publicera avbildningar till containerregister. Fram till .NET 9 måste dessa register skyddas – för att .NET SDK ska fungera behövde de HTTPS-stöd och giltiga certifikat. Containermotorer kan vanligtvis också konfigureras för att fungera med osäkra register, det vill: register som inte har TLS konfigurerat eller som har TLS konfigurerat med ett ogiltigt certifikat. Det här är ett giltigt användningsfall, men verktygen har inte stöd för det här kommunikationsläget.

Från och med .NET 9 kan SDK kommunicera med osäkra register.

Krav (beroende på din miljö):

  • Konfigurera Docker CLI för att markera ett register som osäkert.
  • Konfigurera Podman för att markera ett register som osäkert.
  • Använd miljövariabeln DOTNET_CONTAINER_INSECURE_REGISTRIES för att skicka en semikolonavgränsad lista över registerdomäner för att behandla som osäkra.

Namngivning av miljövariabel

Miljövariabler som publiceringsverktyg för containrar använder för att styra några av de finare aspekterna av registerkommunikation och säkerhet börjar nu med prefixet DOTNET i stället för SDK. Prefixet SDK kommer att fortsätta att stödjas på kort sikt.

Kodanalys

.NET 9 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
CA1514: Undvik argument med redundant längd Underhållbarhet Ett explicit beräknat längdargument kan vara felbenäget och är onödigt när du skär till slutet av en sträng eller buffert.
CA1515: Överväg att göra offentliga typer interna Underhållsbarhet Typer i en körbar sammansättning ska deklareras som internal.
CA1871: Skicka inte en nullbar struktur till 'ArgumentNullException.ThrowIfNull' Föreställning För bättre prestanda är det bättre att kontrollera egenskapen HasValue och manuellt tilldela ett undantag än att skicka en nullbar struct till ArgumentNullException.ThrowIfNull.
CA1872: Föredrar "Convert.ToHexString" och "Convert.ToHexStringLower" framför anropskedjor baserat på "BitConverter.ToString" Prestanda Använd Convert.ToHexString eller Convert.ToHexStringLower när du kodar byte till en hexadecimal strängrepresentation.
CA2022: Undvik att läsa felaktigt med Stream.Read Tillförlitlighet Ett anrop till Stream.Read kan returnera färre byte än begärt, vilket resulterar i otillförlitlig kod om returvärdet inte är markerat.
CA2262: Ange "MaxResponseHeadersLength" korrekt Användning Egenskapen HttpClientHandler.MaxResponseHeadersLength mäts i kilobyte, inte byte.
CA2263: Föredrar allmän överlagring när typen är känd Användning Allmänna överlagringar är att föredra framför överlagringar som accepterar ett argument av typen System.Type när typen är känd vid kompileringstillfället.
CA2264: Skicka inte ett icke-nullbart värde till "ArgumentNullException.ThrowIfNull" Användning Vissa konstruktioner som icke-nullbara structs (förutom Nullable<T>), nameof()-uttryck och "nya" uttryck är kända för att aldrig vara null, så ArgumentNullException.ThrowIfNull kommer aldrig att utlösas.
CA2265: Jämför inte Span<T> med null eller standard Användning Att jämföra ett intervall med null eller default kanske inte gör det du avsåg. default och null literal konverteras implicit till Span<T>.Empty. Ta bort den redundanta jämförelsen eller gör koden mer explicit med hjälp av IsEmpty.