[New article]: dotnet tools support RID-specific and AOT packages

[baronfel]

Proposed topic or title

dotnet tools can be RID-specific, self-contained, or AOT applications now

Location in table of contents.

No response

Reason for the article

In .NET SDK 10.0.100-preview.6 we added support for a new way of authoring tools that enables packaging them for specific platforms and architectures. This makes it much simpler to easily distribute native, fast, trimmed .NET applications for use cases like MCP servers.

Article abstract

• How to opt in to the new behaviors
  • set RuntimeIdentifiers or ToolPackageRuntimeIdentifiers MSBuild properties to a semicolon-delimited list of RID values (win-x64;osx-arm64, etc).
• How the tooling reacts to the new model
  • If you're not doing AOT - dotnet pack on the tool will create N+1 NuGet packages - one for each RID called <packageName>.<RID>.<packageVersion>.nupkg, and as a RID-less pointer called <packageName>.<packageVersion>.nupkg like today.
  • If you are doing AOT, then you need to dotnet pack once for the top-level package, but then on separate platforms call dotnet pack -r <RID> to make the RID-specific packages manually
  • The top-level package has the same PackageType (DotnetTool), but the RID-specific packages have a new PackageType (DotnetToolRidPackage)
  • The top-level package contains metadata signalling that it is a RID-specific tool, and what the RID-specific packages are
  • Push all of these to NuGet.org
  • on dotnet tool install, if the top-level package's metadata signals that it is a RID-specific tool, the CLI will find and install the most relevant package for the user's current platform and invoke that
• Sample application

There is no design for this feature.
Initial implementation at dotnet/sdk#48575, follow-up usability tweaks at dotnet/sdk#49288

Relevant searches

No response