Video summary

Simplifying .NET Installs with dotnetup

Main summary

Key takeaways

Technology

Summary of “Simplifying .NET Installs with dotnetup” (auto-subtitles)

Problem being addressed

  • Installing and managing the .NET SDK over time is fragmented across platforms and tooling.
  • On Windows, Visual Studio handles toolchain updates centrally.
  • Elsewhere (and generally for non-Visual-Studio workflows), the process is a “mixed bag”:
    • IDE-based: Visual Studio Code via an SDK-getting extension.
    • Package manager–based: e.g., Homebrew/Wget-style package manager ecosystems.
    • Manual / scripting: get .NET website install scripts (including PowerShell scripts), plus SDK version managers.
  • Complexity increases on Linux distributions and due to differing package-provider histories (Microsoft sometimes vs distro maintainers).
  • Pain points:
    • SDKs ship 4 times per year with quarterly feature bands—teams often need control over versions and update cadence.
    • User-level install methods often lack central management, auditability, easy updates/uninstalls, and can clash with system installs.
    • Debugging/validating installations is hard for maintainers when reporting bugs.

The solution: dotnetup (an early/internal preview product)

Goals

  • Behave the same on every platform.
  • Prefer user-global installs (in the user directory), no admin/elevation required.
  • Be fast and lightweight, implemented as an AOT (ahead-of-time compiled) app.
  • Use existing configuration input: global.json (with possible future evolution).
  • Add safety/auditability by signing binaries and manifests (working with .NET release teams).
  • Provide a library so other tools can install/manage .NET components consistently and safely.

How to get started (installing dotnetup)

  • Installation is via platform detection and a script:
    • Link pattern shown: aams.netup getnet up (script download + run).
  • First run includes an init/config walkthrough:
    • Chooses update “channels” (example used: latest stable).
    • Allows setup in terminal mode so dotnetup updates shell configuration.
    • dotnetup supports telemetry opt-out flags consistent with the .NET CLI.

Shell integration and managed environment

  • dotnetup can modify shell profile files (example: detects zsh).
  • It ensures:
    • dotnetup itself and the managed dotnet executable are on PATH.
  • It provides commands like:
    • netup info (version/environment details)
    • net info (the active installed .NET SDK/runtime details)

Demo 1: Repo-specific SDK selection using global.json

  • A sample repo contains global.json specifying an SDK feature band (e.g., “100 feature band”).
  • Behavior shown:
    • netup sdk install installs an SDK compatible with the repo’s global.json.
    • If global.json says a specific band, dotnetup installs that band.
    • Example of “why”:
      • dotnetup can roll forward or explain the decision depending on global.json values.
  • Core capability: one command to make a developer’s local environment match the repo’s SDK requirements:
    • Clone repo → run netup install / netup sdk install → build/test works.

Demo 2: Runtime-focused installs (without installing many SDKs)

  • Common issue described:
    • Developers want the latest SDK tooling but tests must run against multiple target runtimes.
    • In current practice, people often install multiple SDKs in CI to get runtimes for test execution.
    • Example outcome: running tests targeting net8/net9/net10 fails when corresponding runtimes aren’t present (only net10 works).
  • dotnetup capability:
    • Installing runtimes independently of installing extra SDKs.
  • Demonstrated commands:
    • netup runtime install 8, 9, 10 (or component-like specifiers such as ASP.NET variants)
    • It selects latest patches within each requested major/minor “band.”
  • A “future syntax” was hinted:
    • extended global.json-like spec to request runtimes (not finalized yet).

dotnetup tracking, updates, and cleanup

  • netup list shows what was installed and the channels/requests that caused it.
  • netup update reconciles installed versions with the desired tracked state.
  • Maintains a manifest/tracker in the user directory (described like a lock file for desired state).
  • Uninstall support included:
    • Updates remove out-of-date SDKs/runtimes that are no longer required by the declared state.
    • Explicit manual uninstall commands also supported.
  • Architecture:
    • Supports top-level commands:
      • install / update / uninstall
    • and component-level variants:
      • netup sdk install, etc.
    • Future direction: treat SDK “pieces” like components (similar to Rustup concept).

Roadmap and preview milestones

Internal preview (next couple weeks; stated goal)

  • Focus on managing stable SDKs.
  • Mentioned pipeline work enabling management of daily/nightly SDKs.
  • Planned “oneshot execution” concept:
    • a command like netup.net to run a command using a specific .NET version without changing the global install
    • Enables A/B comparison (e.g., compare dotnet build using 10.3.0 vs 11 preview).

Public preview (before end of summer; stated goal)

  • dotnetup will be able to self-update securely (like az/Aspire CLI style behavior).
  • Update checks/notifications for both:
    • dotnetup
    • installed SDKs/runtimes
  • Emphasizes:
    • signature verification for stable releases (SDK/runtime tooling and dotnet itself)
    • stronger supply-chain safety / auditability
  • “Agent skills” integration:
    • planned publication to net/skills so LLM/automation agents can use dotnetup safely.

GA (longer term; “fit and finish”)

  • Official docs and likely support as an official .NET website install method.
  • Expand global.json usage for runtime management.
  • Longer-term vision:
    • potentially factor SDK shipping into components to enable faster update cycles.
    • integrate with existing CI/CD tools to unify experience/performance:
      • GitHub Actions setup-dotnet
      • Azure DevOps .NET Tool Installer equivalent (UseDotNet is referenced in spirit)

Key calls to action (where to try and give feedback)

  • Get started docs:
    • aams.netupdoccks (getting started snippet with copy/paste scripts)
  • Design spec:
    • link to NetUp design spec
  • Feedback channel:
    • netup/feedback (discussion board category in the .NET SDK repo)
  • Samples repo:
    • github.com/baronfellnetup/repo patterns demo (contains the demo repo patterns and related GitHub Actions)

Main speaker(s) / sources

  • Chad Husk — working on the .NET SDK and presenting dotnetup.

Original video