[main] Update dependencies from dotnet/efcore dotnet/runtime (#45475)

[main] Update dependencies from dotnet/efcore dotnet/runtime - Update templatestrings.json files - Update template.json files - Update other references to net7 - Rename publicApi folders - Fix RepoTasks - Fix it more fixily - Really fix it for real this time - Undo PreviewFeatures changes - Using - Merge branch 'darc-main-8caa276f-464b-4e95-a7fa-bc264a536653' of https://github.com/dotnet/aspnetcore into darc-main-8caa276f-464b-4e95-a7fa-bc264a536653 - Tasks - IO - CTS - Net70 - Merge branch 'darc-main-8caa276f-464b-4e95-a7fa-bc264a536653' of https://github.com/dotnet/aspnetcore into darc-main-8caa276f-464b-4e95-a7fa-bc264a536653 - Try using net8.0 for HelixTestRunner - Try making ReferenceAssemblies - Merge branch 'darc-main-8caa276f-464b-4e95-a7fa-bc264a536653' of https://github.com/dotnet/aspnetcore into darc-main-8caa276f-464b-4e95-a7fa-bc264a536653 - Get analyzer tests working - Ok fine - Update doc - Path combine - Try somethin wacky - Fix - Using - Merge remote-tracking branch 'upstream/main' into darc-main-8caa276f-464b-4e95-a7fa-bc264a536653 - Quarantine regressed WriteAsJsonAsync tests #45557 - Quarantine regressed async Json test #45557 - Re-order DataAnnotationsMetadataProviderTest expected results - Quarantine regressed async Json test #45557 - Re-order DataAnnotationsMetadataProviderTest expected results - Merge remote-tracking branch 'upstream/main' into darc-main-8caa276f-464b-4e95-a7fa-bc264a536653 - Bump E2E timeout to 2 hours Per discussion in #44834 (comment) - React to enum ordering change - Merge remote-tracking branch 'upstream/darc-main-8caa276f-464b-4e95-a7fa-bc264a536653' into darc-main-8caa276f-464b-4e95-a7fa-bc264a536653 - Skip a microbenchmark, update a version - Make test resilient to order changes - Unquar tests - remove custom loader for .wasm file (#45611)
dotnet · Dec 15, 2022 · 867ffcc · 867ffcc
1 parent 232ec2e
commit 867ffcc
Show file tree

Hide file tree

Showing 280 changed files with 635 additions and 592 deletions.
diff --git a/.azure/pipelines/components-e2e-tests.yml b/.azure/pipelines/components-e2e-tests.yml
@@ -34,7 +34,7 @@ jobs:
     agentOs: Linux
     isAzDOTestingJob: true
     enablePublishTestResults: false
-    timeoutInMinutes: 75
+    timeoutInMinutes: 120
     steps:
     - script: git submodule update --init
       displayName: Update submodules

diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json
@@ -37,7 +37,7 @@
   "remoteEnv": {
     "PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:PATH}",
     "DOTNET_MULTILEVEL_LOOKUP": "0",
-    "TARGET": "net7.0",
+    "TARGET": "net8.0",
     "DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER": "true"
   },
   // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.

diff --git a/docs/Helix.md b/docs/Helix.md
@@ -70,10 +70,10 @@ There's also a link embedded in the build.cmd log of the Tests: Helix x64 job on
   Stopping Azure Pipelines Test Run Ubuntu.1804.Amd64.Open
   Stopping Azure Pipelines Test Run Windows.11.Amd64.ClientPre.Open
   Stopping Azure Pipelines Test Run OSX.1014.Amd64.Open
-D:\a\_work\1\s\.packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21559.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : Work item Microsoft.AspNetCore.Identity.Test--net7.0 in job 53e2ca23-9efd-4299-8a8f-d9271265aeaa has failed. [D:\a\_work\1\s\eng\helix\helix.proj]
-D:\a\_work\1\s\.packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21559.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : Failure log: https://helix.dot.net/api/2019-06-17/jobs/53e2ca23-9efd-4299-8a8f-d9271265aeaa/workitems/Microsoft.AspNetCore.Identity.Test--net7.0/console [D:\a\_work\1\s\eng\helix\helix.proj]
-##[error].packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21559.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : (NETCORE_ENGINEERING_TELEMETRY=Test) Work item Microsoft.AspNetCore.Identity.Test--net7.0 in job 53e2ca23-9efd-4299-8a8f-d9271265aeaa has failed.
-Failure log: https://helix.dot.net/api/2019-06-17/jobs/53e2ca23-9efd-4299-8a8f-d9271265aeaa/workitems/Microsoft.AspNetCore.Identity.Test--net7.0/console
+D:\a\_work\1\s\.packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21559.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : Work item Microsoft.AspNetCore.Identity.Test--net8.0 in job 53e2ca23-9efd-4299-8a8f-d9271265aeaa has failed. [D:\a\_work\1\s\eng\helix\helix.proj]
+D:\a\_work\1\s\.packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21559.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : Failure log: https://helix.dot.net/api/2019-06-17/jobs/53e2ca23-9efd-4299-8a8f-d9271265aeaa/workitems/Microsoft.AspNetCore.Identity.Test--net8.0/console [D:\a\_work\1\s\eng\helix\helix.proj]
+##[error].packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21559.3\tools\Microsoft.DotNet.Helix.Sdk.MultiQueue.targets(78,5): error : (NETCORE_ENGINEERING_TELEMETRY=Test) Work item Microsoft.AspNetCore.Identity.Test--net8.0 in job 53e2ca23-9efd-4299-8a8f-d9271265aeaa has failed.
+Failure log: https://helix.dot.net/api/2019-06-17/jobs/53e2ca23-9efd-4299-8a8f-d9271265aeaa/workitems/Microsoft.AspNetCore.Identity.Test--net8.0/console
 ```
 
 The https://helix.dot.net/ home page displays information about the available public queues (nothing about the related BYOC pools and queues or the internal Helix queues)

diff --git a/docs/UpdatingMajorVersionAndTFM.md b/docs/UpdatingMajorVersionAndTFM.md
@@ -16,7 +16,7 @@ Typically, we will update the Major Version before updating the TFM. This is bec
   3. Change `PreReleaseVersionLabel` to `alpha`.
   4. Change `PreReleaseBrandingLabel` to `Alpha $(PreReleaseVersionIteration)`.
 * In [src/Framework/test/TestData.cs](/src/Framework/test/TestData.cs), update `ListedTargetingPackAssemblies` by incrementing the AssemblyVersion of all aspnetcore assemblies by 1 major version. Once dotnet/runtime updates their AssemblyVersions, we also need to update those in this file. They typically make that change at the same time as their TFM update, but we change our AssemblyVersions as soon as we update branding.
-* Add entries to [NuGet.config](/NuGet.config) for the new Major Version's feed. This just means copying the current feeds (e.g. `dotnet7` and `dotnet7-transport`) and adding entries for the new feeds (`dotnet8` and `dotnet8-transport`). Make an effort to remove old feeds here at the same time.
+* Add entries to [NuGet.config](/NuGet.config) for the new Major Version's feed. This just means copying the current feeds (e.g. `dotnet8` and `dotnet8-transport`) and adding entries for the new feeds (`dotnet9` and `dotnet9-transport`). Make an effort to remove old feeds here at the same time.
 * In [src/ProjectTemplates/Shared/TemplatePackageInstaller.cs](/src/ProjectTemplates/Shared/TemplatePackageInstaller.cs), add entries to `_templatePackages ` for `Microsoft.DotNet.Web.ProjectTemplates` and `Microsoft.DotNet.Web.Spa.ProjectTemplates` matching the new version.
 * In [eng/targets/CSharp.Common.props](/eng/targets/CSharp.Common.props) for the previous release branch, modify the `<LangVersion>` to be a hardcoded version instead of `preview`. (e.g. If main is being updated to 8.0.0 modify the `<LangVersion>` in the release/7.0 branch). See https://docs.microsoft.com/dotnet/csharp/language-reference/configure-language-version#defaults to find what language version to use.
 
@@ -28,13 +28,13 @@ Typically, we will update the Major Version before updating the TFM. This is bec
 
 ## Updating TFM
 
-Once dotnet/runtime has updated their TFM, we update ours in the dependency update PR ingesting that change. We won't be able to ingest new dotnet/runtime dependencies in `main` until this is done. For an example, [this](https://github.com/dotnet/aspnetcore/pull/36328) is the PR where we updated our TFM to `net7.0`. This step can be tricky - we have workarounds in [eng/tools/GenerateFiles/Directory.Build.targets.in](/eng/tools/GenerateFiles/Directory.Build.targets.in) to make the build work before we get an SDK containing runtime references with the new TFM. We copy the `KnownFrameworkReference`, `KnownRuntimePack`, and `KnownAppHostPack` from the previous TFM, give them the incoming runtime dependency versions, and give them the new TFM (these TFMs no-op most of the time - they only apply during this period when we're using an SDK that doesn't know about the new TFM). These workarounds allow us to build against the new TFM before we get an SDK with a reference to it, but there are often problems that arise in this area. The best way to debug build errors related to FrameworkReferences it to get a binlog of a failing project (`dotnet build /bl`) and look at the inputs to the task that failed. Confirm that the `Known___` items look as expected (there is an entry with the current TFM & the current dotnet/runtime dependency version), and look at the source code of the task in [dotnet/sdk](https://github.com/dotnet/sdk) for hints.
+Once dotnet/runtime has updated their TFM, we update ours in the dependency update PR ingesting that change. We won't be able to ingest new dotnet/runtime dependencies in `main` until this is done. For an example, [this](https://github.com/dotnet/aspnetcore/pull/36328) is the PR where we updated our TFM to `net8.0`. This step can be tricky - we have workarounds in [eng/tools/GenerateFiles/Directory.Build.targets.in](/eng/tools/GenerateFiles/Directory.Build.targets.in) to make the build work before we get an SDK containing runtime references with the new TFM. We copy the `KnownFrameworkReference`, `KnownRuntimePack`, and `KnownAppHostPack` from the previous TFM, give them the incoming runtime dependency versions, and give them the new TFM (these TFMs no-op most of the time - they only apply during this period when we're using an SDK that doesn't know about the new TFM). These workarounds allow us to build against the new TFM before we get an SDK with a reference to it, but there are often problems that arise in this area. The best way to debug build errors related to FrameworkReferences it to get a binlog of a failing project (`dotnet build /bl`) and look at the inputs to the task that failed. Confirm that the `Known___` items look as expected (there is an entry with the current TFM & the current dotnet/runtime dependency version), and look at the source code of the task in [dotnet/sdk](https://github.com/dotnet/sdk) for hints.
 
 ### Required changes
 
 * In [eng/Versions.props](/eng/Versions.props), increment `DefaultNetCoreTargetFramework` by 1.
-* Do a global repo search for the current version string, and update almost everything by 1 (e.g. find `net7`, replace with `net8`). See the PR linked above for examples - this shouldn't be done blindly, but on a case-by-case basis. Most things should be updated, and most choices should be obvious.
-  * Exceptions to this are [eng/tools/RepoTasks/RepoTasks.csproj](/eng/tools/RepoTasks/RepoTasks.csproj), [eng/tools/RepoTasks/RepoTasks.tasks](/eng/tools/RepoTasks/RepoTasks.tasks), and [eng/tools/HelixTestRunner/HelixTestRunner.csproj](/eng/tools/HelixTestRunner/HelixTestRunner.csproj). These build without the workarounds from [eng/tools/GenerateFiles/Directory.Build.targets.in](/eng/tools/GenerateFiles/Directory.Build.targets.in), and need to be kept at the previous TFM until we get an SDK containing a runtime with the new TFM. Generally this means we have to hard-code the previous TFM for these files, rather than using `DefaultNetCoreTargetFramework`.
+* Do a global repo search for the current version string, and update almost everything by 1 (e.g. find `net8`, replace with `net9`). See the PR linked above for examples - this shouldn't be done blindly, but on a case-by-case basis. Most things should be updated, and most choices should be obvious.
+  * Exceptions to this are [eng/tools/RepoTasks/RepoTasks.csproj](/eng/tools/RepoTasks/RepoTasks.csproj) and [eng/tools/RepoTasks/RepoTasks.tasks](/eng/tools/RepoTasks/RepoTasks.tasks). These build without the workarounds from [eng/tools/GenerateFiles/Directory.Build.targets.in](/eng/tools/GenerateFiles/Directory.Build.targets.in), and need to be kept at the previous TFM until we get an SDK containing a runtime with the new TFM. Generally this means we have to hard-code the previous TFM for these files, rather than using `DefaultNetCoreTargetFramework`.
 * Add a reference to the new `SiteExtensions` package for the previous Major Version.
   1. Add references to [src/SiteExtensions/LoggingAggregate/src/Microsoft.AspNetCore.AzureAppServices.SiteExtension/Microsoft.AspNetCore.AzureAppServices.SiteExtension.csproj](/src/SiteExtensions/LoggingAggregate/src/Microsoft.AspNetCore.AzureAppServices.SiteExtension/Microsoft.AspNetCore.AzureAppServices.SiteExtension.csproj) to `Microsoft.AspNetCore.AzureAppServices.SiteExtension.{PreviousMajorVersion}.0.x64` and `Microsoft.AspNetCore.AzureAppServices.SiteExtension.{PreviousMajorVersion}.0.x86`.
   2. Add entries in [eng/Versions.props](/eng/Versions.props) similar to [these](https://github.com/dotnet/aspnetcore/blob/216c92b78bce31d5e81a70b589707ec2ae5ab21a/eng/Versions.props#L224-L226) - the version should be from the latest released build of .Net.
@@ -62,4 +62,4 @@ Once dotnet/runtime has updated their TFM, we update ours in the dependency upda
 
 ## Ingesting an SDK with the new TFM
 
-Typically we update the SDK we use in `main` every Monday. Once we have one that contains `Microsoft.Netcore.App` entries with the new TFM, we can update [eng/tools/RepoTasks/RepoTasks.csproj](/eng/tools/RepoTasks/RepoTasks.csproj), [eng/tools/RepoTasks/RepoTasks.tasks](/eng/tools/RepoTasks/RepoTasks.tasks), and [eng/tools/HelixTestRunner/HelixTestRunner.csproj](/eng/helix/tools/HelixTestRunner.csproj) to use `DefaultNetCoreTargetFramework` again rather than hard-coding the previous TFM.
+Typically we update the SDK we use in `main` every Monday. Once we have one that contains `Microsoft.Netcore.App` entries with the new TFM, we can update [eng/tools/RepoTasks/RepoTasks.csproj](/eng/tools/RepoTasks/RepoTasks.csproj) and [eng/tools/RepoTasks/RepoTasks.tasks](/eng/tools/RepoTasks/RepoTasks.tasks) to use `DefaultNetCoreTargetFramework` again rather than hard-coding the previous TFM.