[release/7.0.1xx-rc1] Update dependencies from dotnet/runtime

[dotnet-maestro]

This pull request updates the following dependencies

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

• Subscription: d09cde6c-2776-434a-f0f8-08da7ef63651
• Build: 20220822.23
• Date Produced: August 23, 2022 9:09:04 AM UTC
• Commit: 7193b9098794406cca52bb044c528efd47a23c22
• Branch: refs/heads/release/7.0-rc1

• Updates:
  • Microsoft.DotNet.ILCompiler: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • Microsoft.Extensions.DependencyModel: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • Microsoft.NET.HostModel: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • Microsoft.NETCore.App.Host.win-x64: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • Microsoft.NETCore.App.Ref: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • Microsoft.NETCore.App.Runtime.win-x64: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • Microsoft.NETCore.DotNetHostResolver: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • Microsoft.NETCore.Platforms: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • System.CodeDom: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • System.Reflection.MetadataLoadContext: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • System.Resources.Extensions: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • System.Security.Cryptography.ProtectedData: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • System.Text.Encoding.CodePages: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • VS.Redist.Common.NetCore.SharedFramework.x64.7.0: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23
  • VS.Redist.Common.NetCore.TargetingPack.x64.7.0: from 7.0.0-rc.1.22421.12 to 7.0.0-rc.1.22422.23

[danmoseley]

@eerhardt looks like the infernal publish baselines need an update here also

[lewing]

@mkArtakMSFT if we're going to keep these tests enabled we need someone to own updating them. The manifest changes here are from dotnet/runtime#74236

[eerhardt]

In case anyone needs to update the baselines in the future, here are the steps I did:

1. gh pr checkout XXX
2. .\build.cmd
3. Edit the following lines so it returns true
   

   sdk/src/Tests/Microsoft.NET.Sdk.Razor.Tests/AspNetSdkBaselineTest.cs

   Lines 29 to 33 in eed75f6

   	#if GENERATE_SWA_BASELINES
   	public static bool GenerateBaselines = true;
   	#else
   	public static bool GenerateBaselines = false;
   	#endif

4. .\.dotnet\dotnet.exe test src\Tests\Microsoft.NET.Sdk.BlazorWebAssembly.Tests\
5. Revert the code file from (3) above.
6. git commit -am "Update ASP.NET baselines"
7. git push

[danmoseley]

How often have these baseline tests found an issue, historically?

[javiercn]

@danmoseley we had quite a good number of issues in .NET 3.1 and 5.0 related to the MSBuild pipeline for Blazor apps, that's why we introduced the baselines.

It's a trade-off between catching regressions and having to manually update the baselines when they change. At the time, we did not expect this to cause much friction, but I understand we might have seen more changes than we originally expected.

Normally someone on the ASP.NET Team is watching for these PRs and will ping the relevant people, but you can always ping @mkArtakMSFT, @TanayParikh or me and we'll deal with it as soon as possible.

I'll figure out if we can relax some of the ways in which we check these baselines to be more tolerant with framework assemblies (which is typically what causes issues here).

[TanayParikh]

if we can relax some of the ways in which we check these baselines to be more tolerant with framework assemblies (which is typically what causes issues here).

Related: dotnet/aspnetcore#43834

[eerhardt]

I'll figure out if we can relax some of the ways in which we check these baselines to be more tolerant with framework assemblies (which is typically what causes issues here).

What would really help (IMO) is better diagnostic messaging when it fails. Saying the test failed with

Expected subject to be a collection with 244 item(s), but found 241.

Doesn't really tell a dev what is wrong. Instead, they need to pull the change locally, build, and run it themselves to figure out what is the issue/change.

If instead the test failed with what files were missing / additional, that would really help diagnose what the change is that broke the test.

For example, if the test failed with "Expected to have file dotnet-crypto-worker.js, but it didn't exist. If this change is expected, see [instructions] for updating this test.", then I would know it was my change that broke it - and it is expected. So I can just go update the baseline.