Design document: Installing daily/nightly builds with dotnetup by dsplaisted · Pull Request #54061 · dotnet/sdk

dsplaisted · 2026-04-24T04:38:49Z

Summary

Design document for adding daily/nightly build support to dotnetup (SDK issue #51097).

Key design decisions

Daily builds are channels, not a separate --quality flag — dotnetup sdk install 10.0-daily uses the same mental model as dotnetup sdk install latest
Channel syntax: {version-scope}-daily suffix (e.g., 10.0-daily, 10.0.1xx-daily, or bare daily)
Version discovery: aka.ms redirect for latest daily, blob-feed download with .sha512 hash verification
No changes to InstallWorkflow — daily logic lives behind existing ChannelVersionResolver and IArchiveDownloader abstractions
Phase ordering: (1) specific prerelease version install from blob feed, (2) daily channel parsing + latest version resolution, (3) list/browse via NuGet transport package feeds
Daily builds are NOT code-signed — design documents the weaker trust model

Open questions for review

global.json interaction with daily builds
--feed override for internal scenarios
Runtime transport package selection (VMR versions together)
Naming: daily vs nightly alias
Runtime URL patterns
Host allowlist for redirects
Feed retry order
Channel separator: - (current) vs /
Supporting other quality levels (signed, validated)

Resolves #51097

Adds initial design document for installing pre-release (daily/nightly) builds via dotnetup, addressing SDK issue dotnet#51097. Key design decisions: - Uses 'daily' terminology matching dotnet-install scripts - CLI syntax: --quality daily flag alongside channel argument - Manifest tracks quality and feedKind fields - Daily builds do not auto-update by default - Security: host allowlist, TLS-only, weaker trust model acknowledged - 4 implementation phases: data model, specific version, channel+quality, listing Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Simplifies the design by expressing daily builds as channel names (daily/10.0) rather than a separate --quality flag. This means: - No new CLI flag needed - Manifest schema unchanged (channel name encodes daily nature) - GC/update logic distinguishes daily vs stable by channel prefix - Implementation reduced from 4 phases to 3 Also incorporates rubber-duck review feedback: - Restrict blob-feed fallback to prerelease versions only - Add security/trust model section with host allowlist - Add channel parsing sketch for UpdateChannel class Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Changes channel syntax from prefix (daily/10.0) to suffix (10.0/daily). The version scope comes first, then /daily qualifies it. This reads more naturally and mirrors how existing channels work: start with what you want, then narrow it. Examples: daily, 10.0/daily, 10.0.1xx/daily Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Corrects the version discovery mechanism based on reading the actual dotnet-install.sh source code. The aka.ms link redirects directly to the archive blob (not a version file), and the version is extracted from the redirect URL path. There is no fallback when quality is specified — aka.ms failure is terminal. The latest.version file is a separate legacy mechanism used only when no quality is specified. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Daily builds are the lowest quality level in the .NET build pipeline (daily -> signed -> validated -> preview -> ga). Code signing happens at the 'signed' level, not 'daily'. Updated the archive signatures section to reflect this and added open question about supporting other quality levels like 'signed' and 'validated'. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

InstallWorkflow shouldn't need to know whether a channel is daily or released. The ChannelVersionResolver and DotnetArchiveDownloader should handle the daily/release distinction internally based on the channel name, just as they already abstract away the release manifest details today. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The tool was renamed from dnup to dotnetup. Update all command examples and prose references to use the current name. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Specific version installs are simpler (the user provides the exact version, no discovery needed) so they make a better Phase 1. Daily channel resolution (aka.ms redirect) layers on top of the blob-feed download path established in Phase 1. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Query the NuGet feed for Microsoft.NET.Sdk package versions to enumerate available daily SDK builds. Each daily build publishes a transport package whose version matches the SDK version. Runtime components would use a different transport package (TBD). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

With the VMR, any VMR-produced package can serve as the version index for runtime daily builds since all components are in sync. A candidate like Microsoft.NETCore.App.Runtime.{rid} would work. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Feed URLs are calculated from the major version (dotnet{N}-transport), not read from NuGet.config. dotnetup queries the NuGet V3 protocol directly against the public Azure DevOps feeds. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Use the release manifest as an anchor: find the latest released major version, probe major+1 transport feed for daily builds, fall back to the released major version's feed if major+1 doesn't exist yet. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The dash is simpler and aligns with prerelease version tag conventions. No ambiguity with versions since channels use major.minor (2 components) or feature bands with wildcards. Keep / as an alternative in open question 8 for team discussion. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Readers see the proposed UX (commands and channel table) right after the motivation, before diving into background and technical design details. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Adds a design document describing how dotnetup could support installing daily/nightly (pre-release) .NET SDK/runtime builds, including proposed UX, version discovery, trust model, and phased implementation plan.

Changes:

Documents a channel-based UX for daily builds (e.g., daily, 10.0-daily, 10.0.1xx-daily) without adding a separate --quality flag.
Proposes aka.ms redirect-based version discovery and blob-feed downloads with .sha512 verification.
Outlines phased implementation steps and key security/trust considerations (redirect allowlist, transparency, etc.).

Copilot · 2026-04-24T04:42:33Z

+- Extend `UpdateChannel` with `IsDaily` / `BaseChannel` properties for `...-daily` suffix parsing
+- Add `IsValidChannelFormat()` support for `...-daily` channels


Phase 2 calls out extending IsValidChannelFormat() for ...-daily channels, but the proposed UX also includes bare daily. Make sure the design explicitly includes how bare daily will pass channel validation (e.g., adding daily to the known keyword set) so the implementation checklist is complete.

Suggested change

- Extend `UpdateChannel` with `IsDaily` / `BaseChannel` properties for `...-daily` suffix parsing

- Add `IsValidChannelFormat()` support for `...-daily` channels

- Extend `UpdateChannel` with `IsDaily` / `BaseChannel` properties for `...-daily` suffix parsing,

and define how bare `daily` maps through the same model

- Add `IsValidChannelFormat()` support for `...-daily` channels and bare `daily` (for example,

by adding `daily` to the known channel keyword set)

… channel validation - Fix aka.ms URL to use {base}/{quality} split (10.0/daily) matching the documented pattern - Return 'daily' (not 'latest') as BaseChannel for bare daily channel - Update manifest example to use actual InstallSpec schema (component, versionOrChannel, installSource) - Explicitly include bare 'daily' in IsValidChannelFormat() checklist Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- OQ1: Incorporated into main text — global.json prerelease versions naturally fall back to daily feed via Phase 1 behavior - OQ5: Incorporated into aka.ms redirect section — documented all component archive prefixes and runtime version differences - Removed resolved questions, renumbered remaining (now 1-7) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

baronfel

This looks great overall! I left a few questions, but the core question I have is if we want to rely on the aka.ms infrastructure directly. If we already have/need the ability to query the package versions, then the marker version files don't matter (and they may get out of date due to delayed build publishing!). In addition, if the pipelines are public, we should be able to acquire the appropriate installer payload from azdo artifacts.

baronfel · 2026-04-30T14:04:19Z

+   `daily → signed → validated → preview → ga`. Should dotnetup support `10.0-signed` or
+   `10.0-validated` channels? `signed` builds are code-signed but not fully validated —


Should dotnetup support 10.0-signed or 10.0-validated channels?

No, we can skip these for this feature

baronfel · 2026-04-30T14:06:17Z

+
+## Open questions
+
+1. **Should there be a `--feed` override?** For internal scenarios, users might want to point at


I don't think we need to worry about external feeds for daily support. If a user wants to point to alternative feeds, they should be able to construct their own release manifest and use that, I'd expect.

dsplaisted · 2026-04-30T14:31:08Z

This looks great overall! I left a few questions, but the core question I have is if we want to rely on the aka.ms infrastructure directly. If we already have/need the ability to query the package versions, then the marker version files don't matter (and they may get out of date due to delayed build publishing!). In addition, if the pipelines are public, we should be able to acquire the appropriate installer payload from azdo artifacts.

@baronfel Interesting. I think it might make sense to stick with the aka.ms logic that the install scripts are using to get started. That seems easier and lower risk to get the basic functionality out.

Getting payloads from azdo artifacts sounds like it would make it really easy to add the feature where you can install a build from a PR, which would be great. But I would still keep it simple for the initial implementation.

baronfel · 2026-04-30T14:58:33Z

Totally fair - let's get your plan in motion then!

nagilson · 2026-05-04T18:46:24Z

We can add the --skip-sign-check flag for daily builds if it contains warning text.
Registry key policy should be able to disable the flag on Windows and likely a root only writeable file or /etc/conf

dsplaisted and others added 14 commits April 23, 2026 23:57

Replace dnup with dotnetup throughout design doc

d2cd6f0

The tool was renamed from dnup to dotnetup. Update all command examples and prose references to use the current name. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Move user experience / CLI examples to front of document

af34b57

Readers see the proposed UX (commands and channel table) right after the motivation, before diving into background and technical design details. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings April 24, 2026 04:38

Copilot started reviewing on behalf of dsplaisted April 24, 2026 04:39 View session

Copilot AI reviewed Apr 24, 2026

View reviewed changes

marcpopMSFT added the dotnetup Work items around the proposed `dotnetup` bootstrapper/toolchain management tool and library label Apr 28, 2026

dsplaisted and others added 2 commits April 29, 2026 10:13

baronfel approved these changes Apr 30, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Design document: Installing daily/nightly builds with dotnetup#54061

Design document: Installing daily/nightly builds with dotnetup#54061
dsplaisted wants to merge 16 commits intodotnet:release/dnupfrom
dsplaisted:dotnetup-nightly-design

dsplaisted commented Apr 24, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 24, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

baronfel left a comment

Uh oh!

baronfel Apr 30, 2026

Uh oh!

baronfel Apr 30, 2026

Uh oh!

dsplaisted commented Apr 30, 2026

Uh oh!

baronfel commented Apr 30, 2026

Uh oh!

nagilson commented May 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

		- Extend `UpdateChannel` with `IsDaily` / `BaseChannel` properties for `...-daily` suffix parsing
		- Add `IsValidChannelFormat()` support for `...-daily` channels

-- Extend `UpdateChannel` with `IsDaily` / `BaseChannel` properties for `...-daily` suffix parsing
-- Add `IsValidChannelFormat()` support for `...-daily` channels
+- Extend `UpdateChannel` with `IsDaily` / `BaseChannel` properties for `...-daily` suffix parsing,
+  and define how bare `daily` maps through the same model
+- Add `IsValidChannelFormat()` support for `...-daily` channels and bare `daily` (for example,
+  by adding `daily` to the known channel keyword set)

		`daily → signed → validated → preview → ga`. Should dotnetup support `10.0-signed` or
		`10.0-validated` channels? `signed` builds are code-signed but not fully validated —


		## Open questions

		1. Should there be a `--feed` override? For internal scenarios, users might want to point at

Conversation

dsplaisted commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Key design decisions

Open questions for review

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

baronfel left a comment

Choose a reason for hiding this comment

Uh oh!

baronfel Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

baronfel Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

dsplaisted commented Apr 30, 2026

Uh oh!

baronfel commented Apr 30, 2026

Uh oh!

nagilson commented May 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dsplaisted commented Apr 24, 2026 •

edited

Loading