Changes look good, sorta of related question, is there any kind of test we can add to guard against these precedence changes being incorrect?

I'm not sure, I wasn't aware of them until today. Short of waiting for an SDK that ingests them, maybe @MichalPavlik or @vlada-shubina would have an idea?

Or maybe we just ask CTI to add a scenario where they have 6.0 and 7.0 installed, and run dotnet new, I believe that would catch it right since it would install the wrong version? We could automate that but that's much harder for us to do with our tests and the versioning hell than just verifying this on real builds

Or maybe we just ask CTI to add a scenario where they have 6.0 and 7.0 installed, and run dotnet new, I believe that would catch it right since it would install the wrong version? We could automate that but that's much harder for us to do with our tests and the versioning hell than just verifying this on real builds

We could, but we'd still need to wait until there's an SDK that has ingested our change - I'm not sure if there's way to do it in this repo in isolation

Yeah that's fine, basically we merge this as is, and then ask CTI to add a scenario for this to start testing once the changes are actually in

Changes look good, sorta of related question, is there any kind of test we can add to guard against these precedence changes being incorrect?

I'm not sure, I wasn't aware of them until today. Short of waiting for an SDK that ingests them, maybe @MichalPavlik or @vlada-shubina would have an idea?

We have an idea of enabling template validation via MSBuild tasks: dotnet/templating#3828, however it might not meet the bar in near future. MSBuild tasks package is already in use in several repos for localization and we are onboarding others, so it's a matter of adding validation logic to them to report error/warnings in templates during the build. Detecting precedence / identity clashes is a bit tricky as in these scenarios error is over 2 or more packages, not individual templates inside same packages, but still detecting it is possible.

@halter73 is there a general issue affecting acquisition of Windows build agents❔

I found another PR that was similarly affected. I retriggered the canceled builds.

/backport to release/7.0-preview1

Started backporting to release/7.0-preview1: https://github.com/dotnet/aspnetcore/actions/runs/1753319370

@wtgodbe backporting to release/7.0-preview1 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: Update submodule
Using index info to reconstruct a base tree...
M	src/submodules/spa-templates
Falling back to patching base and 3-way merge...
Failed to merge submodule src/submodules/spa-templates (not checked out)
Auto-merging src/submodules/spa-templates
CONFLICT (submodule): Merge conflict in src/submodules/spa-templates
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Update submodule
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!