* Fix yarn alerts

* Fix nuget alerts

* No yarn-audit-fix

* Remove yarn-audit-fix

- reenable baseline validation
- update 3.1 runtime
- update downlevel site extension versions
- set `$(IsPublicRuntime)` back to `true`

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22206.7 -> To Version 6.0.0-beta.22212.5

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-runtime

* Merged PR 21649: [internal/release/6.0] Make UseUrls() override default hosting config

## Description

Prior to this change, default config (typically loaded from `DOTNET_`/`ASPNET_` environment variables and command line arguments) could override the application-level configuration. This would prevent `GenericWebHostService` from seeing the latest configuration set by `UseUrls()` of `DOTNET_URLS`, `ASPNET_URLS` or `--urls` was set.

Fixes #38185

## Customer Impact

This is a big gotcha to customers using `WebApplicationBuilder` (which is used in all the ASP.NET Core 6 templates) who expect the following to work:

```C#
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseUrls("http://*:8080");
var app = builder.Build();
app.Run();
```

A comment on the issue suggesting we patch this has gotten 5 thumbs ups not counting mine.

## Regression?

- [ ] Yes
- [x] No

## Risk

- [ ] High
- [ ] Medium
- [x] Low

This is a small well tested change which only affects the loading of default config sources and those added via a `HostFactoryResolver` to host configuration. [Here’s the existing test](https://github.com/dotnet/aspnetcore/blob/0f6f649f1da658bbe37b8898df0c80c5affa9d2d/src/DefaultBuilder/test/Microsoft.AspNetCore.Tests/WebApplicationTests.cs#L883) showing that the expected configuration providers are still dispose.

## Verification

- [x] Manual (required)
- [x] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [x] N/A

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-runtime

* Merge from github release/6.0

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore dnceng/internal/dotnet-runtime

 - Set to private runtime

* Merged PR 21869: Correct `--architecture` in `fpm` commands

# {PR title}

Correct `--architecture` in `fpm` commands

## Description

Update `fpm` commands to use a supported `--architecture` value. As-is, the x64 .rpm files we produce are incompatible w/ installation on an x64 machine. Problem found during servicing version flow.

## Customer Impact

Unable to build dotnet-installer-ci-official w/ current .rpm files from dotnet-aspnetcore repo.

## Regression?

- [x] Yes
- [ ] No

This is a build regression since 6.0.3. It will also impact our 'main' branch.

## Risk

- [ ] High
- [ ] Medium
- [x] Low

Have verified the chosen values for the command line using available online documentation. Since we know the current .rpm files are busted, things can only get better 

## Verification

- [x] Manual (required)
- [ ] Automated

I am locally building this branch and will use `rpmlint` in a `docker` container to verify the goodness of the produced package.

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

Not sure how to answer this because the change is to an internal setting of the RPM installer. If others agree it's the right change, it's been reviewed 



----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

* Merged PR 21931: Revert "[release/6.0] Build ProjectTemplates in Source-Build (#40650)" (#40805)

# {PR title}

Summary of the changes (Less than 80 chars)

## Description

{Detail}

Fixes #{bug number} (in this specific format)

## Customer Impact

{Justification}

## Regression?

- [ ] Yes
- [ ] No

[If yes, specify the version the behavior has regressed from]

## Risk

- [ ] High
- [ ] Medium
- [ ] Low

[Justify the selection above]

## Verification

- [ ] Manual (required)
- [ ] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

Revert "[release/6.0] Build ProjectTemplates in Source-Build (#40650)" (#40805)

This reverts commit 7c2000d3.

Co-authored-by: dotnet-bot <dotnet-bot@microsoft.com>
Co-authored-by: DotNet Bot <dn-bot@microsoft.com>
Co-authored-by: Stephen Halter <shalter@microsoft.com>
Co-authored-by: mmitche <mmitche@microsoft.com>
Co-authored-by: Doug Bunting (AAPT) <dougbu@microsoft.com>

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22178.5 -> To Version 6.0.0-beta.22206.7

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* Add option to project templates to use Program.Main instead of top-level statements (#40886)

Fixes #40944

* Update spa templates submodule

* [release/6.0] Add RID to targeting pack archive names
* Fixup

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22161.1 -> To Version 6.0.0-beta.22178.5

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

Bumps [src/submodules/googletest](https://github.com/google/googletest) from `c9461a9` to `af29db7`.
- [Release notes](https://github.com/google/googletest/releases)
- [Commits](https://github.com/google/googletest/compare/c9461a9b55ba954df0489bab6420eb297bed846b...af29db7ec28d6df1c7f0f745186884091e602e07

)

---
updated-dependencies:
- dependency-name: src/submodules/googletest
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Revert "Revert "[release/6.0] Build ProjectTemplates in Source-Build (#40650)" (#40805)"

This reverts commit a351c437.

* Update Microsoft.Authentication.WebAssembly.Msal.csproj
* Update Microsoft.AspNetCore.Components.WebAssembly.Authentication.csproj
* Update Microsoft.Authentication.WebAssembly.Msal.csproj
* Update Microsoft.AspNetCore.Components.WebAssembly.Authentication.csproj

* Workaround

- backport for #39038
- `cherry-pick` of 6958517c
- update `AssemblyTestLog` to perform actual log directory cleanup
  - add `ReportTestFailure()` method for tests to report failures, disabling cleanup
  - add `IAcceptFailureReports` for `AspNetTestAssemblyRunner` to report failures to `AssemblyTestLog`
- extend `AspNetTestAssemblyRunner` to optionally create fixture instances using `static ForAssembly(Assembly)`
- add `AssemblyTestLogFixtureAttribute` to register `AssemblyTestLog` as an assembly fixture
  - use `AssemblyTestLogFixtureAttribute` in all test projects
- disable log cleanup in three existing tests

- add tests of new cleanup features
  - also cover a few existing methods
- do cleanup before creating new logger
  - was deleting the just-created global.log file

nits:
- use `is [not] null` and `new()` more
- move `AssemblyTestLogTests` to same namespace as `AssemblyTestLog`

* Get richnav.yml building again - correct build.cmd location - generally align richnav.yml with ci.yml - ignore signing, internal download args, and publish args

nit: correct name of one build step in ci.yml

* Disable pipeline in PR validation - also remove irrelevant trigger branches

* !fixup! Try doing native build w/o rich nav

nit: put `-no`s together

* !fixup! Disable rich nav explicitly - also remove installers build entirely; build will fail

nits:
- don't bother setting `$(EnableRichCodeNavigation)` or `$(OnlyPackPlatformSpecificPackages)` to `true`
  - job.yml sets `$(EnableRichCodeNavigation)` variable and `msbuild` will find that in environment
  - `$(OnlyPackPlatformSpecificPackages)` is not relevant in this pipeline; not packing

Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>

# {PR title}

Summary of the changes (Less than 80 chars)

## Description

{Detail}

Fixes #{bug number} (in this specific format)

## Customer Impact

{Justification}

## Regression?

- [ ] Yes
- [ ] No

[If yes, specify the version the behavior has regressed from]

## Risk

- [ ] High
- [ ] Medium
- [ ] Low

[Justify the selection above]

## Verification

- [ ] Manual (required)
- [ ] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

Revert "[release/6.0] Build ProjectTemplates in Source-Build (#40650)" (#40805)

This reverts commit 7c2000d3.

# {PR title}

Summary of the changes (Less than 80 chars)

## Description

{Detail}

Fixes #{bug number} (in this specific format)

## Customer Impact

{Justification}

## Regression?

- [ ] Yes
- [ ] No

[If yes, specify the version the behavior has regressed from]

## Risk

- [ ] High
- [ ] Medium
- [ ] Low

[Justify the selection above]

## Verification

- [ ] Manual (required)
- [ ] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

This reverts commit 7c2000d3.

# {PR title}

Correct `--architecture` in `fpm` commands

## Description

Update `fpm` commands to use a supported `--architecture` value. As-is, the x64 .rpm files we produce are incompatible w/ installation on an x64 machine. Problem found during servicing version flow.

## Customer Impact

Unable to build dotnet-installer-ci-official w/ current .rpm files from dotnet-aspnetcore repo.

## Regression?

- [x] Yes
- [ ] No

This is a build regression since 6.0.3. It will also impact our 'main' branch.

## Risk

- [ ] High
- [ ] Medium
- [x] Low

Have verified the chosen values for the command line using available online documentation. Since we know the current .rpm files are busted, things can only get better 

## Verification

- [x] Manual (required)
- [ ] Automated

I am locally building this branch and will use `rpmlint` in a `docker` container to verify the goodness of the produced package.

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

Not sure how to answer this because the change is to an internal setting of the RPM installer. If others agree it's the right change, it's been reviewed 

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

# {PR title}

Summary of the changes (Less than 80 chars)

## Description

{Detail}

Fixes #{bug number} (in this specific format)

## Customer Impact

{Justification}

## Regression?

- [ ] Yes
- [ ] No

[If yes, specify the version the behavior has regressed from]

## Risk

- [ ] High
- [ ] Medium
- [ ] Low

[Justify the selection above]

## Verification

- [ ] Manual (required)
- [ ] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

Merge from github release/6.0

[internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore dnceng/internal/dotnet-runtime

 - Set to private runtime

* Support tab characters in headers and unify validation code between servers.

* Preserve non-ASCII header value char treatment in http.sys.

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22159.8 -> To Version 6.0.0-beta.22161.1

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

[Blazor] Fix race condition when caching for a type of QueryParameterValueSupplier (#40636) (#40663)

## Description

We were using a regular dictionary on an internal cache that can be accessed concurrently.

#40595

## Customer Impact

If two or more threads try to populate the cache concurrently, it can cause the app to fail.

## Regression?

- [ ] Yes
- [X] No

[If yes, specify the version the behavior has regressed from]

## Risk

- [ ] High
- [ ] Medium
- [X] Low

It's switching the underlying dictionary type used.

## Verification

- [ ] Manual (required)
- [X] Automated

We have extensive E2E and unit tests for this behavior.

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [X] N/A

Co-authored-by: Mayuki Sawatari <mayuki+github@misuzilla.org>

* [release/6.0] Build .rpm packages for linux arm64

* Update Build.props

* Update Directory.Build.props

* Update Directory.Build.targets

* Update Rpm.Runtime.rpmproj

* Update Rpm.TargetingPack.rpmproj

* Avoid duplicate targeting-pack RPM Build
- if an RPM containing platform-neutral executables is platform-neutral, this should be enough

* !fixup! Change Linux ARM64 job, not ARM one

* Correct RPM arch name, include in targeting pack

* Revert "Avoid duplicate targeting-pack RPM Build"

This reverts commit 7bebff5b

* Rename x64 RPM to "x64"

Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>

* Build ProjectTemplates in Source-Build

* Fixup

Co-authored-by: Will Godbe <wigodbe@microsoft.com>

* Update dependencies from https://github.com/dotnet/arcade build 20220308.4

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22122.7 -> To Version 6.0.0-beta.22158.4

* Update dependencies from https://github.com/dotnet/arcade

 build 20220309.8

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22122.7 -> To Version 6.0.0-beta.22159.8

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>