Consider packaging `dnx` with the .NET Runtime

[lbussell]

The new dnx features are awesome. They make it really convenient to run .NET tools. However, they require the entire .NET SDK to run. It would be even more convenient if dnx was usable with only the .NET Runtime installed.

For example, I would like to run a tool using dnx in a .NET Runtime container image. However, I need to use the entire SDK image.

For comparison, the size of the .NET 10 Preview 6 linux-x64 SDK is ~230 MB, whereas the Runtime is just ~35 MB. And mcr.microsoft.com/dotnet/sdk:10.0-preview is ~332 MB while mcr.microsoft.com/dotnet/runtime:10.0-preview is ~83 MB.

[baronfel]

This is definitely something we're thinking about. The tools functionalities are useful/viable on their own, but splitting them out is definitely a complete rethink of how the SDK works/is built today.

Our best take on this problem is that dnx could/should be a standalone native AOT app that carries all of the SDK's knowledge of tools. The main blocker to that right now is technical - we need NuGet APIs and the Telemetry library we use in the SDK to be AOT-friendly. The latter especially will require help from your team @lbussell because we'll need to onboard OpenTelemetry to source build (and perhaps the AzureMonitor adapter to OTel as well).

The long-term goal that we should shoot for here is that tools that have no framework-dependent components should be installable and usable without the SDK or the Runtime installed. Tools that have framework-dependent components should be installable and usable as long as a compatible Runtime is installed and available.

[lbussell]

dnx could/should be a standalone native AOT app that carries all of the SDK's knowledge of tools.
...
The long-term goal that we should shoot for here is that tools that have no framework-dependent components should be installable and usable without the SDK or the Runtime installed.

Not requiring the Runtime would open up even more doors. I can imagine shipping dnx in dotnet/runtime-deps images, or even a new dotnet/dnx image. Something super lightweight + distroless for running .NET tools in a container. Lots to think about.

[baronfel]

One of the side-effects of dnx being part of the sdk is that it's vulnerable to the muxer's SDK selection. Users that are on 9 following new dnx-ified getting-started tutorials run face-first into the wall of command not recognized.

[diluculo]

Sharing a concrete data point that complements the container scenario in the OP — ours is on the client side.

We built FieldCure.ToolHost as a time-bounded bridge for running NuGet .NET tools from SDK-less hosts, motivated by MSIX / Microsoft Store app distribution where requiring or shipping the full .NET SDK is not a viable UX.

https://github.com/fieldcure/fieldcure-toolhost

The CLI (fcdnx) and library mirror the dnx surface where reasonable, and the project is explicitly documented as an interim bridge — with sunset planned once a standalone dnx ships.

Posting in case it's useful to others hitting the same gap in the meantime.