Migrate patches to source mutations, in particular ones that are known to change every release

[dagood]

Patch: a change from some specific text to some other text in a specific part of a file. Extremely fragile--intentionally--when upstream source code changes in that file.

Source mutation: modifying a file with a looser tool, such as sed or an MSBuild task. We modify global.json, nuget.config, and the RID graph this way today.

---

This patch is a prime candidate:
https://github.com/dotnet/source-build/blob/release/3.1/patches/aspnetcore/0007-Fix-version-number.patch

This patch is actually on a minified json file, changing the last handful of characters to the current product version. Instead of updating this patch for each servicing release, this should be done as a step in the build itself.

To keep this manageable, we should also keep track of what changes we're making to source code outside of patches: #1499. This is technically optional. (We already have some source mutations that aren't tracked.)

[omajid]

https://github.com/dotnet/source-build/blob/release/3.1/patches/aspnetcore/0007-Fix-version-number.patch

This patch is actually on a minified json file, changing the last handful of characters to the current product version. Instead of updating this patch for each servicing release, this should be done as a step in the build itself.

For the product version, is there some msbuild variable that corresponds to the expected version? Are variables that are listed in PackagesVersions.props such as MicrosoftAspNetCoreMetadataVersion available when aspnetcore.proj is being built? If not, what's a good way to avoid hardcoding the number.

Is there a test that verifies that this file is correct? Is there something that breaks if this patch is (accidentally) not applied?

[dagood]

For the product version, is there some msbuild variable that corresponds to the expected version?

Not right now. I think we should add one for this and for #747. Plopping this into our eng/Versions.props and saying to update it in the release checklist would IMO be fine to get past this:

<MajorVersion>5</MajorVersion>
<MinorVersion>0</MinorVersion>
<RuntimePatchVersion>2</RuntimePatchVersion>
<SdkPatchVersion>102</SdkPatchVersion>
<RuntimeProductVersion>$(MajorVersion).$(MinorVersion).$(PatchVersion)</RuntimeProductVersion>
<SdkProductVersion>...</SdkProductVersion>

Maybe we could set up auto-update somehow, or something like how aspnetcoreOutputPackageVersion gets populated but we don't have a package with a stable SDK version in eng/Version.Details.xml right now.

Are variables that are listed in PackagesVersions.props such as MicrosoftAspNetCoreMetadataVersion available when aspnetcore.proj is being built?

Not sure, you can check a source-build binlog to know for sure.

Is there a test that verifies that this file is correct? Is there something that breaks if this patch is (accidentally) not applied?

IIRC the website won't work if you try to navigate to it? I'm not sure. @crummel @dseefeld ?

[crummel]

@JunTaoLuo I'm not sure exactly what happens when the Blazor.js version and ASP.NET server version mismatch. Is this something that's easy to test for?

[omajid]

With the recent changes to master removing repos/aspnetcore.proj, where does https://github.com/dotnet/source-build/blob/release/3.1/patches/aspnetcore/0007-Fix-version-number.patch live now?

[dagood]

That's over at https://github.com/dotnet/source-build/blob/release/5.0/patches/aspnetcore/0016-Fix-version-number.patch for 5.0. (We'll fork a 6.0 branch from release/5.0 for any non-arcade-powered-source-build 6.0 work, so that patch would live on through that flow in 6.0 until the patch (or mutation) gets in dotnet/aspnetcore directly.)

[MichaelSimons]

Patch usage has been steadily declining. For .NET 7.0 we are down to 3 patches. We do not want to make any investments around making patches easier to use - patch usage is being eliminated.