[main] Update dependencies from dotnet/msbuild

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/msbuild

• Subscription: c88fef6f-3728-44a8-80e6-587fb00258a1
• Build: 20250312.14
• Date Produced: March 12, 2025 3:55:29 PM UTC
• Commit: a4ef1e90fef9b56473708b7d308f982c7c9f46d9
• Branch: refs/heads/vs17.13

• Updates:
  • Microsoft.SourceBuild.Intermediate.msbuild: from 17.11.0-preview-24178-03 to 17.13.20-preview-25162-14
  • Microsoft.Build: from 17.11.0-preview-24178-03 to 17.13.20
  • Microsoft.Build.Framework: from 17.11.0-preview-24178-03 to 17.13.20
  • Microsoft.Build.Tasks.Core: from 17.11.0-preview-24178-03 to 17.13.20
  • Microsoft.Build.Utilities.Core: from 17.11.0-preview-24178-03 to 17.13.20

[github-actions]

✅ No release notes required

[psfinaki]

Hi @ellahathaway and @mthalman. So I am trying to apply what you mentioned in this PR - I've set up a new Maestro subscription to flow msbuild to our repo, which produced this PR.

Good news is that I could remove the recently added lines from SourceBuildPrebuiltBaseline.xml.

But - the new MSBuild version claimed the updates to the System packages which, in turn, SourceBuild is now complaining about:

Package IDs are:
System.Collections.Immutable.9.0.0
System.Configuration.ConfigurationManager.9.0.0
System.Diagnostics.DiagnosticSource.9.0.0
System.Diagnostics.EventLog.9.0.0
System.Formats.Asn1.9.0.0
System.Formats.Nrbf.9.0.0
System.Reflection.Metadata.9.0.0
System.Resources.Extensions.9.0.0
System.Security.Cryptography.ProtectedData.9.0.0
System.Text.Encoding.CodePages.9.0.0
System.Threading.Tasks.Dataflow.9.0.0

What's your recommendation? Should I add those to the baseline - like Roslyn has that? Should I do something else?

[T-Gro]

I don't think it's correct for us to depend on preview versions in our versions.props - those bits are flowing automatically to release branches, and consequently, insertions.

I don't think I have seen preview versions for those components in versions.props before, so we should only do it if it gives any sensible advantage (e.g. compared to taking last known good stable versions).

A source build specific config can of course do whatever source build requires, I do understand that.

[psfinaki]

@T-Gro I get your perspective and I personally don't have any big preference here.

That said, note that we actually do have preview packages among our dependencies, e.g. this and this.

It's not uncommon for sibling repos to have preview deps as well, e.g. ASP.NET Core has the hell lot of them.

That was the reason for my choice. However, it's trivial to resetup this in Maestro, if we want to.

[T-Gro]

@T-Gro I get your perspective and I personally don't have any big preference here.

That said, note that we actually do have preview packages among our dependencies, e.g. this and this.

It's not uncommon for sibling repos to have preview deps as well, e.g. ASP.NET Core has the hell lot of them.

That was the reason for my choice. However, it's trivial to resetup this in Maestro, if we want to.

None of the links, neither this repo nor aspnetcore, are making it to be part of the shipped product.
This is not really about preference - it is about being aware what is being a shippable production product.

If you can ensure that the preview versions remain in main only and release branches will have stable versions, that works.
(if the benefits are really that big and additional complexity+cost is justified)

[psfinaki]

Okay @mthalman @ellahathaway this should be good to go, I set up Maestro to not send previews to us, which in turn now doesn't require System packages update. As the result, this only removes stuff from SourceBuildPrebuildBaseline without adding anything there - which is nice.

[psfinaki]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).