Merge branch 'main' into merge/release/8.0-to-main

Author: Tratcher

.azure/pipelines/ci.yml

@@ -144,8 +144,14 @@ variables:
   - ${{ if in(variables['Build.Reason'], 'PullRequest') }}:
     - name: _SignType
       value: test
-- name: runCodeQL3000
-  value: ${{ or(eq(variables['Build.Reason'], 'Schedule'), and(eq(variables['Build.Reason'], 'Manual'), eq(parameters.runCodeQL3000, 'true'))) }}
+- ${{ if or(eq(variables['Build.Reason'], 'Schedule'), and(eq(variables['Build.Reason'], 'Manual'), eq(parameters.runCodeQL3000, 'true'))) }}:
+  - name: runCodeQL3000
+    value: true
+- ${{ else }}:
+  - name: runCodeQL3000
+    value: false
+  - name: Codeql.Enabled
+    value: false
 - template: /eng/common/templates/variables/pool-providers.yml
 
 stages:
@@ -277,17 +283,15 @@ stages:
                   $(WindowsArm64LogArgs)
           displayName: Build ARM64
 
-        # Submit a manual build (in public or internal project) to validate changes to site extensions.
-        - ${{ if ne(variables['Build.Reason'], 'PullRequest') }}:
-          - script: .\src\SiteExtensions\build.cmd
-                    -ci
-                    -noBuildRepoTasks
-                    -pack
-                    -noBuildDeps
-                    -noBuildNative
-                    $(_BuildArgs)
-                    $(_InternalRuntimeDownloadArgs)
-            displayName: Build SiteExtension
+        - script: .\src\SiteExtensions\build.cmd
+                  -ci
+                  -noBuildRepoTasks
+                  -pack
+                  -noBuildDeps
+                  -noBuildNative
+                  $(_BuildArgs)
+                  $(_InternalRuntimeDownloadArgs)
+          displayName: Build SiteExtension
 
         # This runs code-signing on all packages, zips, and jar files as defined in build/CodeSign.targets. If
         # https://github.com/dotnet/arcade/issues/1957 is resolved, consider running code-signing inline with the other

.azure/pipelines/helix-matrix.yml

@@ -13,6 +13,7 @@ schedules:
     include:
     - release/6.0
     - release/7.0
+    - release/8.0
   always: false
 
 variables:

.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.

.github/fabricbot.json

@@ -1496,7 +1496,7 @@
             ]
           },
           {
-            "label": "area-runtime",
+            "label": "area-networking",
             "pathFilter": [
               "src/Servers/",
               "src/Http/",
@@ -1633,7 +1633,7 @@
             {
               "name": "addedToMilestone",
               "parameters": {
-                "milestoneName": ".NET 8 Planning"
+                "milestoneName": ".NET 9 Planning"
               }
             },
             {
@@ -1649,12 +1649,12 @@
           "issues",
           "project_card"
         ],
-        "taskName": "Comment when an investigation issue moved to .NET 8 Planning",
+        "taskName": "Comment when an investigation issue moved to .NET 9 Planning",
         "actions": [
           {
             "name": "addReply",
             "parameters": {
-              "comment": "To learn more about what this message means, what to expect next, and how this issue will be handled you can read our [Triage Process document](https://github.com/dotnet/aspnetcore/blob/main/docs/TriageProcess.md).\nWe're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious what is causing this behavior, we would like to keep this around to collect more feedback, which can later help us determine how to handle this. We will re-evaluate this issue, during our next planning meeting(s).\nIf we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact work."
+              "comment": "To learn more about what this message means, what to expect next, and how this issue will be handled you can read our [Triage Process document](https://github.com/dotnet/aspnetcore/blob/main/docs/TriageProcess.md).\nWe're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. Because it's not immediately obvious what is causing this behavior, we would like to keep this around to collect more feedback, which can later help us determine how to handle this. We will re-evaluate this issue, during our next planning meeting(s).\nIf we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact work."
             }
           }
         ]
@@ -2491,7 +2491,7 @@
           {
             "name": "addMilestone",
             "parameters": {
-              "milestoneName": "8.0-rc1"
+              "milestoneName": "9.0-preview1"
             }
           }
         ],
@@ -2510,7 +2510,7 @@
             {
               "name": "addedToMilestone",
               "parameters": {
-                "milestoneName": ".NET 8 Planning"
+                "milestoneName": ".NET 9 Planning"
               }
             },
             {
@@ -2531,12 +2531,12 @@
           "issues",
           "project_card"
         ],
-        "taskName": "Comment when an issue is moved to `.NET 8 Planning` milestone",
+        "taskName": "Comment when an issue is moved to `.NET 9 Planning` milestone",
         "actions": [
           {
             "name": "addReply",
             "parameters": {
-              "comment": "Thanks for contacting us.\n\nWe're moving this issue to the `.NET 8 Planning` milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). \nIf we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.\nTo learn more about what to expect next and how this issue will be handled you can read more about our triage process [here](https://github.com/dotnet/aspnetcore/blob/main/docs/TriageProcess.md)."
+              "comment": "Thanks for contacting us.\n\nWe're moving this issue to the `.NET 9 Planning` milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). \nIf we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.\nTo learn more about what to expect next and how this issue will be handled you can read more about our triage process [here](https://github.com/dotnet/aspnetcore/blob/main/docs/TriageProcess.md)."
             }
           }
         ]
@@ -3236,7 +3236,7 @@
           {
             "name": "addMilestone",
             "parameters": {
-              "milestoneName": "6.0.22"
+              "milestoneName": "6.0.23"
             }
           }
         ]
@@ -3280,7 +3280,7 @@
           {
             "name": "addMilestone",
             "parameters": {
-              "milestoneName": "7.0.11"
+              "milestoneName": "7.0.12"
             }
           }
         ]
@@ -3304,7 +3304,7 @@
             {
               "name": "prTargetsBranch",
               "parameters": {
-                "branchName": "release/8.0-preview7"
+                "branchName": "release/8.0-rc2"
               }
             }
           ]
@@ -3315,7 +3315,7 @@
           "issues",
           "project_card"
         ],
-        "taskName": "[Milestone Assignments] Assign Milestone to PRs merged to release/8.0-preview7 branch",
+        "taskName": "[Milestone Assignments] Assign Milestone to PRs merged to release/8.0-rc2 branch",
         "actions": [
           {
             "name": "removeMilestone",
@@ -3324,7 +3324,51 @@
           {
             "name": "addMilestone",
             "parameters": {
-              "milestoneName": "8.0-preview7"
+              "milestoneName": "8.0-rc2"
+            }
+          }
+        ]
+      }
+    },
+    {
+      "taskType": "trigger",
+      "capabilityId": "IssueResponder",
+      "subCapability": "PullRequestResponder",
+      "version": "1.0",
+      "config": {
+        "conditions": {
+          "operator": "and",
+          "operands": [
+            {
+              "name": "isAction",
+              "parameters": {
+                "action": "merged"
+              }
+            },
+            {
+              "name": "prTargetsBranch",
+              "parameters": {
+                "branchName": "release/8.0"
+              }
+            }
+          ]
+        },
+        "eventType": "pull_request",
+        "eventNames": [
+          "pull_request",
+          "issues",
+          "project_card"
+        ],
+        "taskName": "[Milestone Assignments] Assign Milestone to PRs merged to release/8.0 branch",
+        "actions": [
+          {
+            "name": "removeMilestone",
+            "parameters": {}
+          },
+          {
+            "name": "addMilestone",
+            "parameters": {
+              "milestoneName": "8.0.0"
             }
           }
         ]
@@ -3357,7 +3401,7 @@
           {
             "name": "addReply",
             "parameters": {
-              "comment": "Thank you for filing this issue. In order for us to investigate this issue, please provide [a minimalistic repro project](https://github.com/dotnet/aspnetcore/blob/main/docs/repro.md) that illustrates the problem."
+              "comment": "Thank you for filing this issue. In order for us to investigate this issue, please provide [a minimal repro project](https://github.com/dotnet/aspnetcore/blob/main/docs/repro.md) that illustrates the problem without unnecessary code. Please share with us in a public GitHub repo because we cannot open ZIP attachments, and don't include any confidential content."
             }
           },
           {

.github/workflows/markdownlint.yml

@@ -14,7 +14,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v3
+    - uses: actions/checkout@v4
     - name: Use Node.js
       uses: actions/setup-node@v3
       with:

.github/workflows/runtime-sync.yml

@@ -21,14 +21,14 @@ jobs:
     runs-on: windows-latest
     steps:
     - name: Checkout aspnetcore
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         # Test this script using changes in a fork
         repository: 'dotnet/aspnetcore'
         path: aspnetcore
         ref: main
     - name: Checkout runtime
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         # Test this script using changes in a fork
         repository: 'dotnet/runtime'

Directory.Build.props

@@ -1,6 +1,10 @@
 <Project>
   <Import Project="eng\Common.props" />
 
+  <PropertyGroup>
+    <AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>
+  </PropertyGroup>
+
   <PropertyGroup>
     <!-- $(RepoRoot) is normally set globally and Arcade overrides it to ensure a trailing slash. -->
     <RepoRoot Condition=" '$(RepoRoot)' == '' OR !HasTrailingSlash('$(RepoRoot)') ">$(MSBuildThisFileDirectory)</RepoRoot>

NuGet.config

@@ -4,6 +4,8 @@
     <clear />
     <add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
     <add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
+    <add key="dotnet9" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json" />
+    <add key="dotnet9-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9-transport/nuget/v3/index.json" />
     <add key="dotnet8" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json" />
     <add key="dotnet7" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json" />
     <add key="dotnet8-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8-transport/nuget/v3/index.json" />

docs/UpdatingMajorVersionAndTFM.md

@@ -15,7 +15,6 @@ Typically, we will update the Major Version before updating the TFM. This is bec
   2. Change `PreReleaseVersionIteration` to `1`.
   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. `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 an entry to `_templatePackages` for `Microsoft.DotNet.Web.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://learn.microsoft.com/dotnet/csharp/language-reference/configure-language-version#defaults to find what language version to use.
@@ -24,6 +23,7 @@ Typically, we will update the Major Version before updating the TFM. This is bec
     * The result of `.\eng\scripts\mark-shipped.cmd` should be checked in to the release branch as well, as part of the RTM release.
 * Update `.\eng\Baseline.xml` to reflect the set of RTM packages that were just shipped. Then, `dotnet run` `.\eng\tools\BaselineGenerator\BaselineGenerator.csproj`, which will update `.\eng\Baseline.Designer.props`. If RTM hasn't shipped yet, do this in a separate PR once it has.
 * Update `.\eng\PlatformManifest.txt` and `.\eng\PackageOverrides.txt`. Download the just released RTM version of the `Microsoft.AspNetCore.App.Ref` package, and copy over the files from the `data` folder. This can be done in the same PR as the one updating `.\eng\Baseline.xml` and `.\eng\Baseline.Designer.props` (see https://github.com/dotnet/aspnetcore/pull/49269).
+* Update [helix-matrix.yml](https://github.com/dotnet/aspnetcore/blob/436556163a671259c8b14ae1c90d72767af62d18/.azure/pipelines/helix-matrix.yml#L12-L16) to list the currently active release branches
 
 ### Validation
 
@@ -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.