[automated] Merge branch 'release/10.0.1xx' => 'release/10.0.3xx'

[github-actions]

I detected changes in the release/10.0.1xx branch which have not been merged yet to release/10.0.3xx. I'm a robot and am configured to help you automatically keep release/10.0.3xx up to date, so I've opened this PR.

This PR merges commits made on release/10.0.1xx by the following committers:

• halter73
• DonnaChen888
• dotnet-maestro[bot]

Instructions for merging from UI

This PR will not be auto-merged. When pull request checks pass, complete this PR by creating a merge commit, not a squash or rebase commit.

If this repo does not allow creating merge commits from the GitHub UI, use command line instructions.

Instructions for merging via command line

Run these commands to merge this pull request from the command line.

git fetch
git checkout release/10.0.1xx
git pull --ff-only
git checkout release/10.0.3xx
git pull --ff-only
git merge --no-ff release/10.0.1xx

# If there are merge conflicts, resolve them and then run git merge --continue to complete the merge
# Pushing the changes to the PR branch will re-trigger PR validation.
git push https://github.com/dotnet/sdk HEAD:merge/release/10.0.1xx-to-release/10.0.3xx

or if you are using SSH

git push git@github.com:dotnet/sdk HEAD:merge/release/10.0.1xx-to-release/10.0.3xx

After PR checks are complete push the branch

git push

Instructions for resolving conflicts

⚠️ If there are merge conflicts, you will need to resolve them manually before merging. You can do this using GitHub or using the command line.

Instructions for updating this pull request

Contributors to this repo have permission update this pull request by pushing to the branch 'merge/release/10.0.1xx-to-release/10.0.3xx'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.
The provided examples assume that the remote is named 'origin'. If you have a different remote name, please replace 'origin' with the name of your remote.

git fetch
git checkout -b merge/release/10.0.1xx-to-release/10.0.3xx origin/release/10.0.3xx
git pull https://github.com/dotnet/sdk merge/release/10.0.1xx-to-release/10.0.3xx
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet/sdk HEAD:merge/release/10.0.1xx-to-release/10.0.3xx

or if you are using SSH

git fetch
git checkout -b merge/release/10.0.1xx-to-release/10.0.3xx origin/release/10.0.3xx
git pull git@github.com:dotnet/sdk merge/release/10.0.1xx-to-release/10.0.3xx
(make changes)
git commit -m "Updated PR with my changes"
git push git@github.com:dotnet/sdk HEAD:merge/release/10.0.1xx-to-release/10.0.3xx

Contact .NET Core Engineering (dotnet/dnceng) if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/main/.github/workflows/scripts/inter-branch-merge.ps1.

[DonnaChen888]

@nagilson @jeffhandley could you please help confirm whether this change is expected to be kept in 10.0.3xx?

The PR merged the mcpserver template change from 10.0.1xx into 10.0.3xx.

After this change, CI started failing with:

• error: '[]' is not a valid version string
• NU1101: Unable to find package Microsoft.McpServer.ProjectTemplates.10.0

I was able to reproduce this locally. The NU1101 appears when the following version property is defined:

<MicrosoftMcpServerProjectTemplates100PackageVersion>10.0.8</MicrosoftMcpServerProjectTemplates100PackageVersion>

[marcpopMSFT]

@DonnaChen888 Looks like we're missing the version.details.props and version.details.xml changes from https://github.com/dotnet/sdk/pull/54319/changes. Normally we don't take any eng changes in the codeflow but this is the rare exception when a new component was added in an older branch.

Can you add this back to this PR? Thanks.

[DonnaChen888]

@DonnaChen888 Looks like we're missing the version.details.props and version.details.xml changes from https://github.com/dotnet/sdk/pull/54319/changes. Normally we don't take any eng changes in the codeflow but this is the rare exception when a new component was added in an older branch.

Can you add this back to this PR? Thanks.

@marcpopMSFT I haven’t pushed the changes yet — I tested the version.details.props and version.details.xml updates from #54319 locally first.

However, even after adding them, restore is still failing on 10.0.3xx with:

NU1101: Unable to find package Microsoft.McpServer.ProjectTemplates.10.0

I’m able to reproduce this locally, and it looks like version 10.0.8 of this package is not available from the configured feeds.

It seems the package may not have been published/backported to 10.0.3xx.

Could you confirm whether this package is expected to exist in 10.0.3xx, or if this change should not be kept in this branch?

[marcpopMSFT]

@DonnaChen888 the issue here is that the component wasn't added until 10.0.9 I believe so it's correct that there isn't a 10.0.8 version. The 10.0.1xx branch currently is on 10.0.10 but that flows to the 3xx branch internally so won't flow back to the SDK for another month.

@dotnet/product-construction suggestion on how this should work? Should we check in the 10.0.10 version here and have it flow to VMR 3xx that way and then internal codeflow will update it to the correct 10.0.10 version? It's a bit funky adding a new component to the SDK that comes from runtime in servicing.

[marcpopMSFT]

Talking internally, it sounds like we have to wait until release day next week, have 10.0.9 flow to public 10.0.3xx of vmr, then flow back here, and then update this new reference to 10.0.9. We should confirm if it's available in the feeds we'll be using.

[marcpopMSFT]

Confirmed internally that there are three options:

1. Wait for public codeflow on release day that flows back to 10.0.3xx and update the version in this PR to match. Then this would have to flow back to the VMR and then get updated in internal codeflow to the latest...
2. Move this change to the internal branch of 10.0.3xx
3. Manually update the public 10.0.3xx repo with the public runtime version from 10.0.1xx and let it flow to here.

For now, I think we're going with option 1.