Skapa RID-specifika, fristående och AOT .NET-verktyg

Den här artikeln gäller för: ✔️ .NET SDK 10 och senare versioner

Paketera .NET-verktyg för specifika plattformar och arkitekturer så att du kan distribuera inbyggda, snabba och trimmade program. Den här funktionen gör det enklare att distribuera optimerade program för kommandoradsverktyg som MCP-servrar eller andra plattformsspecifika verktyg.

Översikt

Från och med .NET SDK 10 kan du skapa .NET-verktyg som riktar sig mot specifika operativsystemmiljöer (representeras av Runtime Identifiers (RID)). Dessa verktyg kan vara:

RID-specifik: Kompilerad för specifika operativsystem och arkitekturer.
Självförsörjande: Inkluderar .NET-runtime och kräver ingen separat installation av .NET.
Intern AOT: Använd kompilering i förväg för snabbare start och mindre minnesfotavtryck.

Användarna märker ingen skillnad när de installerar verktyget. .NET CLI väljer och installerar automatiskt det bästa paketet för sin plattform.

Anmäl dig till RID-specifik förpackning

Om du vill skapa ett RID-specifikt verktyg konfigurerar du projektet med någon av följande MSBuild-egenskaper:

Egenskapen RuntimeIdentifiers

Använd RuntimeIdentifiers för att ange de plattformar som verktyget stöder:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <PackAsTool>true</PackAsTool>
    <ToolCommandName>mytool</ToolCommandName>
    <RuntimeIdentifiers>win-x64;linux-x64;osx-arm64</RuntimeIdentifiers>
  </PropertyGroup>
</Project>

ToolPackageRuntimeIdentifiers-egenskapen

Du kan också använda ToolPackageRuntimeIdentifiers för verktygsspecifik RID-konfiguration:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <PackAsTool>true</PackAsTool>
    <PublishAot>true</PublishAot>
    <ToolCommandName>mytool</ToolCommandName>
    <ToolPackageRuntimeIdentifiers>win-x64;linux-x64;osx-arm64</ToolPackageRuntimeIdentifiers>
  </PropertyGroup>
</Project>

Använd en semikolonavgränsad lista med RID-värden. En lista över Körningsidentifierare finns i RID-katalogen.

Ange en ramverksberoende version

När du väljer RID-specifik verktygsförpackning skapar .NET SDK fristående paket för varje angiven RID. Du förlorar dock standardramverksberoende paketering som fungerar på valfri plattform med .NET-körningen installerad.

Om du vill tillhandahålla en ramverksberoende version tillsammans med RID-specifika paket lägger du till any i listan ToolPackageRuntimeIdentifiers :

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
  <ToolPackageRuntimeIdentifiers>win-x64;osx-arm64;linux-x64;any</ToolPackageRuntimeIdentifiers>
</PropertyGroup>

Den här konfigurationen skapar fem paket:

Ett pekarpaket på den översta nivån som visar alla tillgängliga underpaket.
Tre RID-specifika paket (win-x64, osx-arm64, linux-x64) som är fristående och trimmade.
Ett RID-agnostiskt paket (any) som är ramverksberoende och kräver att .NET-körningen installeras.

När användarna installerar verktyget:

På win-x64, osx-arm64eller linux-x64 -system laddas de fristående, trimmade paketen ned och körs.
På andra operativsystem eller arkitekturer används det ramverksberoende any paketet.

Den här metoden ger optimerade, fristående binärfiler för vanliga plattformar, samtidigt som den upprätthåller kompatibilitet med mindre vanliga plattformar via ett ramverksberoende alternativ.

När du ska använda `RuntimeIdentifiers` vs `ToolPackageRuntimeIdentifiers`

Både RuntimeIdentifiers och ToolPackageRuntimeIdentifiers aktiverar ditt verktyg för RID-specifika paketeringar, men de tjänar något olika syften:

Använd RuntimeIdentifiers när:

Du vill att projektet ska skapa och publicera RID-specifika appar i allmänhet (inte bara som ett verktyg).
Du riktar dig främst till CoreCLR (icke-AOT) eller så vill du ha standard-SDK-beteendet där en enda dotnet pack genererar flera RID-specifika paket.
Du kan anpassa PublishAot för en delmängd av RIDs, men du vill fortfarande ha ett paket baserat på CoreCLR för varje RID i RuntimeIdentifiers.

Använd ToolPackageRuntimeIdentifiers när:

Du vill definiera RID-specifikt beteende endast för verktygsförpackningen, utan att ändra hur projektet byggs för andra distributionsscenarier.
Du använder intern AOT och planerar att manuellt skapa AOT-binärfiler per RID med dotnet pack -r <RID>.
Du vill ha en hybridmodell där vissa RID:er får intern AOT och andra återgår till en bärbar CoreCLR-implementering.

Notes:

Det översta pekarpaketet anger de tillgängliga RID-specifika paketen. Om du anger ToolPackageRuntimeIdentifiers, bestämmer det verktygets RIDs; annars används RuntimeIdentifiers.
ToolPackageRuntimeIdentifiers ska vara lika med eller en delmängd av RID:erna i RuntimeIdentifiers
När PublishAot=truegenereras RID-specifika paket endast när du packar för en specifik RID (till exempel dotnet pack -r linux-x64).
Interna AOT-versioner (PublishAot=true) stöds endast när genereringsoperativsystemet och måloperativsystemet matchar.

Paketera verktyget

Paketeringsprocessen varierar beroende på om du använder AOT-kompilering. Kör kommandot dotnet pack för att skapa ett NuGet-paket eller en .nupkg-fil från projektet.

RID-specifika och fristående verktyg

Kör dotnet pack en gång:

dotnet pack

Det här kommandot skapar flera NuGet-paket:

Ett paket för varje RID: <packageName>.<RID>.<packageVersion>.nupkg
- Exempel: mytool.win-x64.1.0.0.nupkg
- Exempel: mytool.linux-x64.1.0.0.nupkg
- Exempel: mytool.osx-arm64.1.0.0.nupkg
Ett RID-agnostiskt pekarpaket: <packageName>.<packageVersion>.nupkg
- Exempel: mytool.1.0.0.nupkg

AOT-verktyg

För verktyg med AOT-kompilering (<PublishAot>true</PublishAot>) måste du packa separat för varje plattform.

Plattformskrav för intern AOT

Intern AOT-kompilering kräver operativsystemdelen (OS) av SDK RID för att matcha mål-RID:ets operativsystem. SDK:t kan korskompilera för olika arkitekturer (till exempel x64 till ARM64) men inte mellan operativsystem (till exempel Windows till Linux).

Det innebär att du har flera alternativ för att skapa interna AOT-paket:

Skapa endast för utvecklingsdatorn: Stöd endast intern AOT för det operativsystem som du utvecklar på.
Använda containrar för Linux-versioner: Om du använder macOS eller Windows använder du containrar för att korskompilera för Linux. Använd till exempel mcr.microsoft.com/dotnet/sdk:10.0-noble-aot containeravbildningar.
Federera ditt bygge mellan datorer: Använd CI/CD-system som GitHub Actions eller Azure DevOps Pipelines för att bygga vidare på olika operativsystem.

Du behöver inte skapa alla RID-specifika paket på samma dator eller på samma gång. Du behöver bara skapa och publicera dem innan du publicerar paketet på den översta nivån.

Paketering av interna AOT-verktyg

Packa paketet på den översta nivån en gång (på valfri plattform):

dotnet pack

Paket för varje specifik RID på motsvarande plattform, till exempel:

dotnet pack -r linux-x64

Du måste köra varje RID-specifikt paketkommando på en plattform där operativsystemet matchar mål-RID:s operativsystem. Mer information om förutsättningarna för intern AOT-kompilering finns i Intern AOT-distribution.

När du anger PublishAot till trueändras förpackningsbeteendet:

dotnet pack genererar pekarpaketet på den översta nivån (pakettyp DotnetTool).
RID-specifika AOT-paket produceras endast när du uttryckligen skickar -r <RID>, till exempel dotnet pack -r linux-x64 eller dotnet pack -r osx-arm64.

Hybrid-AOT + CoreCLR-paketeringsmönster (exempel)

Vissa verktyg vill ha det bästa av två världar:

Intern AOT för en delmängd av plattformar med hög prioritet (beroende på verktyget).
En bärbar CoreCLR-reservlösning som fungerar på plattformar som inte är mål för de inhemska AOT-versionerna.

Du kan uppnå den här hybridmodellen med följande mönster:

Konfigurera verktyget för inbyggda AOT- och verktygsspecifika RID:er.

I projektfilen, använd ToolPackageRuntimeIdentifiers och aktivera PublishAot.

Till exempel:
```
<ToolPackageRuntimeIdentifiers>osx-arm64;linux-arm64;linux-x64;any</ToolPackageRuntimeIdentifiers>
<PublishAot>true</PublishAot>
```
Skapa pekarpaketet.

Kör dotnet pack en gång (på valfri plattform) för att skapa det toppnivåpaket som pekar på RID-specifika paket:
```
dotnet pack
```
Skapa interna AOT-paket för valda RID:er.

Inhemsk AOT-kompilering kräver byggande på målplattformen. Skapa varje AOT-aktiverat RID-paket på den motsvarande plattformen med dotnet pack -r <RID>.

Till exempel:

dotnet pack -r linux-x64

Skapa ett CoreCLR-återställningspaket.

Om du vill tillhandahålla en universell reserv kan du packa any RID utan AOT:
```
dotnet pack -r any -p:PublishAot=false
```
Detta skapar ett bärbart CoreCLR-paket (till exempel yourtool.any.<version>.nupkg) som kan köras på plattformar som inte har en dedikerad AOT-version.

Anmärkning

Du kan också använda containeravbildningarna .NET SDK 10.0-noble-aot för att skapa och paketera inbyggda Linux-AOT-verktyg från valfri värd som stöder Linux-containrar. Till exempel:

mcr.microsoft.com/dotnet/sdk:10.0-noble-aot

Detta är användbart när utvecklingsdatorn inte kör Linux internt.

I den här hybridkonfigurationen:

Pekarpaketet (yourtool.<version>.nupkg) refererar till båda:
- RID-specifika interna AOT-paket (till exempel yourtool.osx-arm64, yourtool.linux-x64).
- any CoreCLR-paketet som en reserv.
.NET CLI väljer automatiskt det lämpligaste paketet för användarens plattform när de kör dotnet tool install eller dnx.

Exempel: `dotnet10-hybrid-tool`

Lagringsplatsendotnet10-hybrid-tool visar det här hybridpaketeringsmönstret med interna AOT-paket för osx-arm64, linux-arm64och linux-x64, plus ett CoreCLR-återställningspaket för any RID (används till exempel i Windows när ingen AOT-version är tillgänglig).

Du kan installera och prova verktyget själv:

dotnet tool install -g dotnet10-hybrid-tool
dotnet10-hybrid-tool

Verktyget rapporterar sin runtime framework-beskrivning, körningsidentifierare (RID) och kompileringsläge (intern AOT eller CoreCLR).

Exempel på utdata på en plattform med intern AOT:

Hi, I'm a 'DotNetCliTool v2' tool!
Yes, I'm quite fancy.

Version: .NET 10.0.2
RID: osx-arm64
Mode: Native AOT

Exempel på utdata på en plattform med CoreCLR-fallback:

Hi, I'm a 'DotNetCliTool v2' tool!
Yes, I'm quite fancy.

Version: .NET 10.0.2
RID: win-x64
Mode: CoreCLR

Detta gör det till ett användbart sätt att experimentera med RID-specifika, AOT-kompilerade verktyg och CoreCLR-återställningsbeteendet.

Publicera verktyget

När du publicerar RID-specifika verktygspaket använder .NET CLI versionsnumret för det översta paketet för att välja matchande RID-specifika paket. Detta innebär att:

Alla RID-specifika paket måste ha exakt samma version som toppnivåpaketet.
Alla paket måste publiceras i feeden innan paketet på den översta nivån blir tillgängligt.

För att säkerställa en smidig publiceringsprocess:

Publicera alla RID-specifika paket först:

dotnet nuget push yourtool.win-x64.1.0.0.nupkg
dotnet nuget push yourtool.linux-x64.1.0.0.nupkg
dotnet nuget push yourtool.osx-arm64.1.0.0.nupkg
dotnet nuget push yourtool.any.1.0.0.nupkg

Publicera det översta paketet senast:
```
dotnet nuget push yourtool.1.0.0.nupkg
```

Genom att publicera det översta paketet ser du till att alla refererade RID-specifika paket är tillgängliga när användarna installerar verktyget. Om en användare installerar verktyget innan alla RID-paket publiceras misslyckas installationen.

Installera och köra verktyg

Om ett verktyg använder RID-specifik paketering är en implementeringsinformation som är transparent för användarna. Du installerar och kör verktyg på samma sätt, oavsett om verktygsutvecklaren har valt RID-specifik paketering.

Så här installerar du ett verktyg globalt:

dotnet tool install -g mytool

När du har installerat det kan du anropa det direkt:

mytool

Du kan också använda hjälpverktyget dnx , som fungerar på samma sätt npx som i Node.js ekosystemet: det laddar ned och startar ett verktyg i en enda gest om det inte redan finns:

dnx mytool

När ett verktyg använder RID-specifik paketering väljer .NET CLI automatiskt rätt paket för din plattform. Du behöver inte ange en RID – CLI härleder den från systemet och laddar ned lämpligt RID-specifikt paket.

Se även

Feedback

Var den här sidan hjälpsam?

Last updated on 2026-01-27