Wat is er nieuw in de SDK en hulpprogramma's voor .NET 11

In dit artikel worden nieuwe functies en verbeteringen in de .NET SDK voor .NET 11 beschreven. Het is voor het laatst bijgewerkt voor Preview 6. U kunt hier .NET 11 downloaden.

omvang van de SDK

De .NET SDK-installatiegrootte in Linux en macOS is verminderd door assembly's te ontdubbelen met behulp van symbolische koppelingen. Duplicaten .dll en .exe bestanden worden geïdentificeerd door inhoudshash en vervangen door symbolische koppelingen die verwijzen naar één kopie. Dit is van invloed op tarballs, .pkg, .deb, en .rpm installateurs.

Analyse heeft vastgesteld dat 35% van de SDK-map bestaat uit dubbele bestanden. Op Linux x64 zijn dat 816 bestanden die in totaal 140 MB op schijf (53 MB gecomprimeerd) zijn. Door duplicaten te vervangen door symbolische koppelingen, wordt het Linux x64-archief aanzienlijk kleiner:

Platform SDK-artefact .NET 10 grootte (MB) .NET 11 Preview 2 grootte (MB) Vermindering
linux-x64 Tarball 230 189 17,8%
linux-x64 Deb 164 122 25.6%
linux-x64 Rpm 165 122 26.0%
linux-x64 Containers Varies Varies 8-17%

De SDK wordt verder ingekort omdat crossgen wordt overgeslagen voor assembly's die alleen bestaan onder DotnetTools/. Assemblies die ook buiten DotnetTools/ bestaan, worden nog steeds met crossgen verwerkt: ze krijgen het opstartvoordeel en het duplicaat wordt vervolgens verwijderd, maar assemblies die uniek zijn voor DotnetTools/ blijven alleen als IL over. Op een linux-x64 build vermindert dit de SDK-tarball met een extra 23,6 MB.

Windows ontdubbeling is gepland voor een toekomstige preview.

Codeanalyse en waarschuwingen

Verbeteringen in codeanalyse

CA1873: Minder ruis en verbeterde berichten

Er zijn twee verbeteringen aangebracht in CA1873 (vermijd mogelijk dure logboekregistratie):

Minder fout-positieven: Eigenschapstoegangen, GetType(), GetHashCode(), en GetTimestamp() oproepen worden niet meer gemarkeerd. Diagnostische gegevens zijn nu standaard alleen van toepassing op logboekregistratie op informatieniveau en lager, omdat waarschuwings-, fout- en kritieke codepaden zelden vaak gebruikte paden zijn.

Specifieke redenen in diagnostische berichten: Het diagnostische bericht bevat nu waarom een argument is gemarkeerd, zodat u kunt bepalen welke waarschuwingen moeten worden aangepakt:

// Before
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled

// After
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled (method invocation)

De negen specifieke redenen zijn:

  • Methode-aanroep
  • Aanmaak van objecten
  • Matrix maken
  • Conversie van boksen
  • Tekenreeksinterpolatie
  • Verzamelingsexpressie
  • Anoniem maken van objecten
  • Await-expressie
  • Met expressie

Oplossingen voor analysefouten

Analyzer Repareren
CA1515 Fout-positief opgelost wanneer C#-extensieleden aanwezig zijn
CA1034 Fout-positief opgelost wanneer C#-extensieleden aanwezig zijn
CA1859 Onjuiste verwerking van standaardinterface-implementaties opgelost

AnalysisLevel gecorrigeerd voor .NET 11

Projecten met AnalysisLevel=latest gebruikten ten onrechte .NET 9 analyseregels in plaats van de verwachte .NET 11 regels. Dit is nu opgelost.

Nieuwe SDK-waarschuwingen

NETSDK1235: Aangepaste .nuspec met PackAsTool

Er wordt een nieuwe waarschuwing uitgegeven wanneer een project PackAsTool=true instelt en een aangepaste NuspecFile eigenschap opgeeft. Voor hulpprogrammapakketten zijn specifieke indelings- en id-conventies vereist die aangepaste .nuspec bestanden doorgaans schenden:

warning NETSDK1235: .NET Tools do not support using a custom .nuspec file, but the nuspec file 'custom.nuspec' was provided. Remove the NuspecFile property from this project to enable packing it as a .NET Tool.

Hoewel de packbewerking nog steeds doorgaat, wordt er een waarschuwing gegeven om te voorkomen dat bestaande projecten worden onderbroken.

Productiviteit van CLI-werkstroom en ontwikkelaars

Cli-ondersteuning voor oplossingsfilters

dotnet sln kan nu oplossingsfilters (.slnf) rechtstreeks vanuit de CLI maken en bewerken. Met oplossingsfilters kunnen grote opslagplaatsen een subset van projecten laden of bouwen zonder de hoofdoplossing te wijzigen. De ondersteunde bewerkingen spiegelen de bestaande dotnet sln opdrachten:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet sln MyApp.slnf list
dotnet sln MyApp.slnf remove src/Lib/Lib.csproj

Bestandsgebaseerde apps die over bestanden zijn verdeeld

Op bestanden gebaseerde apps ondersteunen nu een #:include richtlijn, zodat u gedeelde helpers kunt verplaatsen naar afzonderlijke bestanden zonder dat u de werkstroom op basis van bestanden hoeft op te geven:

#:include helpers.cs
#:include models/customer.cs

Console.WriteLine(Helpers.FormatOutput(new Customer()));

Omgevingsvariabelen doorgeven met dotnet-uitvoering

dotnet run -e KEY=VALUE geeft omgevingsvariabelen vanaf de opdrachtregel door aan de gestarte app, zonder dat u shellstatus hoeft te exporteren of startprofielen te bewerken:

dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e LOG_LEVEL=Debug

Omgevingsvariabelen die op deze manier worden doorgegeven, zijn beschikbaar voor MSBuild-logica als RuntimeEnvironmentVariable items.

Verbeteringen in dotnet watch

.NET 11 voegt verschillende dotnet watch verbeteringen toe voor langlopende lokale ontwikkelcycli:

  • Aspire integratie:dotnet watch kan nu worden geïntegreerd met Aspire app-hosts, waardoor werkstromen voor dynamisch opnieuw laden in het volledige Aspire toepassingsmodel mogelijk zijn.
  • Crashherstel: Wanneer de app vastloopt, dotnet watch wordt deze automatisch opnieuw gestart bij de volgende relevante bestandswijziging.
  • Windows bureaubladondersteuning: Ctrl+C-verwerking is verbeterd voor Windows bureaublad-apps, zoals Windows Forms en WPF.

.NET 11 voegt ook apparaatselectie toe voor MAUI- en mobiele projecten. Nadat u een doelframework hebt gekozen, wordt het dotnet watch MSBuild-target ComputeAvailableDevices aangeroepen, wordt automatisch geselecteerd wanneer er maar één apparaat is en wordt een interactieve kiezer met zoekfunctie weergegeven wanneer er meerdere zijn. Het gekozen apparaat wordt doorgegeven aan dotnet build en het gestarte dotnet run-subproces, inclusief een nieuwe herstelbewerking wanneer het apparaat een RuntimeIdentifier vereist die niet aanwezig was in het oorspronkelijke herstel.

Als u een apparaat vooraf wilt selecteren vanaf de opdrachtregel, gebruikt u:

dotnet watch --device <device-id>

De volgende langdurige dotnet watch problemen zijn opgelost:

  • De prompt voor frameworkselectie lijkt niet langer vast te lopen doordat twee readers beide Console.ReadKey() aanroepen.
  • Ctrl+C en Ctrl+R geven niet langer onterecht een WebSocketException of ObjectDisposedException weer wanneer het WebSocket-transport wegvalt.
  • Hot Reload loopt niet langer vast op iOS wanneer UIKitSynchronizationContext is geïnstalleerd voordat de startuphook wordt uitgevoerd.

Note

dotnet watch vereist <MtouchLink>None</MtouchLink> in het .csproj bestand voor iOS Simulator-projecten. Zie dotnet/macios #25295.

Aanvullingen voor de Fish-shell

De provider voor de fish-shell genereerde eerder een one-liner die elke aanvulling delegeerde naar een dynamische aanroep van dotnet complete. Het gegenereerde script doorloopt nu de getokeniseerde opdrachtregel, genereert statische aanvullingen voor subopdrachten, opties en positionele argumenten, en valt alleen waar nodig terug op dynamische aanroepen. Dit komt overeen met het gedrag van de Bash-, Zsh- en PowerShell-providers.

dotnet-verwijzing valt terug naar de huidige map

dotnet reference add en dotnet reference remove vallen nu terug op de huidige map wanneer er geen --project is opgegeven, overeenkomstig het al lang bestaande gedrag van dotnet reference list:

cd ClassLib2
dotnet reference add ../ClassLib1/ClassLib1.csproj   # now works without --project
dotnet reference remove ../ClassLib1/ClassLib1.csproj

Voorheen zijn deze opdrachten mislukt wanneer Could not find project or directory '' ze worden uitgevoerd vanuit een map met een projectbestand.

De melding over startinstellingen is verplaatst naar stderr

Het informatiebericht 'Opstartinstellingen gebruiken van...' wordt nu naar stderr geschreven in plaats van naar stdout. Scripts die de standaarduitvoer van dotnet run vastleggen, hoeven deze regel niet langer te verwijderen.

Andere CLI-verbeteringen

  • dotnet format accepteert --framework nu voor projecten met meerdere doelgroepen.
  • dotnet test in de MTP-modus (Microsoft Testing Platform) ondersteunt nu --artifacts-path.
  • dotnet tool exec en dnx vragen niet langer om extra toestemming bij het uitvoeren van tools.
  • dotnet nuget <subcommand> --help wordt nu correct doorgestuurd naar de helpuitvoer van de NuGet-CLI in plaats van terug te vallen op algemene help.
  • dotnet publish verwijdert geen systeemeigen DLL's meer bij latere uitvoeringen van publiceren met één bestand.

Webassets en telemetrie

Assetgroepen voor statische webassets

De Static Web Assets SDK voegt ondersteuning toe voor assetgroepen, een manier om groepen gerelateerde assets te declareren die publiceren, vingerafdrukken en eindpuntmetagegevens delen. De gerelateerde DefineStaticWebAssetEndpoints taak krijgt een AdditionalEndpointDefinitions parameter en de glob-matcher maakt de vastgelegde ** stengel zichtbaar, zodat extra eindpunten (bijvoorbeeld standaarddocumentroutes zoals / voor **/index.html) declaratief kunnen worden gedefinieerd.

Dit is een infrastructuur voor ASP.NET Core auteurs van onderdelen en SDK-extensies. De meeste app-ontwikkelaars zien het resultaat indirect als Razor- en Blazor-onderdeelpakketten verzenden schonere metagegevens van statische activa.

OpenTelemetry vervangt Application Insights voor CLI-telemetrie

De dotnet CLI maakt nu gebruik van OpenTelemetry (OTel) met Azure Monitor en OTLP-exporteurs voor de opt-in-telemetrie, waarbij de vorige Microsoft.ApplicationInsights-afhankelijkheid wordt vervangen. Het gebruikersgerichte gedrag is ongewijzigd: dezelfde telemetrie wordt verzameld met dezelfde opt-out via DOTNET_CLI_TELEMETRY_OPTOUT. De motivatie is om de CLI NativeAOT-vriendelijk te maken.

CLI-architectuur

NativeAOT-toegangspunt voor de dotnet CLI

Om nagenoeg onmiddellijk opstarten voor veelgebruikte CLI-aanroepen mogelijk te maken, legt .NET 11 de basis voor een met NativeAOT gecompileerde dotnet CLI-host. Eerdere previews verpakten de NativeAOT-bibliotheek dotnet-aot en beperkte deze achter DOTNET_CLI_ENABLEAOT=true. Preview 6 handhaaft het gedrag dat standaard is uitgeschakeld, maar voegt de managed- en NativeAOT-CLI-parsers samen in één gedeelde implementatie, waardoor het snelle AOT-pad nu --help parseert, valideert en rendert voor elk commando, en niet alleen voor de kleine subset die het eerder afhandelde.

Opdrachten die volledig kunnen worden uitgevoerd zonder de beheerde runtime, worden systeemeigen uitgevoerd. Elke andere opdracht valt transparant terug op de beheerde CLI. In preview 6 worden de volgende opdrachten volledig uitgevoerd vanuit het AOT-pad:

  • dotnet --version, dotnet --info, dotnet --help
  • dotnet <command> --help voor elke ingebouwde opdracht
  • dotnet --cli-schema
  • dotnet sln list, dotnet sln migrate, dotnet sln remove

Aanroepen van hulpprogramma's en externe opdrachten (globale hulpprogramma's, PATH-opdrachten, app-base-opdrachten) worden nu ook via het AOT-pad gevonden en in een afzonderlijk proces gestart, waarbij de opstarttijd van 600–700 ms van de beheerde CLI wordt overgeslagen voor opdrachten zoals dotnet ef of dotnet dev-certs.

OpenTelemetry-tracingspans worden vanuit het AOT-pad uitgestuurd met de juiste ouder-/kindrelaties ten opzichte van de beheerde CLI-spans, waardoor end-to-end-analyse van gedistribueerde traces over beide hosts heen mogelijk is.

Gedeeltelijk gereed-om-uit-te-voeren voor upstack-tooling

Met een nieuwe MSBuild-eigenschap kunnen hogerliggende hulpprogramma's (bijvoorbeeld dotnet/macios en dotnet/maui) een lijst met assemblies opgeven die gedeeltelijk als R2R worden gecompileerd en van de samengestelde image worden uitgesloten. Het motiverende scenario is het vooraf compileren van gegenereerde XAML-code in builds voor foutopsporing om F5 te versnellen zonder de volledige crossgenkosten voor de rest van de app te betalen. App-ontwikkelaars stellen deze eigenschap niet rechtstreeks in—het is een aanknopingspunt dat de mobiele workloads in hun doelconfiguraties gebruiken.

Verbeteringen testen

dotnet-testverbeteringen

Preview 6 voegt verschillende mogelijkheden toe bij dotnet test het uitvoeren van Microsoft Testing Platform (MTP):

  • --no-dependencies: Slaat het maken van project-naar-project-referenties over, in overeenstemming met het bestaande gedrag van dotnet build --no-dependencies.
  • DOTNET_TEST_RUNNER omgevingsvariabele: selecteert de testloper zonder dat hiervoor een global.json wijziging is vereist. Stel deze in op VSTest of Microsoft.Testing.Platform om global.json voor de huidige sessie te overschrijven.
  • --use-current-runtime / --ucr: Is gericht op de huidige runtime tijdens het herstellen en bouwen, die overeenkomt met de optie die al beschikbaar is op dotnet build en dotnet publish.
  • --test-modules uitsluitingspatronen: patronen die beginnen met ! worden nu behandeld als uitsluitingen en witruimte tussen puntkomma's wordt ingekort, waardoor YAML-gevouwen CI-expressies correct werken.
  • Testaantallen per assembly: De samenvattingsregel voor uitvoeringen met meerdere assembly’s bevat nu testaantallen per assembly.
  • Terminalloggerargumenten: --tl, --terminalloggeren --tlp worden nu doorgestuurd naar MSBuild in plaats van als testtoepassingargumenten te worden doorgegeven.
  • Liveweergave van tests in vlucht: het voortgangsgebied toont tests die worden uitgevoerd, met behulp van een nieuwe TestInProgressMessages IPC-gebeurtenis. Het paneel behoudt per-assembly trimming voor grote parallelle runs en wordt alleen ingeschakeld voor interactieve ANSI-terminals.
  • Ctrl+C-onderbreking in twee stappen: de eerste keer stopt het plannen van nieuwe test-apps en wordt er een hint getoond; de tweede keer worden alle onderliggende testprocessen geforceerd beëindigd.
  • --device voor MAUI: Selecteer een apparaat per doelframework bij het uitvoeren van tests voor .NET MAUI projecten.
  • Protocol 1.1.0-uitvoer doorsturen: wanneer de testhost protocol 1.1.0 ondersteunt, worden stdout/stderr en IOutputDevice berichten live gestreamd via de terminalrapporter in plaats van alleen te worden weergegeven bij fouten.

Testsjablonen ondersteunen xUnit v3 en NUnit op Microsoft. Testing.Platform

Met de ingebouwde xunit sjabloon wordt een --xunit-version optie toegevoegd. Gebruik v3 om een xUnit v3-project te genereren dat standaard Microsoft.Testing.Platform als runner gebruikt:

dotnet new xunit --xunit-version v3
dotnet new xunit --xunit-version v3 --test-runner VSTest

De nunit-sjabloon voegt op vergelijkbare wijze een --test-runner-optie toe om te kiezen voor Microsoft.Testing.Platform:

dotnet new nunit --test-runner Microsoft.Testing.Platform

Beide opties zijn beschikbaar voor C#-, F#- en VB-sjablonen.

Updates voor containers en tools

Multi-arch containerbuilds met Podman

De ingebouwde containerpublicatie van de SDK biedt nu ondersteuning voor het bouwen van containerinstallatiekopieën met meerdere architectuur bij het gebruik van Podman als containerengine. Voorheen vereisten multi-arch builds Docker. Hierdoor worden rootloze multi-arch-werkstromen op Linux-distributies die Podman standaard verzenden, gedeblokkeerd.

TypeScript-uitvoer kan worden geïntegreerd met Static Web Assets

Projecten die Microsoft.TypeScript.MSBuild gebruiken in Razor Class Libraries, worden nu correct geïntegreerd met de uitvoer van de TypeScript-compilatie en ASP.NET Core Static Web Assets. De nieuwe integratie integreert de TypeScript-uitvoer na compilatie in de pijplijn voor Static Web Assets, waardoor compressie, fingerprinting en correct gedrag bij opnieuw opbouwen mogelijk worden. Voorheen konden rebuildbewerkingen mislukken omdat TypeScript-uitvoer werd gevonden vóór de compilatie of verouderde verwijzingen na het opschonen bleven bestaan.

Omgevingsvariabelen MSBuild-server en OpenTelemetry

De dotnet CLI onderdrukt de MSBuild-buildserver niet meer wanneer DOTNET_CLI_USE_MSBUILD_SERVER deze niet is ingesteld. Voorheen schreef de CLI onvoorwaardelijk MSBUILDUSESERVER=0, en overschreef daarmee een door de gebruiker ingestelde waarde. Als DOTNET_CLI_USE_MSBUILD_SERVER niet is ingesteld, laat de CLI MSBUILDUSESERVER ongewijzigd, zodat u de MSBuild-server rechtstreeks kunt inschakelen.

De OTLP-telemetrieexporteur is nu ook ingeschakeld wanneer er een standaard omgevingsvariabele van OpenTelemetry OTEL_EXPORTER_OTLP_* aanwezig is (eindpunt, protocol, headers of time-out, inclusief signaalspecifieke _TRACES_* en _METRICS_* varianten), naast de bestaande DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER vlag.

DLL's opnemen in op bestanden gebaseerde apps

Bestandsgebaseerde apps kunnen nu gecompileerde DLL-verwijzingen opnemen met #:include zonder featureflag. De standaardtoewijzing van het itemtype behandelt .dll bestanden als Reference items, zodat u rechtstreeks naar vooraf gemaakte bibliotheken kunt verwijzen:

#:include ./libs/MyLibrary.dll

MyLibrary.Helper.DoWork();

Daarnaast kunnen er nu meer #: richtlijnen worden weergegeven als duplicaten in opgenomen bestanden wanneer hun waarden overeenkomen (#:sdk, #:property, #:package), waardoor zelfstandige bibliotheekbestanden kunnen worden ingeschakeld die hun eigen afhankelijkheden declareren zonder conflicteren wanneer meerdere toegangspunten deze bevatten.

Zie ook

  • Last updated on