Skip to content

Reference: How Inspect Web acquires coherent .NET 12 daily SDK and Wasm builds #7488

Open

Description

@richlander

Purpose

This issue documents the reproducible flow Inspect Web uses to discover and acquire a coherent .NET 12 daily SDK, runtime, and browser-Wasm workload. It is intended as a shareable reference; the checked-in pin remains the source of truth.

Sources

Role Source
Authoritative daily identity https://aka.ms/dotnet/12.0/daily/productCommit-linux-x64.json
Redirected daily metadata https://ci.dot.net/public/Sdk/<sdk-version>/productCommit-linux-x64.json
Exact SDK installer dotnetup, bootstrapped from https://aka.ms/dotnet/dotnetup/daily/get-dotnetup.sh
.NET 12 workload/runtime packages https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet12/nuget/v3/index.json
Ordinary package dependencies https://api.nuget.org/v3/index.json

The authoritative metadata names one SDK version, runtime version, and dotnet/dotnet VMR commit. We treat that response as one immutable candidate snapshot rather than independently floating those components.

Acquisition flow

  1. Fetch productCommit-linux-x64.json from the .NET 12 daily endpoint once.

  2. Require the SDK, runtime, ASP.NET Core, and Windows Desktop entries to name one VMR commit. Require matching SDK/runtime daily suffixes and monotonic advancement over the checked-in pin.

  3. Install the exact candidate SDK version into an isolated directory with dotnetup:

    dotnetup sdk install "$candidate_sdk" \
      --install-path "$DOTNET_ROOT" \
      --untracked \
      --set-default-install false \
      --interactive false
  4. Pin that exact SDK through global.json with roll-forward disabled.

  5. Install the browser-Wasm workload without refreshing manifests:

    dotnet workload install wasm-tools \
      --skip-manifest-update \
      --source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet12/nuget/v3/index.json \
      --source https://api.nuget.org/v3/index.json
  6. Validate the installed workload before using it:

    • the workload manifest version equals the SDK version;
    • its direct pack inventory equals the checked-in policy;
    • every selected Wasm pack uses the candidate runtime version;
    • Microsoft.NET.Sdk.WebAssembly.Pack identifies the expected dotnet/dotnet repository and VMR commit; and
    • dotnet --list-runtimes exposes exactly the candidate runtime version.
  7. Build Mono, CoreCLR IL, and CoreCLR ReadyToRun from one product commit and one shared frontend. Admit and measure only artifacts whose receipts preserve the exact SDK, runtime, workload, feed, VMR, and source identities.

  8. Create a proposal branch only after the complete controlled cohort satisfies its admission contract. The branch may change only inspect-web/runtime-cohort-pin.json.

Checked-in owner

inspect-web/runtime-cohort-pin.json owns:

  • the discovery endpoint and RID;
  • exact SDK and runtime versions;
  • the dotnet/dotnet VMR commit;
  • workload ID, target framework, manifest, and direct pack inventory; and
  • the daily and NuGet.org feeds.

The current design deliberately uses the .NET 12 runtime with the net11.0 browser-Wasm workload packs because that is the target framework described by the selected browser workload. “.NET 12 daily” therefore does not mean independently selecting arbitrary SDK and Wasm packages; all identities must form one validated cohort.

Implementation

Part of #6077.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions