[release/11.0.1xx-preview1] Source code updates from dotnet/dotnet#52727
Conversation
|
@dsplaisted could you please help to take a look at this issue? System.Exception : The following additional unexpected assets were found in the manifest:
|
|
The runtime team is currently adding support for ZStandard compression to .NET, so I do expect to see a new assembly. |
…review1-d8c0b1db-1909-4ac4-9af3-6a64d1e2f3d7
|
@dotnet/aspnet-blazor-eng A bunch of blazor tests are failing with an exception out of a task. Can someone investigate?
@dotnet/run-file Microsoft.DotNet.Cli.Run.Tests.RunFileTests.Microsoft.DotNet.Cli.Run.Tests.RunFileTests.CscArguments is failing. Can someone take a look? This may be due to the addition of System.IO.Compression.ZStandard.dll. Thanks. |
|
Important While this PR was open, the source repository has received code changes from this repository (an opposite codeflow merged). You can continue with one of the following options:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
|
@dsplaisted The Blazor MSBuild crash is a known and already-fixed bug in MSBuild: Root Cause:
The bug is in This was exposed by the new Resolution: This is not a regression caused by the MSBuild changes in this PR - rather, those changes exposed a pre-existing latent bug that was independently discovered and fixed. |
@lewing notice that the crash in In my situation this happened when tasks started using the new Runtime="NET" support on UsingTask in non sdk-style project. This likely means that there's a real regression in the product that will impact customers when they start using P1. |
@ViktorHofer I think @maraf switched the task at your suggestion so what is the recommendation? |
|
The |
for reference dotnet/runtime#123304 |
|
I think using netcore taskhost in the SDK today may be a bit premature. Ideal fix is probably reverting dotnet/runtime#123304 (for now). |
|
|
Spitballing, but I wonder if the VS installation on this queue is slightly stale and has some other MSBuild-side bug. |
looks like |
…review1-d8c0b1db-1909-4ac4-9af3-6a64d1e2f3d7
| $"/reference:{DotNetRootPath}/packs/Microsoft.NETCore.App.Ref/{RuntimeVersion}/ref/net{TargetFrameworkVersion}/System.IO.Compression.dll", | ||
| $"/reference:{DotNetRootPath}/packs/Microsoft.NETCore.App.Ref/{RuntimeVersion}/ref/net{TargetFrameworkVersion}/System.IO.Compression.FileSystem.dll", | ||
| $"/reference:{DotNetRootPath}/packs/Microsoft.NETCore.App.Ref/{RuntimeVersion}/ref/net{TargetFrameworkVersion}/System.IO.Compression.ZipFile.dll", | ||
| $"/reference:{DotNetRootPath}/packs/Microsoft.NETCore.App.Ref/{RuntimeVersion}/ref/net{TargetFrameworkVersion}/System.IO.Compression.Zstandard.dll", |
There was a problem hiding this comment.
@jjonescz does this impact P1 meaning we should fix this for the produced P1 SDK?
There was a problem hiding this comment.
Aside from that, are there any plans to avoid these hardcodes?
There was a problem hiding this comment.
does this impact P1 meaning we should fix this for the produced P1 SDK?
If the DLL is supposed to be in P1, then without this change it won't be referenced by file-based apps that skip builds, yeah. (Sounds like a low priority edge case to me though.)
Aside from that, are there any plans to avoid these hardcodes?
That would be straightforward to do technically I think but I would rather avoid that, that's why I chose this hard-coding in the first place; I have seen several times before that some unintended changes tried to slip through here - if this was automated, no-one would notice that. Also we only hardcode here the set of CSC arguments for the simplest command-line app. That should hardly ever change - if there is large change it's probably a bug - and so it seems like a good test in general to have (not just for file-based apps).
There was a problem hiding this comment.
Looks like you hardcode all reference assemblies that are part of the microsoft.netcore.app.ref targeting pack. That will always change (grow). The source of truth is the ref pack's FrameworkList.xml file which provides the list of assemblies to reference and the TargetFrameworkVersion.
cc @ericstj for the ref pack
There was a problem hiding this comment.
I see, we can use that xml file instead of hardcoding the list of references, that makes sense to me.
There was a problem hiding this comment.
What is this thing doing?
This is an optimization used by file-based apps. It can skip MSBuild and run just the compiler for simple apps which are equivalent to dotnet new console. That might seem limited but it's a very common scenario for file-based apps.
Anything that approximates that is bound to diverge.
We are not trying to approximate here, this should be precisely what MSBuild would do for that exact same simple app, we have tests for that.
There was a problem hiding this comment.
does the user have a way to target net10.0 with this? the System.IO.Compression.Zstandard.dll won't exist in that reference pack and looks like it'd also set NET11_0_OR_GREATERdefine
There was a problem hiding this comment.
does the user have a way to target net10.0 with this?
They can set #:property TargetFramework=net10.0 or use Directory.Build.props or something like that - all of which will skip that optimized path (which uses hard-coded CSC args) and fallback to full MSBuild instead.
There was a problem hiding this comment.
@jjonescz since this PR is already merged, please file a tracking issue to capture our feedback around avoiding hardcodes
…#123973) This reverts PR #123304 (commit 46c884e). ## Reverted Changes - Restores multi-targeting for Microsoft.NET.Sdk.WebAssembly.Pack.Tasks (net11.0 + net472) - Restores \_WebAssemblySdkTasksTFM\ property and MSBuildRuntimeType-based TFM selection - Restores \TaskFactory=\"TaskHostFactory\"\ instead of \Runtime=\"NET\"\ for UsingTask declarations - Restores TFM-specific paths in NuGet package layout ## Reason for Revert Per discussion in dotnet/sdk#52727 (comment): The \Runtime=\"NET\"\ feature for UsingTask is currently **only supported with SDK-style projects** (see dotnet/msbuild#12895). Using it in the WebAssembly SDK tasks causes failures when these tasks are invoked from non-SDK-style projects. Additionally, the .NET Runtime Task Host infrastructure is still maturing, and using it in the SDK at this time is premature. This was causing Blazor test failures in the SDK repo where tasks would crash with \ArgumentNullException\ when the .NET Runtime Task Host couldn't be found. This revert restores the previous behavior using \TaskFactory=\"TaskHostFactory\"\ with TFM-based task assembly selection, which works reliably across both SDK-style and non-SDK-style projects. The \Runtime=\"NET\"\ approach can be revisited once MSBuild has broader support for this feature. Related: - dotnet/msbuild#12895 - Runtime=\"NET\" only works with SDK-style projects - dotnet/msbuild#13150 - MSBuild crash when wrapping exceptions (fixed but not yet in preview1)
|
@lewing @rainersigwald most of the test failures are still in the blazor wasm tests. Did you end up landing on a solution for that? |
|
It got reverted in dotnet/runtime#123974, so maybe the VMR flow is slightly stale here? |
|
@rainersigwald Yes, confirmed — the codeflow is still stale from that point. The revert landed in the VMR but never flowed into this PR. Timeline:
The in-progress build (1283475) will likely hit the same Blazor WASM Options to unblock:
|
|
@dotnet/prodconsvcs force triggering the subscription is doing nothing. |
## Summary Adds a new Copilot Agent Skill (`.github/skills/vmr-codeflow-status/`) that automates analysis of VMR codeflow PR health for dotnet repositories. Handles both backflow (VMR → product repos) and forward flow (product repos → VMR). ### What it does **PR Analysis Mode:** 1. **Parses PR metadata** — Extracts VMR commit, subscription ID, build info from the PR body 2. **Validates snapshot** — Cross-references PR body commit against branch "Backflow from" commit messages to detect stale metadata 3. **Checks freshness** — Compares PR's snapshot against the current source branch HEAD, showing how many commits behind and which repos have updates 4. **Shows pending forward flow** — For behind backflow PRs, finds open forward flow PRs that would close part of the freshness gap 5. **Detects staleness & conflicts** — Finds Maestro "codeflow cannot continue" warnings and "Conflict detected" messages (with conflicting files and resolve commands) 6. **Analyzes PR commits** — Categorizes commits as auto-updates vs manual (which would be lost on close/force-trigger) 7. **Traces fixes** (optional) — Checks if a specific fix PR has flowed through VMR into the codeflow PR 8. **Recommends actions** — Suggests force trigger, close/reopen, merge as-is, resolve conflicts, or wait, with ready-to-use darc commands **Missing Backflow Mode:** - Discovers all branches with backflow subscriptions by examining recently merged PRs - Compares VMR branch HEAD against the last merged backflow commit - Flags branches where the VMR has moved but no new backflow PR exists - Warns when Maestro may be stuck (>6 hours since last merge with VMR ahead) ### Example Prompts - "check the codeflow status of dotnet/sdk#52727" - "is #124098 up to date with the VMR?" - "has the runtime revert in #123974 reached the codeflow PR dotnet/sdk#52727?" - "why is this codeflow PR blocked?" - "are there any missing backflow PRs for dotnet/roslyn?" - "report on the codeflow status for dotnet/aspnetcore" - "what forward flow PRs are pending for the preview1 VMR branch?" ### Motivation Investigating stale codeflow PRs is a common and tedious task — checking VMR freshness, finding staleness warnings, tracing whether specific fixes have flowed through. This skill automates the entire workflow and provides actionable darc commands. Tested against 10+ codeflow PRs across dotnet/sdk, dotnet/runtime, dotnet/roslyn, dotnet/aspnetcore, and dotnet/dotnet on multiple branches (main, preview1, release/10.0.x). ### Files - `SKILL.md` — Skill definition with frontmatter (matching existing skills in this repo) - `scripts/Get-CodeflowStatus.ps1` — Main analysis script (~750 lines) - `references/vmr-codeflow-reference.md` — Reference docs (VMR concepts, darc CLI, API endpoints)
for reference use dotnet/runtime#124109 for this kind of analysis |
hours ago |
lewing
deleted the
darc-release/11.0.1xx-preview1-d8c0b1db-1909-4ac4-9af3-6a64d1e2f3d7
branch
…ackflow (#124129) ## Version.Details.xml as primary VMR snapshot source + forward flow scanning ### Problem The codeflow status script relied on PR body metadata and commit messages to determine the VMR snapshot. When manual backflow was used (e.g., \darc vmr backflow\ pushed directly), the PR body was stale and commit messages didn't follow the expected format, causing incorrect freshness reporting. ### Changes **Commit 1: VD.xml as primary snapshot** - \�ng/Version.Details.xml\ (\<Source Sha=...>\) is now checked first as the authoritative snapshot source - XML parser with regex fallback, 40-char SHA validation - Commit messages are secondary confirmation, PR body is last resort - Case-insensitive SHA comparison throughout - \2>\\\ for stderr isolation on all \gh\ calls **Commit 2: Forward flow scanning in -CheckMissing** - \-CheckMissing\ now scans open forward flow PRs (product repo → dotnet/dotnet) - Detects conflicts and staleness via Maestro comment scanning - Combined summary showing backflow + forward flow health ### Testing - VD.xml: Tested against sdk#52727 (manual backflow mismatch), sdk#52885 (conflicted), aspnetcore#65338 (deleted branch), runtime#124098 (normal), sourcelink#1581 (fresh) - Forward flow: Tested against dotnet/sdk (4 PRs: 2 healthy, 1 stale, 1 conflict) and dotnet/runtime (3 PRs: 2 healthy, 1 stale) Cross-repo context: dotnet/sdk#52727, dotnet/sdk#52885
…dotnet#123973) This reverts PR dotnet#123304 (commit 46c884e). ## Reverted Changes - Restores multi-targeting for Microsoft.NET.Sdk.WebAssembly.Pack.Tasks (net11.0 + net472) - Restores \_WebAssemblySdkTasksTFM\ property and MSBuildRuntimeType-based TFM selection - Restores \TaskFactory=\"TaskHostFactory\"\ instead of \Runtime=\"NET\"\ for UsingTask declarations - Restores TFM-specific paths in NuGet package layout ## Reason for Revert Per discussion in dotnet/sdk#52727 (comment): The \Runtime=\"NET\"\ feature for UsingTask is currently **only supported with SDK-style projects** (see dotnet/msbuild#12895). Using it in the WebAssembly SDK tasks causes failures when these tasks are invoked from non-SDK-style projects. Additionally, the .NET Runtime Task Host infrastructure is still maturing, and using it in the SDK at this time is premature. This was causing Blazor test failures in the SDK repo where tasks would crash with \ArgumentNullException\ when the .NET Runtime Task Host couldn't be found. This revert restores the previous behavior using \TaskFactory=\"TaskHostFactory\"\ with TFM-based task assembly selection, which works reliably across both SDK-style and non-SDK-style projects. The \Runtime=\"NET\"\ approach can be revisited once MSBuild has broader support for this feature. Related: - dotnet/msbuild#12895 - Runtime=\"NET\" only works with SDK-style projects - dotnet/msbuild#13150 - MSBuild crash when wrapping exceptions (fixed but not yet in preview1)
## Summary Adds a new Copilot Agent Skill (`.github/skills/vmr-codeflow-status/`) that automates analysis of VMR codeflow PR health for dotnet repositories. Handles both backflow (VMR → product repos) and forward flow (product repos → VMR). ### What it does **PR Analysis Mode:** 1. **Parses PR metadata** — Extracts VMR commit, subscription ID, build info from the PR body 2. **Validates snapshot** — Cross-references PR body commit against branch "Backflow from" commit messages to detect stale metadata 3. **Checks freshness** — Compares PR's snapshot against the current source branch HEAD, showing how many commits behind and which repos have updates 4. **Shows pending forward flow** — For behind backflow PRs, finds open forward flow PRs that would close part of the freshness gap 5. **Detects staleness & conflicts** — Finds Maestro "codeflow cannot continue" warnings and "Conflict detected" messages (with conflicting files and resolve commands) 6. **Analyzes PR commits** — Categorizes commits as auto-updates vs manual (which would be lost on close/force-trigger) 7. **Traces fixes** (optional) — Checks if a specific fix PR has flowed through VMR into the codeflow PR 8. **Recommends actions** — Suggests force trigger, close/reopen, merge as-is, resolve conflicts, or wait, with ready-to-use darc commands **Missing Backflow Mode:** - Discovers all branches with backflow subscriptions by examining recently merged PRs - Compares VMR branch HEAD against the last merged backflow commit - Flags branches where the VMR has moved but no new backflow PR exists - Warns when Maestro may be stuck (>6 hours since last merge with VMR ahead) ### Example Prompts - "check the codeflow status of dotnet/sdk#52727" - "is dotnet#124098 up to date with the VMR?" - "has the runtime revert in dotnet#123974 reached the codeflow PR dotnet/sdk#52727?" - "why is this codeflow PR blocked?" - "are there any missing backflow PRs for dotnet/roslyn?" - "report on the codeflow status for dotnet/aspnetcore" - "what forward flow PRs are pending for the preview1 VMR branch?" ### Motivation Investigating stale codeflow PRs is a common and tedious task — checking VMR freshness, finding staleness warnings, tracing whether specific fixes have flowed through. This skill automates the entire workflow and provides actionable darc commands. Tested against 10+ codeflow PRs across dotnet/sdk, dotnet/runtime, dotnet/roslyn, dotnet/aspnetcore, and dotnet/dotnet on multiple branches (main, preview1, release/10.0.x). ### Files - `SKILL.md` — Skill definition with frontmatter (matching existing skills in this repo) - `scripts/Get-CodeflowStatus.ps1` — Main analysis script (~750 lines) - `references/vmr-codeflow-reference.md` — Reference docs (VMR concepts, darc CLI, API endpoints)
10 participants
Note
This is a codeflow update. It may contain both source code changes from
the VMR
as well as dependency updates. Learn more here.
This pull request brings the following source code changes
From https://github.com/dotnet/dotnet
Updated Dependencies
Associated changes in source repos
Diff the source with this PR branch