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

In dit artikel worden nieuwe functies en verbeteringen in de .NET SDK voor .NET 10 beschreven. Het is bijgewerkt voor RC 2.

Verbeteringen van .NET-hulpprogramma's

Platformspecifieke .NET-hulpprogramma's

.NET-hulpprogramma's kunnen nu worden gepubliceerd met ondersteuning voor meerdere RuntimeIdentifiers (RID's) in één pakket. Auteurs van hulpprogramma's kunnen binaire bestanden bundelen voor alle ondersteunde platforms en de .NET CLI selecteert de juiste versie tijdens de installatie of runtime. Dit maakt het ontwerpen en distribueren van hulpprogramma's op meerdere platforms veel eenvoudiger.

Deze verbeterde hulpmiddelen ondersteunen verschillende verpakkingsvariaties:

• Frameworkafhankelijk, platformneutraal (klassieke modus, wordt overal uitgevoerd met .NET 10 geïnstalleerd)
• Frameworkafhankelijk, platformspecifiek (kleiner, geoptimaliseerd voor elk platform)
• Zelfstandig, platformspecifiek (inclusief de runtime, geen .NET-installatie vereist)
• Uitgedund, platformspecifiek (kleiner, knipt ongebruikte code weg)
• Met AOT gecompileerd, platformspecifiek (maximale prestaties en kleinste implementatie)

Deze nieuwe hulpprogramma's werken net als normale gepubliceerde toepassingen, zodat alle publicatieopties die u kunt gebruiken met toepassingen (bijvoorbeeld zelfstandige, ingekorte of AOT) ook van toepassing kunnen zijn op hulpprogramma's.

Eenmalige uitvoering van tools

U kunt nu de dotnet tool exec opdracht gebruiken om een .NET-hulpprogramma uit te voeren zonder dit globaal of lokaal te installeren. Dit is vooral waardevol voor CI/CD of kortstondig gebruik.

dotnet tool exec --source ./artifacts/package/ dotnetsay  "Hello, World!"
Tool package dotnetsay@1.0.0 will be downloaded from source <source>.
Proceed? [y/n] (y): y
  _   _          _   _                __        __                 _       _   _
 | | | |   ___  | | | |   ___         \ \      / /   ___    _ __  | |   __| | | |
 | |_| |  / _ \ | | | |  / _ \         \ \ /\ / /   / _ \  | '__| | |  / _` | | |
 |  _  | |  __/ | | | | | (_) |  _      \ V  V /   | (_) | | |    | | | (_| | |_|
 |_| |_|  \___| |_| |_|  \___/  ( )      \_/\_/     \___/  |_|    |_|  \__,_| (_)
                                |/

Hiermee wordt het opgegeven hulpprogrammapakket in één opdracht gedownload en uitgevoerd. Standaard wordt gebruikers gevraagd om het downloaden te bevestigen als het hulpprogramma nog niet lokaal bestaat. De nieuwste versie van het gekozen hulpprogrammapakket wordt gebruikt, tenzij er een expliciete versie is opgegeven (bijvoorbeeld dotnetsay@0.1.0).

Eenmalige uitvoering van tools werkt naadloos met lokale toolmanifests. Als u een hulpprogramma uitvoert vanaf een locatie die een .config/dotnet-tools.json nabijgelegen locatie bevat, wordt de versie van het hulpprogramma in die configuratie gebruikt in plaats van de meest recente versie die beschikbaar is.

Het nieuwe dnx script voor het uitvoeren van hulpprogramma's

Het dnx script biedt een gestroomlijnde manier om hulpprogramma's uit te voeren. Hiermee worden alle argumenten doorgestuurd naar de dotnet CLI voor verwerking, waardoor het gebruik van hulpprogramma's zo eenvoudig mogelijk is:

dnx dotnetsay "Hello, World!"

De daadwerkelijke implementatie van de dnx opdracht bevindt zich in de dotnet CLI zelf, waardoor het gedrag ervan in de loop van de tijd kan evolueren.

Zie .NET-hulpprogramma's beheren voor meer informatie over het beheren van .NET-hulpprogramma's.

any RuntimeIdentifier gebruiken met platformspecifieke .NET-hulpprogramma's

De platformspecifieke functie voor .NET-hulpprogramma's is ideaal om ervoor te zorgen dat hulpprogramma's zijn geoptimaliseerd voor specifieke platforms die u van tevoren richt. Er zijn echter momenten waarop u niet alle platforms kent waarop u zich wilt richten, of soms leert .NET zelf hoe u een nieuw platform ondersteunt en u wilt dat uw hulpprogramma daar ook kan worden uitgevoerd.

Als u uw hulpprogramma op deze manier wilt laten werken, voegt u de any runtime-id toe aan uw projectbestand:

<PropertyGroup>
  <RuntimeIdentifiers>
       linux-x64;
       linux-arm64;
       macos-arm64;
       win-x64;
       win-arm64;
       any
  </RuntimeIdentifiers>
</PropertyGroup>

Deze RuntimeIdentifier bevindt zich in de hoofdmap van de platformcompatibiliteitscontrole en omdat het ondersteuning declareert voor elk platform, is het hulpprogramma dat wordt verpakt, het meest compatibele type hulpprogramma: een frameworkafhankelijke, platformonafhankelijke .NET DLL, waarvoor een compatibele .NET Runtime moet worden uitgevoerd. Wanneer u een dotnet pack hulpprogramma maakt, ziet u een nieuw pakket voor de any RuntimeIdentifier verschijnen naast het hoofdmanifestpakket en de andere platformspecifieke pakketten.

CLI-introspectie met --cli-schema

Er is een nieuwe --cli-schema optie beschikbaar voor alle CLI-opdrachten. Wanneer deze wordt gebruikt, wordt een JSON-weergave van de CLI-opdrachtstructuur uitgevoerd voor de aangeroepen opdracht of subopdracht. Dit is handig voor auteurs van hulpprogramma's, shell-integratie en geavanceerde scripting.

dotnet clean --cli-schema

De uitvoer biedt een gestructureerde, machineleesbare beschrijving van de argumenten, opties en subopdrachten van de opdracht:

{
  "name": "clean",
  "version": "10.0.100-dev",
  "description": ".NET Clean Command",
  "arguments": {
    "PROJECT | SOLUTION": {
      "description": "The project or solution file to operate on. If a file is not specified, the command will search the current directory for one.",
      "arity": { "minimum": 0, "maximum": null }
    }
  },
  "options": {
    "--artifacts-path": {
      "description": "The artifacts path. All output from the project, including build, publish, and pack output, will go in subfolders under the specified path.",
      "helpName": "ARTIFACTS_DIR"
    }
  },
  "subcommands": {}
}

.NET MSBuild-taken gebruiken met .NET Framework MSBuild

MSBuild is het onderliggende buildsysteem voor .NET dat zowel het bouwen van projecten stuurt (zoals bij opdrachten dotnet build en dotnet pack) en tevens fungeert als algemene bron van informatie over projecten (zoals bij opdrachten dotnet list package en impliciet gebruikt door opdrachten zoals dotnet run om te ontdekken hoe een project uitgevoerd moet worden).

Wanneer u CLI-opdrachten uitvoert dotnet , is de versie van MSBuild die wordt gebruikt, degene die wordt geleverd met de .NET SDK. Wanneer u Echter Visual Studio gebruikt of MSBuild rechtstreeks aanroept, is de versie van MSBuild die wordt gebruikt, degene die met Visual Studio is geïnstalleerd. Dit milieuverschil heeft enkele belangrijke gevolgen. Het belangrijkste is dat MSBuild wordt uitgevoerd in Visual Studio (of via msbuild.exe) een .NET Framework-toepassing is, terwijl MSBuild die wordt uitgevoerd in de dotnet CLI een .NET-toepassing is. Dit betekent dat MSBuild-taken die zijn geschreven om te worden uitgevoerd op .NET niet kunnen worden gebruikt bij het bouwen in Visual Studio of wanneer ze worden gebruikt msbuild.exe.

Vanaf .NET 10 msbuild.exe en Visual Studio 2026 kunnen MSBuild-taken uitvoeren die zijn gebouwd voor .NET. Dit betekent dat u nu dezelfde MSBuild-taken kunt gebruiken bij het bouwen in Visual Studio of met msbuild.exe, net zoals bij het bouwen met de dotnet CLI. Voor de meeste .NET-gebruikers verandert dit niets. Maar voor auteurs van aangepaste MSBuild-taken betekent dit dat u nu uw taken kunt schrijven naar .NET en ze overal kunt laten werken. Het doel van deze wijziging is om het gemakkelijker te maken OM MSBuild-taken te schrijven en te delen, en om taakauteurs in staat te stellen te profiteren van de nieuwste functies in .NET. Bovendien vermindert deze wijziging de problemen met taken met meerdere doellijnen om zowel .NET Framework als .NET te ondersteunen en om te gaan met versies van .NET Framework-afhankelijkheden die impliciet beschikbaar zijn in de uitvoeringsruimte van MSBuild .NET Framework.

.NET-taken configureren

Voor taakauteurs is het eenvoudig om dit nieuwe gedrag te kiezen. U hoeft alleen uw UsingTask declaratie te wijzigen om MSBuild over uw taak te vertellen.

<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    TaskFactory="TaskHostFactory"
/>

De Runtime="NET" en TaskFactory="TaskHostFactory" kenmerken vertellen de MSBuild-engine hoe de taak moet worden uitgevoerd:

• Runtime="NET" vertelt MSBuild dat de taak is gebouwd voor .NET (in plaats van .NET Framework).
• TaskFactory="TaskHostFactory" vertelt MSBuild dat de TaskHostFactory taak moet worden uitgevoerd. Dit is een bestaande mogelijkheid van MSBuild waarmee taken buiten het proces kunnen worden uitgevoerd.

Kanttekeningen en prestatie-optimalisatie

Het voorgaande voorbeeld is de eenvoudigste manier om aan de slag te gaan met .NET-taken in MSBuild, maar het heeft enkele beperkingen. Omdat taken TaskHostFactory altijd buiten proces worden uitgevoerd, wordt de nieuwe .NET-taak altijd uitgevoerd in een afzonderlijk proces van MSBuild. Dit betekent dat er een kleine overhead is voor het uitvoeren van de taak, omdat de MSBuild-engine en de taak communiceren via IPC (Inter-Process Communication) in plaats van in-procescommunicatie. Voor de meeste taken is deze overhead te verwaarlozen, maar voor taken die vaak in een build worden uitgevoerd of die veel logboekregistratie uitvoeren, kan deze overhead aanzienlijker zijn.

Met nog iets meer werk kunt u de taak zo configureren dat deze nog steeds wordt uitgevoerd wanneer deze wordt uitgevoerd via dotnet:

<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    TaskFactory="TaskHostFactory"
    Condition="$(MSBuildRuntimeType) == 'Full'"
/>
<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    Condition="$(MSBuildRuntimeType) == 'Core'"
/>

Dankzij de Condition functie van MSBuild kunt u een taak anders laden, afhankelijk van of MSBuild wordt uitgevoerd in .NET Framework (Visual Studio of msbuild.exe) of .NET (de dotnet CLI). In dit voorbeeld wordt de taak buiten het proces uitgevoerd wanneer deze wordt uitgevoerd in Visual Studio of msbuild.exe, maar wordt deze binnen het proces uitgevoerd wanneer deze wordt uitgevoerd in de dotnet CLI. Dit biedt de beste prestaties bij het uitvoeren in de dotnet CLI, terwijl de taak nog steeds kan worden gebruikt in Visual Studio en msbuild.exe.

Er zijn ook enkele technische beperkingen om rekening mee te houden bij het gebruik van .NET Tasks in MSBuild, waarbij de meest opvallende is dat de Host Object-functie van MSBuild Tasks nog niet wordt ondersteund voor .NET taken die buiten het proces draaien. Dit betekent dat als uw taak afhankelijk is van een hostobject, het niet werkt wanneer deze wordt uitgevoerd in Visual Studio of msbuild.exe. Aanvullende ondersteuning voor hostobjecten wordt gepland in toekomstige releases.

Verbeteringen aan bestandsgebaseerde apps

.NET 10 brengt aanzienlijke updates voor de ervaring met bestand-gebaseerde apps, waaronder ondersteuning voor het publiceren en systeemeigen AOT-mogelijkheden. Zie Bestands-apps en C#-programma's bouwen en uitvoeren voor een inleiding tot op bestanden gebaseerde apps.

Verbeterde op bestanden gebaseerde apps met publicatieondersteuning en systeemeigen AOT

Op bestanden gebaseerde apps ondersteunen nu het publiceren naar systeemeigen uitvoerbare bestanden via de dotnet publish app.cs opdracht, waardoor het eenvoudiger is om eenvoudige apps te maken die u als systeemeigen uitvoerbare bestanden kunt distribueren. Alle op bestanden gebaseerde apps richten zich nu standaard op systeemeigen AOT. Als u pakketten of functies wilt gebruiken die niet compatibel zijn met systeemeigen AOT, kunt u dit uitschakelen met behulp van de #:property PublishAot=false instructie in uw .cs bestand.

Op bestanden gebaseerde apps bevatten ook verbeterde functies:

• Project waarnaar wordt verwezen: ondersteuning voor het verwijzen naar projecten via de #:project richtlijn.
• Toegang tot runtimepaden: App-bestands- en mappaden zijn tijdens runtime beschikbaar via System.AppContext.GetData.
• Verbeterde shebang-ondersteuning: Directe shell-uitvoering met verbeterde shebang-verwerking, inclusief ondersteuning voor extensieloze bestanden.

Voorbeeld van project waarnaar wordt verwezen

#:project ../ClassLib/ClassLib.csproj

var greeter = new ClassLib.Greeter();
var greeting = greeter.Greet(args.Length > 0 ? args[0] : "World");
Console.WriteLine(greeting);

Een voorbeeld van verbeterde shebang-ondersteuning

U kunt nu uitvoerbare C#-bestanden maken die rechtstreeks vanuit de shell worden uitgevoerd:

#!/usr/bin/env dotnet

Console.WriteLine("Hello shebang!");

Voor extensieloze bestanden:

# 1. Create a single-file C# app with a shebang
cat << 'EOF' > hello.cs
#!/usr/bin/env dotnet
Console.WriteLine("Hello!");
EOF

# 2. Copy it (extensionless) into ~/utils/hello (~/utils is on my PATH)
mkdir -p ~/utils
cp hello.cs ~/utils/hello

# 3. Mark it executable
chmod +x ~/utils/hello

# 4. Run it directly from anywhere
cd ~
hello

Deze verbeteringen zorgen ervoor dat op bestanden gebaseerde apps krachtiger worden en tegelijkertijd hun eenvoud behouden voor snelle script- en prototypescenario's.

Zie .NET native AOT voor meer informatie over systeemeigen AOT.

Verwijderen van door framework geleverde pakketverwijzingen

Vanaf .NET 10 kan de NuGet Audit-functie door het framework geleverde pakketverwijzingen verwijderen die niet door het project worden gebruikt. Deze functie is standaard ingeschakeld voor alle frameworks van een project dat zich richt op > .NET 10.0 in de nieuwste SDK. Deze wijziging helpt het aantal pakketten te verminderen dat tijdens het buildproces wordt hersteld en geanalyseerd, wat kan leiden tot snellere buildtijden en minder schijfruimtegebruik. Het kan ook leiden tot een vermindering van vals positieven van NuGet Audit en andere afhankelijkheidsscanmechanismen.

Wanneer deze functie is ingeschakeld, ziet u mogelijk een vermindering van de inhoud van de gegenereerde .deps.json bestanden van uw toepassingen. Alle pakketverwijzingen die door de .NET-runtime worden geleverd, worden automatisch verwijderd uit het gegenereerde afhankelijkheidsbestand. Wanneer een directe pakketreferentie binnen het snoeibereik valt, worden PrivateAssets="all" en IncludeAssets="none" toegepast.

Hoewel deze functie standaard is ingeschakeld voor de vermelde TFM's, kunt u deze uitschakelen door de eigenschap RestoreEnablePackagePruning in te stellen op false in uw projectbestand of Directory.Build.props bestand.

Consistentere opdrachtvolgorde

Vanaf .NET 10 bevat het dotnet CLI-hulpprogramma nieuwe aliassen voor algemene opdrachten om ze gemakkelijker te onthouden en te typen. De nieuwe opdrachten worden weergegeven in de volgende tabel.

De nieuwe zelfstandig naamwoord-eerst vormen zijn afgestemd op algemene CLI-standaarden, waardoor de dotnet CLI consistenter wordt met andere tools. Hoewel de werkwoord-eerst-vormen blijven werken, is het beter om de zelfstandig naamwoord-eerst-vormen te gebruiken voor verbeterde leesbaarheid en consistentie in scripts en documentatie.

CLI-opdrachten zijn standaard ingesteld op de interactieve modus in interactieve terminals

De --interactive vlag is nu standaard ingeschakeld voor CLI-opdrachten in interactieve terminals. Met deze wijziging kunnen opdrachten referenties dynamisch ophalen of ander interactief gedrag uitvoeren zonder dat de vlag expliciet moet worden ingesteld. Voor niet-interactieve scenario's kunt u interactiviteit uitschakelen door --interactive false te specificeren.

Ondersteunde shell tab-aanvulscripts

De dotnet CLI biedt nu ondersteuning voor het genereren van systeemeigen tabvoltooiingsscripts voor populaire shells met behulp van de dotnet completions generate [SHELL] opdracht. Ondersteunde shells zijn onder andere bash, fish, nushellen powershellzsh. Deze scripts verbeteren de bruikbaarheid door snellere en meer geïntegreerde functies voor tabvoltooiing te bieden. In PowerShell kunt u bijvoorbeeld voltooiingen inschakelen door het volgende toe te voegen aan uw $PROFILE:

dotnet completions script pwsh | out-String | Invoke-Expression -ErrorAction SilentlyContinue

Console-apps kunnen native container images maken

Console-apps kunnen nu containerinstallatiekopieën maken zonder dat de dotnet publish /t:PublishContainer eigenschap in het projectbestand vereist is via <EnableSdkContainerSupport>. Hiermee worden console-apps uitgelijnd met het gedrag van ASP.NET Core- en Worker SDK-apps.

De formaten van containerafbeeldingen expliciet beheren

Met een nieuwe <ContainerImageFormat> eigenschap kunt u de indeling van containerafbeeldingen expliciet instellen op Docker of OCI. Met deze eigenschap wordt het standaardgedrag overschreven, wat afhangt van het basisafbeeldingsformaat en of de container meerdere architecturen heeft.

Ondersteuning voor Microsoft Testing Platform in dotnet test

Vanaf .NET 10 biedt dotnet test systeemeigen ondersteuning voor Microsoft.Testing.Platform. Als u deze functie wilt inschakelen, voegt u de volgende configuratie toe aan uw global.json-bestand :

{
    "test": {
        "runner": "Microsoft.Testing.Platform"
    }
}

Voor meer details, zie Testen met dotnet test.