[vs18.6] Point OptProf bootstrapper at rel/stable instead of int.main - #13923
Merged
Conversation
vs18.6 stabilization should train OptProf against the VS channel that ships matching 18.6 bits, not the moving int.main channel. Training against int.main causes assembly-version drift (e.g. the C++ designtime build demanding System.Text.Json 10.0.0.4) and breaks OptProf collection. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the OptProf VS bootstrapper configuration in the Azure Pipelines build job so OptProf training targets the VS 18.6 shipping channel instead of the moving internal mainline channel, avoiding version drift during stabilization.
Changes:
- Switch
VisualStudio.ChannelNamefromint.maintorel/stablefor the VS bootstrapper build used by OptProf.
Contributor
There was a problem hiding this comment.
This is a correct and appropriate change for the vs18.6 stabilization branch. Switching VisualStudio.ChannelName from int.main to rel/stable ensures OptProf training targets the stable VS channel that ships the matching 18.6 bits, avoiding assembly-version drift (e.g. System.Text.Json version mismatches from int.main) that would break OptProf data collection. Single-line, clear intent, no side effects on C# code or MSBuild logic.
Generated by Expert Code Review (on open) for issue #13923 · sonnet46 936.9K
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
ViktorHofer
approved these changes
Jun 2, 2026
rainersigwald
requested changes
Jun 2, 2026
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
rainersigwald
approved these changes
Jun 3, 2026
AlesProkop
enabled auto-merge (squash)
June 3, 2026 14:10
Member
|
Merging on red since this change could not possibly break a test. |
rainersigwald
disabled auto-merge
June 3, 2026 14:30
This was referenced Jun 8, 2026
jankratochvilcz
added a commit
that referenced
this pull request
Jun 8, 2026
…#13993) ### Problem PR #13923 changed `VisualStudio.ChannelName` from `int.main` to `stable` to stop OptProf training against the moving `int.main` channel (which caused assembly-version drift, e.g. System.Text.Json 10.0.0.4). Since then the official build fails at **OptProf - Build VS bootstrapper**: > The drop url https://download.visualstudio.microsoft.com/.../VisualStudio.vsman is invalid. Expected the drop url to have the format {prefix};{suffix} ### Root cause The MicroBuild `MicroBuildBuildVSBootstrapper` task only special-cases the literal channel names **`release`** and **`preview`** as public channels. **Any other value — including `stable` — is assumed to be an *internal* channel** whose installer-manifest URL is a vsdrop drop in `{prefix};{suffix}` form. The public `stable` channel resolves (`aka.ms/vs/18/stable/channel`) to `VisualStudio.18.Release.chman`, whose installer-manifest URL is the public CDN `download.visualstudio.microsoft.com/.../VisualStudio.vsman` (no semicolon) -> the task throws. The relevant task logic (`CreateConfigFile`): https://dev.azure.com/devdiv/Engineering/_git/MicroBuild?path=/src/Tasks/BuildVSBootstrapper/plugin.ps1&line=286&lineEnd=307&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents ### Fix Use `release` instead of `stable`. Both resolve to the **same** public channel manifest (`VisualStudio.18.Release.chman`), so OptProf trains against the identical shipping bits — but `release` is one of the two special-cased names, so the task uses the aka.ms config template instead of attempting to parse a vsdrop URL. No behavioral change to trained bits; this only unblocks the bootstrapper build. Companion to #13992 (vs18.6).
jankratochvilcz
added a commit
that referenced
this pull request
Jun 8, 2026
…#13992) ### Problem PR #13923 changed `VisualStudio.ChannelName` from `int.main` to `stable` to stop OptProf training against the moving `int.main` channel (which caused assembly-version drift, e.g. System.Text.Json 10.0.0.4). Since then the official build fails at **OptProf - Build VS bootstrapper**: > The drop url https://download.visualstudio.microsoft.com/.../VisualStudio.vsman is invalid. Expected the drop url to have the format {prefix};{suffix} ### Root cause The MicroBuild `MicroBuildBuildVSBootstrapper` task only special-cases the literal channel names **`release`** and **`preview`** as public channels. **Any other value — including `stable` — is assumed to be an *internal* channel** whose installer-manifest URL is a vsdrop drop in `{prefix};{suffix}` form. The public `stable` channel resolves (`aka.ms/vs/18/stable/channel`) to `VisualStudio.18.Release.chman`, whose installer-manifest URL is the public CDN `download.visualstudio.microsoft.com/.../VisualStudio.vsman` (no semicolon) -> the task throws. The relevant task logic (`CreateConfigFile`): https://dev.azure.com/devdiv/Engineering/_git/MicroBuild?path=/src/Tasks/BuildVSBootstrapper/plugin.ps1&line=286&lineEnd=307&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents ### Fix Use `release` instead of `stable`. Both resolve to the **same** public channel manifest (`VisualStudio.18.Release.chman`), so OptProf trains against the identical shipping bits — but `release` is one of the two special-cased names, so the task uses the aka.ms config template instead of attempting to parse a vsdrop URL. No behavioral change to trained bits; this only unblocks the bootstrapper build. Companion to #13993 (vs18.7).
This was referenced Jun 8, 2026
rainersigwald
pushed a commit
that referenced
this pull request
Jun 8, 2026
…ase' (#14005) ### Problem The previous fix (#13992, `stable` -> `release`) was wrong. On the official build it fails with: > ##[error]Invalid JSON primitive: . because `release` is **not a valid channel moniker for VS 18**. `https://aka.ms/vs/18/release/channel` bounces to a Bing fallback page, which the bootstrapper task saves as the `.chman` and then fails to parse as JSON. ### Why `release` and `stable` are both wrong The aka.ms moniker convention changed between VS17 and VS18: | moniker | VS 17 | VS 18 | | --- | --- | --- | | `release` | real CDN manifest | bounces to bing.com (broken) | | `stable` | bounces to bing.com | real **public** CDN manifest (`VisualStudio.18.Release.chman`) | | `int.stable` | n/a | **internal vsdrop** manifest (`VisualStudio.18.int.stable.chman`) | So for VS 18 the public GA channel is `stable` (not `release`). But the MicroBuild `MicroBuildBuildVSBootstrapper` task's `CreateConfigFile` only special-cases the VS17-era public names `release`/`preview`. Any other name — including `stable` — is routed down the **internal** path, where it parses the installer-manifest URL as a vsdrop `{prefix};{suffix}` drop. `stable`'s public CDN URL has no semicolon, hence the original *"drop url ... is invalid"* failure. ### Fix Use **`int.stable`**: the **internal, vsdrop-backed** equivalent of `stable`. It tracks the stable 18.x bits (not the moving `int.main` that caused the System.Text.Json 10.0.0.4 drift in #13923), and because it is an internal channel its installer-manifest URL is a vsdrop `{prefix};{suffix}` URL that `CreateConfigFile` accepts. - `https://aka.ms/vs/18/int.stable/channel` resolves to `VisualStudio.18.int.stable.chman` on `vsdrop.microsoft.com` (verified). Relevant task logic (`CreateConfigFile`): https://dev.azure.com/devdiv/Engineering/_git/MicroBuild?path=/src/Tasks/BuildVSBootstrapper/plugin.ps1&line=286&lineEnd=307&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents Companion to #14006 (vs18.7). --- ### Local validation (verified before merge) Replicated every step the `MicroBuildBuildVSBootstrapper` task performs, using the same VSDrop token audience the task uses (per `plugin.ps1`): | Check | Result | Failure mode it rules out | | --- | --- | --- | | (a) `aka.ms/vs/18/int.stable/channel` redirects to **vsdrop** (not bing.com) | ✅ | the `release` "Invalid JSON primitive" (Bing fallback page) | | (b) `.chman` downloads and is valid JSON (11 channelItems) | ✅ | the `release` "Invalid JSON primitive" | | (c) installer-manifest URL splits into `{prefix};{suffix}` (2 parts) | ✅ | the `stable` "drop url ... is invalid" (`CreateConfigFile` `Split(";")` check) | | (d) config payload `…;bootstrappers/Enterprise/configuration/vs_setup_bootstrapper.config` returns **HTTP 200** (after the corp→ZTN host rewrite the task does) | ✅ | the only downstream config-download risk | | (bonus) installer `.vsman` downloads and parses (20,527 packages) | ✅ | the `vsman overlay` step input | This is the same code path `int.main` already runs successfully; `int.stable` only pins it to stable 18.x bits. > Note: the `int.stable` channel's installer manifest is named `VisualStudioIntPreview.vsman` (`...Channels.IntPreviewInstallerManifest`). That is just the drop's internal naming for the stable-pinned channel and does not affect correctness — all checks above passed. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
rainersigwald
pushed a commit
that referenced
this pull request
Jun 8, 2026
…ase' (#14006) ### Problem The previous fix (#13993, `stable` -> `release`) was wrong. On the official build it fails with: > ##[error]Invalid JSON primitive: . because `release` is **not a valid channel moniker for VS 18**. `https://aka.ms/vs/18/release/channel` bounces to a Bing fallback page, which the bootstrapper task saves as the `.chman` and then fails to parse as JSON. ### Why `release` and `stable` are both wrong The aka.ms moniker convention changed between VS17 and VS18: | moniker | VS 17 | VS 18 | | --- | --- | --- | | `release` | real CDN manifest | bounces to bing.com (broken) | | `stable` | bounces to bing.com | real **public** CDN manifest (`VisualStudio.18.Release.chman`) | | `int.stable` | n/a | **internal vsdrop** manifest (`VisualStudio.18.int.stable.chman`) | So for VS 18 the public GA channel is `stable` (not `release`). But the MicroBuild `MicroBuildBuildVSBootstrapper` task's `CreateConfigFile` only special-cases the VS17-era public names `release`/`preview`. Any other name — including `stable` — is routed down the **internal** path, where it parses the installer-manifest URL as a vsdrop `{prefix};{suffix}` drop. `stable`'s public CDN URL has no semicolon, hence the original *"drop url ... is invalid"* failure. ### Fix Use **`int.stable`**: the **internal, vsdrop-backed** equivalent of `stable`. It tracks the stable 18.x bits (not the moving `int.main` that caused the System.Text.Json 10.0.0.4 drift in #13923), and because it is an internal channel its installer-manifest URL is a vsdrop `{prefix};{suffix}` URL that `CreateConfigFile` accepts. - `https://aka.ms/vs/18/int.stable/channel` resolves to `VisualStudio.18.int.stable.chman` on `vsdrop.microsoft.com` (verified). Relevant task logic (`CreateConfigFile`): https://dev.azure.com/devdiv/Engineering/_git/MicroBuild?path=/src/Tasks/BuildVSBootstrapper/plugin.ps1&line=286&lineEnd=307&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents Companion to #14005 (vs18.6). --- ### Local validation (verified before merge) Replicated every step the `MicroBuildBuildVSBootstrapper` task performs, using the same VSDrop token audience the task uses | Check | Result | Failure mode it rules out | | --- | --- | --- | | (a) `aka.ms/vs/18/int.stable/channel` redirects to **vsdrop** (not bing.com) | ✅ | the `release` "Invalid JSON primitive" (Bing fallback page) | | (b) `.chman` downloads and is valid JSON (11 channelItems) | ✅ | the `release` "Invalid JSON primitive" | | (c) installer-manifest URL splits into `{prefix};{suffix}` (2 parts) | ✅ | the `stable` "drop url ... is invalid" (`CreateConfigFile` `Split(";")` check) | | (d) config payload `…;bootstrappers/Enterprise/configuration/vs_setup_bootstrapper.config` returns **HTTP 200** (after the corp→ZTN host rewrite the task does) | ✅ | the only downstream config-download risk | | (bonus) installer `.vsman` downloads and parses (20,527 packages) | ✅ | the `vsman overlay` step input | This is the same code path `int.main` already runs successfully; `int.stable` only pins it to stable 18.x bits. > Note: the `int.stable` channel's installer manifest is named `VisualStudioIntPreview.vsman` (`...Channels.IntPreviewInstallerManifest`). That is just the drop's internal naming for the stable-pinned channel and does not affect correctness — all checks above passed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Jul 9, 2026
This was referenced Aug 11, 2026
This was referenced Aug 19, 2026
Closed
Open
This was referenced Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
vs18.6 stabilization should train OptProf against the VS channel that ships matching 18.6 bits, not the moving int.main channel. Training against int.main causes assembly-version drift (e.g. the C++ designtime build demanding System.Text.Json 10.0.0.4) and breaks OptProf collection.