Nyheter i SDK och verktyg för .NET 10

I den här artikeln beskrivs nya funktioner och förbättringar i .NET SDK för .NET 10. Den har uppdaterats för RC 2.

Förbättringar av .NET-verktyg

Plattformsspecifika .NET-verktyg

.NET-verktyg kan nu publiceras med stöd för flera RuntimeIdentifiers (RID) i ett enda paket. Verktygsförfattare kan paketera binärfiler för alla plattformar som stöds, och .NET CLI kommer att välja rätt binärfiler vid installation eller körning. Detta gör det mycket enklare att redigera och distribuera plattformsoberoende verktyg.

Dessa förbättrade verktyg stöder olika förpackningsvariationer:

• Ramverksberoende, plattformsoberoende (klassiskt läge, körs var som helst med .NET 10 installerat)
• Ramverksberoende, plattformsspecifik (mindre, optimerad för varje plattform)
• Fristående, plattformsspecifik (inkluderar körningen, ingen .NET-installation krävs)
• Trimmad, plattformsspecifik (mindre, trimmar oanvänd kod)
• AOT-kompilerad, plattformsspecifik (maximal prestanda och minsta distribution)

Dessa nya verktyg fungerar ungefär som vanliga publicerade program, så alla publiceringsalternativ som du kan använda med program (till exempel fristående, trimmade eller AOT) kan även gälla för verktyg.

Körning av enstaka verktyg

Du kan nu använda dotnet tool exec kommandot för att köra ett .NET-verktyg utan att installera det globalt eller lokalt. Detta är särskilt värdefullt för CI/CD eller tillfällig användning.

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 /   | (_) | | |    | | | (_| | |_|
 |_| |_|  \___| |_| |_|  \___/  ( )      \_/\_/     \___/  |_|    |_|  \__,_| (_)
                                |/

Detta laddar ned och kör det angivna verktygspaketet i ett kommando. Som standard uppmanas användarna att bekräfta nedladdningen om verktyget inte redan finns lokalt. Den senaste versionen av det valda verktygspaketet används om inte en explicit version har angetts (till exempel dotnetsay@0.1.0).

Enstaka verktygskörning fungerar sömlöst med lokala verktygsmanifest. Om du kör ett verktyg från en plats som innehåller en .config/dotnet-tools.json i närheten används versionen av verktyget i konfigurationen i stället för den senaste tillgängliga versionen.

Det nya dnx verktygskörningsskriptet

Skriptet dnx ger ett effektivt sätt att köra verktyg. Den vidarebefordrar alla argument till dotnet CLI för bearbetning, vilket gör verktygsanvändningen så enkel som möjligt:

dnx dotnetsay "Hello, World!"

Den faktiska implementeringen av dnx kommandot finns i dotnet själva CLI, vilket gör att dess beteende kan utvecklas över tid.

Mer information om hur du hanterar .NET-verktyg finns i Hantera .NET-verktyg.

any Använda RuntimeIdentifier med plattformsspecifika .NET-verktyg

Den plattformsspecifika .NET-verktygsfunktionen är bra för att se till att verktygen är optimerade för specifika plattformar som du riktar in dig på i förväg. Det finns dock tillfällen då du inte känner till alla plattformar som du vill rikta in dig på, eller ibland kommer .NET självt att lära sig att stödja en ny plattform, och du vill att ditt verktyg också ska kunna köras där.

Om du vill att verktyget ska fungera på det här sättet lägger du till any körningsidentifieraren i projektfilen:

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

Den här RuntimeIdentifier är "roten" för kontrollen av plattformskompatibilitet, och eftersom den deklarerar stöd för alla plattformar är verktyget som paketeras den mest kompatibla typen av verktyg – en ramverksberoende, plattformsoberoende .NET DLL, som kräver en kompatibel .NET Runtime för att köra. När du utför en dotnet pack för att skapa verktyget visas ett nytt paket för any RuntimeIdentifier tillsammans med de andra plattformsspecifika paketen och manifestpaketet på den översta nivån.

CLI-introspektion med --cli-schema

Ett nytt --cli-schema alternativ är tillgängligt för alla CLI-kommandon. När den används matar den ut en JSON-representation av CLI-kommandoträdet för det anropade kommandot eller underkommandot. Detta är användbart för verktygsförfattare, gränssnittsintegrering och avancerad skriptning.

dotnet clean --cli-schema

Utdata ger en strukturerad, maskinläsbar beskrivning av kommandots argument, alternativ och underkommandon:

{
  "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": {}
}

Använd .NET MSBuild-aktiviteter med .NET Framework MSBuild

MSBuild är det underliggande byggsystemet för .NET, som driver både bygget av projekt (som i kommandon som dotnet build och dotnet pack) och fungerar som en allmän leverantör av information om projekt (vilket visas i kommandon som dotnet list package, och implicit används av kommandon som dotnet run för att upptäcka hur ett projekt vill köras).

När du kör dotnet CLI-kommandon är den version av MSBuild som används den som levereras med .NET SDK. Men när du använder Visual Studio eller anropar MSBuild direkt är den version av MSBuild som används den som installeras med Visual Studio. Den här miljöskillnaden har några viktiga konsekvenser. Det viktigaste är att MSBuild som körs i Visual Studio (eller via msbuild.exe) är ett .NET Framework-program, medan MSBuild som körs i dotnet CLI är ett .NET-program. Det innebär att alla MSBuild-uppgifter som skrivs för att köras på .NET inte kan användas när du skapar i Visual Studio eller när du använder msbuild.exe.

Från och med .NET 10 msbuild.exe och Visual Studio 2026 kan du köra MSBuild-uppgifter som har skapats för .NET. Det innebär att du nu kan använda samma MSBuild-uppgifter när du skapar i Visual Studio eller använder msbuild.exe som du gör när du skapar med dotnet CLI. För de flesta .NET-användare ändras ingenting. Men för författare av anpassade MSBuild-uppgifter innebär det att du nu kan skriva dina uppgifter för att rikta in dig på .NET och få dem att fungera överallt. Målet med den här ändringen är att göra det enklare att skriva och dela MSBuild-uppgifter och att tillåta aktivitetsförfattare att dra nytta av de senaste funktionerna i .NET. Dessutom minskar den här ändringen svårigheterna med aktiviteter med flera mål för att stödja både .NET Framework och .NET och hantera versioner av .NET Framework-beroenden som är implicit tillgängliga i MSBuild .NET Framework-körningsutrymmet.

Konfigurera .NET-uppgifter

För uppgiftsförfattare är det enkelt att välja det här nya beteendet. Ändra bara UsingTask-deklarationen för att berätta för MSBuild om din uppgift.

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

Attributen Runtime="NET" och TaskFactory="TaskHostFactory" talar om för MSBuild-motorn hur uppgiften ska köras:

• Runtime="NET" anger för MSBuild att uppgiften har skapats för .NET (till skillnad från .NET Framework).
• TaskFactory="TaskHostFactory" instruerar MSBuild att använda TaskHostFactory för att köra uppgiften, vilket är en befintlig funktion i MSBuild som gör att aktiviteter kan köras ut ur processen.

Varningar och prestandajustering

Föregående exempel är det enklaste sättet att komma igång med .NET-uppgifter i MSBuild, men det har vissa begränsningar. Eftersom TaskHostFactory alltid kör uppgifter utanför processen, körs den nya .NET-uppgiften alltid i en separat process, skild från den som MSBuild kör. Det innebär att det finns en del mindre omkostnader för att köra aktiviteten eftersom MSBuild-motorn och uppgiften kommunicerar via kommunikation mellan processer (IPC) i stället för processkommunikation. För de flesta uppgifter är den här kostnaden försumbar, men för uppgifter som körs många gånger i en version, eller som utför mycket loggning, kan den här kostnaden vara mer betydande.

Med bara lite mer arbete kan du konfigurera uppgiften så att den fortfarande körs i processen när den körs 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'"
/>

Tack vare Condition funktionen i MSBuild kan du läsa in en uppgift på olika sätt beroende på om MSBuild körs i .NET Framework (Visual Studio eller msbuild.exe) eller .NET ( dotnet CLI). I det här exemplet körs uppgiften utanför processen när den körs i Visual Studio eller msbuild.exe, men körs inom processen när den körs i dotnet CLI. Detta ger bästa prestanda när den körs i dotnet CLI, samtidigt som Tasken kan användas i Visual Studio och msbuild.exe.

Det finns också små tekniska begränsningar att vara medveten om när du använder .NET Tasks i MSBuild—det mest anmärkningsvärda är att MSBuild Tasks-funktionen ännu inte stöds för .NET Tasks som körs utanför processen. Det innebär att om din uppgift förlitar sig på ett värdobjekt fungerar den inte när den körs i Visual Studio eller msbuild.exe. Ytterligare stöd för värdobjekt planeras i framtida versioner.

Förbättringar av filbaserade appar

.NET 10 ger betydande uppdateringar av den filbaserade appupplevelsen, inklusive publiceringsstöd och interna AOT-funktioner. En introduktion till filbaserade appar finns i Filbaserade appar och Skapa och köra C#-program.

Förbättrade filbaserade appar med publiceringsstöd och intern AOT

Filbaserade appar stöder nu publicering till inbyggda körbara filer via dotnet publish app.cs kommandot, vilket gör det enklare att skapa enkla appar som du kan distribuera om som inbyggda körbara filer. Alla filbaserade appar riktar nu in sig på intern AOT som standard. Om du behöver använda paket eller funktioner som inte är kompatibla med inbyggd AOT kan du inaktivera detta med hjälp av #:property PublishAot=false direktivet i din .cs-fil.

Filbaserade appar innehåller även förbättrade funktioner:

• Projektreferenser: Stöd för att referera till projekt via #:project direktivet.
• Åtkomst till körningssökväg: Appfiler och kataloger är tillgängliga under körning via System.AppContext.GetData.
• Förbättrat stöd för shebang: Direkt shellkörning med förbättrad hantering av shebang, inklusive stöd för tilläggslösa filer.

Exempel på projektreferenser

#:project ../ClassLib/ClassLib.csproj

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

Förbättrat exempel på shebang-stöd

Nu kan du skapa körbara C#-filer som körs direkt från gränssnittet:

#!/usr/bin/env dotnet

Console.WriteLine("Hello shebang!");

För tilläggslösa filer:

# 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

De här förbättringarna gör filbaserade appar mer kraftfulla samtidigt som de bevarar sin enkelhet för snabba skript och prototypscenarier.

Mer information om intern AOT finns i .NET native AOT.

Beskärning av paketreferenser som tillhandahålls av ramverket

Från och med .NET 10 kan nuget-granskningsfunktionenbeskära paketreferenser som tillhandahålls av ramverk som inte används av projektet. Den här funktionen är som standard aktiverad för alla ramverk i ett projekt som riktar sig mot .NET 10.0 med den senaste SDK. Den här ändringen bidrar till att minska antalet paket som återställs och analyseras under byggprocessen, vilket kan leda till snabbare byggtider och minskad diskutrymmesanvändning. Det kan också minska antalet falska positiva resultat från granskning med NuGet och andra beroendeskanningsmekanismer.

När den här funktionen är aktiverad kan du se en minskning av innehållet i dina program genererade .deps.json filer. Alla paketreferenser som tillhandahålls av .NET-körningen tas automatiskt bort från den genererade beroendefilen. När en direkt paketreferens är inom beskärningsintervallet tillämpas och .

Även om den här funktionen är aktiverad som standard för de listade TFM:erna kan du inaktivera den genom att ange egenskapen RestoreEnablePackagePruning till false i projektfilen eller Directory.Build.props fil.

Mer konsekvent kommandoordning

Från och med .NET 10 innehåller verktyget dotnet CLI nya alias för vanliga kommandon för att göra dem enklare att komma ihåg och skriva. De nya kommandona visas i följande tabell.

De nya substantiv-första formulären överensstämmer med allmänna CLI-standarder, vilket gör dotnet CLI mer konsekvent med andra verktyg. Även om de verb-första formulären fortsätter att fungera är det bättre att använda substantiv-första formulären för bättre läsbarhet och konsekvens i skript och dokumentation.

CLI-kommandon körs som standard i interaktivt läge i interaktiva terminaler

Flaggan --interactive är nu aktiverad som standard för CLI-kommandon i interaktiva terminaler. Den här ändringen gör det möjligt för kommandon att dynamiskt hämta autentiseringsuppgifter eller utföra andra interaktiva beteenden utan att kräva att flaggan uttryckligen anges. För icke-interaktiva scenarier kan du inaktivera interaktivitet genom att --interactive falseange .

Skript för inbyggt gränssnitt för tab-completion

dotnet CLI har nu stöd för att generera inbyggda tab-completion-skript för populära gränssnitt med hjälp av dotnet completions generate [SHELL] kommandot . Gränssnitt som stöds är bash, fish, nushell, powershelloch zsh. Dessa skript förbättrar användbarheten genom att tillhandahålla snabbare och mer integrerade tab-completion-funktioner. I PowerShell kan du till exempel aktivera slutföranden genom att lägga till följande i :$PROFILE

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

Konsolappar kan skapa containeravbildningar internt

Konsolappar kan nu skapa containeravbildningar via dotnet publish /t:PublishContainer utan att kräva egenskapen <EnableSdkContainerSupport> i projektfilen. Detta justerar konsolappar med beteendet för ASP.NET Core- och Worker SDK-appar.

Kontrollera uttryckligen avbildningsformatet för containrar

Med en ny <ContainerImageFormat> egenskap kan du uttryckligen ange formatet för containeravbildningar till antingen Docker eller OCI. Den här egenskapen åsidosätter standardbeteendet, vilket beror på basavbildningsformatet och om containern är multiarkitektur.

Stöd för Microsoft Testing Platform i dotnet test

Från och med .NET 10 dotnet test har inbyggt stöd för Microsoft.Testing.Platform. Om du vill aktivera den här funktionen lägger du till följande konfiguration i filenglobal.json :

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

Mer information finns i Testa med dotnet test.