[main] Update dependencies from dotnet/efcore dotnet/runtime

.devcontainer/devcontainer.json

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

docs/UpdatingMajorVersionAndTFM.md

@@ -33,11 +33,12 @@ 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 `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.
+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.
 
 ### Required changes
 
 * In [eng/Versions.props](/eng/Versions.props), increment `DefaultNetCoreTargetFramework` by 1.
+* In [eng/SourceBuild.props](/eng/SourceBuild.props), update `SourceBuildTargetFrameworkFilter` to include the current TFM.
 * 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.

eng/BeforeTargetFrameworkInference.targets

@@ -0,0 +1,6 @@
+<Project>
+  <PropertyGroup>
+    <!-- Workaround while there is no SDK available that understands the TFM; suppress unsupported version errors. -->
+    <NETCoreAppMaximumVersion>99.9</NETCoreAppMaximumVersion>
+  </PropertyGroup>
+</Project>

eng/SourceBuild.props

@@ -5,6 +5,7 @@
   <PropertyGroup>
     <GitHubRepositoryName>aspnetcore</GitHubRepositoryName>
     <SourceBuildManagedOnly>true</SourceBuildManagedOnly>
+    <SourceBuildTargetFrameworkFilter>netstandard2.0%3bnetstandard2.1%3bnetcoreapp2.1%3bnetcoreapp3.1%3bnet5.0%3bnet6.0%3bnet7.0%3bnet8.0%3bnet9.0</SourceBuildTargetFrameworkFilter>
   </PropertyGroup>
 
   <Target Name="PrepareGlobalJsonForSourceBuild"

eng/SourceBuildPrebuiltBaseline.xml

@@ -36,7 +36,7 @@
 
     <!-- These are coming in via runtime but the source-build infra isn't able to automatically pick up the right intermediate. -->
     <UsagePattern IdentityGlob="Microsoft.NET.ILLink.Tasks/*8.0.*" />
-    <UsagePattern IdentityGlob="Microsoft.NETCore.App.Crossgen2.linux-x64/*8.0.*" />
+    <UsagePattern IdentityGlob="Microsoft.NETCore.App.Crossgen2.linux-x64/*9.0.*" />
 
     <!-- Transivite dependency of Microsoft.CodeAnalysis.ExternalAccess.AspNetCore -> Microsoft.CodeAnalysis.Features.
          In product build the dependency is bumped to latest, which also bumps the version of DiaSymReader  -->