Update to latest templating autoring package to fix CG alert

[marcpopMSFT]

I got a CG alert that we were still on the -rtm version of this package from 2023. I found the latest build from May and did an update-dependencies on it. I'm not sure what depends on this package or how to validate that the latest version is compatible with the prior one. There should not be any intentional breaks in the package afaik.

[akoeplinger]

Diff: dotnet/templating@4a9eb30...7206725

[akoeplinger]

Looks like this is used in a couple repos: https://github.com/search?q=org%3Adotnet+UsingToolTemplateLocalizer+-repo%3Adotnet%2Fdotnet&type=code

We also apparently hit an issue once that caused us to downgrade 9.0.101 to 9.0.100 of that package: #15257

@mmitche @ViktorHofer do you remember anything about this? I also see we're still using a random 10.0.100-preview.4 in both 10.0 and main...

[ViktorHofer]

The revert was due to .NET Framework tasks not being able to load the assembly anymore due to binding redirects in msbuild. This doesn't apply anymore as we don't have any .NET Framework tasks in Arcade anymore.

EDIT: Just saw the branch. Yes, we need to be super careful here. You would want to validate that the .NET Framework task is still loadable by the VS version used in this branch. You could also add an integration test directly here to validate that.

[marcpopMSFT]

The revert was due to .NET Framework tasks not being able to load the assembly anymore due to binding redirects in msbuild. This doesn't apply anymore as we don't have any .NET Framework tasks in Arcade anymore.

EDIT: Just saw the branch. Yes, we need to be super careful here. You would want to validate that the .NET Framework task is still loadable by the VS version used in this branch. You could also add an integration test directly here to validate that.

This was flagged by CG as the -rtm version is considered prerelease and from the version number, it was a random build in September of that year. I'm not sure how to low cost confirm that this is ok and if we wanted to go to 8.0.100 version, I'd be ok with that to. The current version is wrong and I'm not really looking to add a test since this isn't likely to be updated frequently.

Is the issue that the repos that use this build using VS and it could break their builds? How do I verify that?

[mmitche]

Summary

Darc Build Lookups

┌─────────────────────────┬────────────────────────────────────────────┬────────────┬─────────────────┐
│ Version                 │ Commit                                     │ Build Date │ Branch          │
├─────────────────────────┼────────────────────────────────────────────┼────────────┼─────────────────┤
│ 8.0.100-rtm.23479.1     │ 4a9eb30212b51dc53c2f647843db6aad6c5426a8   │ 9/29/2023  │ release/8.0.1xx │
├─────────────────────────┼────────────────────────────────────────────┼────────────┼─────────────────┤
│ 8.0.127 (released)      │ 7206725e3dfa05ce92dd567703ff2c96cbe2dc59   │ 4/16/2026  │ release/8.0.1xx │
└─────────────────────────┴────────────────────────────────────────────┴────────────┴─────────────────┘

MSBuild Task Dependencies

Both versions reference the same MSBuild package versions (defined in eng/dependabot/Packages.props):

┌────────────────────────────────────┬────────────┐
│ Package                            │ Version    │
├────────────────────────────────────┼────────────┤
│ Microsoft.Build.Framework          │ 17.7.2     │
├────────────────────────────────────┼────────────┤
│ Microsoft.Build.Utilities.Core     │ 17.7.2     │
└────────────────────────────────────┴────────────┘

The MSBuild task dependency did not change between 8.0.100-rtm.23479.1 and 8.0.127 — both use Microsoft.Build 17.7.2.

[mmitche]

I think this is safe.