Merge branch 'main' into no-bb-epoch

.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md

@@ -22,6 +22,7 @@ main PR <!-- Link to PR if any that fixed this in the main branch. -->
 
 <!-- Please assess the risk of taking this fix. Provide details backing up your assessment. -->
 
-# Package authoring signed off?
+# Package authoring no longer needed in .NET 9
 
-IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary [package authoring](../../docs/project/library-servicing.md) and gotten it explicitly reviewed.
+IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
+Keep in mind that we still need package authoring in .NET 8 and older versions.

.github/policies/resourceManagement.yml

@@ -1589,9 +1589,7 @@ configuration:
         then:
         - mentionUsers:
             mentionees:
-            - agocke
-            - sbomer
-            - vitek-karas
+            - dotnet/illink
             replyTemplate: >-
               Tagging subscribers to this area: ${mentionees}
 

.github/workflows/backport.yml

@@ -48,4 +48,7 @@ jobs:
 
         - The PR target branch is `release/X.0-staging`, not `release/X.0`.
 
-        - If the change touches code that ships in a NuGet package, you have added the necessary [package authoring](https://github.com/dotnet/runtime/blob/main/docs/project/library-servicing.md) and gotten it explicitly reviewed.
+        ## Package authoring no longer needed in .NET 9
+
+        **IMPORTANT**: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
+        Keep in mind that we still need package authoring in .NET 8 and older versions.

Directory.Build.props

@@ -120,9 +120,7 @@
     <NetFrameworkToolCurrent Condition="'$(DotNetBuildSourceOnly)' == 'true'" />
     <NetFrameworkCurrent Condition="'$(DotNetBuildSourceOnly)' == 'true'" />
 
-    <!-- Important: Set this to the GA version (or a close approximation) during servicing and adjust the TFM property below. -->
-    <!-- TODO: Update to 9.0.0 when .NET 9 is generally available. https://github.com/dotnet/runtime/issues/106598 -->
-    <ApiCompatNetCoreAppBaselineVersion>9.0.0-preview.7.24405.7</ApiCompatNetCoreAppBaselineVersion>
+    <ApiCompatNetCoreAppBaselineVersion>9.0.0</ApiCompatNetCoreAppBaselineVersion>
     <ApiCompatNetCoreAppBaselineTFM>net9.0</ApiCompatNetCoreAppBaselineTFM>
   </PropertyGroup>
 

docs/design/coreclr/botr/readytorun-overview.md

@@ -117,7 +117,7 @@ To allow changes in the runtime, we simply require that the new runtime handle a
 
 ### Restrictions on Runtime Evolution
 
-As mentioned previously, when designing for version compatibility we have the choice of either simply disallowing a change (by changing the breaking change rules), or insuring that the format is sufficiently flexible to allow evolution. For example, for managed code we have opted to disallow changes to value type (struct) layout so that codegen for structs can be efficient. In addition, the design also includes a small number of restrictions that affect the flexibility of evolving the runtime itself. They are:
+As mentioned previously, when designing for version compatibility we have the choice of either simply disallowing a change (by changing the breaking change rules), or ensuring that the format is sufficiently flexible to allow evolution. For example, for managed code we have opted to disallow changes to value type (struct) layout so that codegen for structs can be efficient. In addition, the design also includes a small number of restrictions that affect the flexibility of evolving the runtime itself. They are:
 
 - The field layout of `System.Object` cannot change. (First, there is a pointer sized field for type information and then the other fields.)
 - The field layout of arrays cannot change. (First, there is a pointer sized field for type information, and then a pointer sized field for the length. After these fields is the array data, packed using existing alignment rules.)

docs/project/library-servicing.md

@@ -4,21 +4,15 @@ This document provides the steps that need to be followed after modifying a libr
 
 Servicing branches represent shipped versions of .NET, and their name is in the format `release/X.0-staging`. Examples:
 
+- `release/9.0-staging`
 - `release/8.0-staging`
-- `release/7.0-staging`
-- `release/6.0-staging`
 
-## Check if a package is generated
-
-If a library is packable (check for the `<IsPackable>true</IsPackable>` property) you'll need to set `<GeneratePackageOnBuild>true</GeneratePackageOnBuild>` in the source project. That is necessary as packages aren't generated by default in servicing releases.
-
-## Determine ServiceVersion
-
-When you make a change to a library & ship it during the servicing release, the `ServicingVersion` must be bumped. This property is found in the library's source project. It's also possible that the property is not in that file, in which case you'll need to add it to the library's source project and set it to 1. If the property is already present in your library's source project, just increment the servicing version by 1.
+IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
+Keep in mind that we still need package authoring in .NET 8 and older versions.
 
 ## Test your changes
 
-All that's left is to ensure that your changes have worked as expected. To do so, execute the following steps:
+Develop and test your change as normal.  For packages, you may want to test them outside the repo infrastructure. To do so, execute the following steps:
 
 1. From a clean copy of your branch, run `build.cmd/sh libs -allconfigurations`
 
@@ -34,9 +28,8 @@ All the servicing change must go through an approval process. You have two ways
 - By manually creating your PR using [this template](https://raw.githubusercontent.com/dotnet/runtime/main/.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md).
 - Or by asking the bot to automatically create the servicing PR for you using a merged `main` PR as source. This method requires typing an AzDO backport command as a comment of your merged PR using the format `/backport to release/X.0-staging`. Examples:
 
+  - `/backport to release/9.0-staging`
   - `/backport to release/8.0-staging`
-  - `/backport to release/7.0-staging`
-  - `/backport to release/6.0-staging`
 
 For all cases, you must:
 
@@ -52,4 +45,4 @@ For all cases, you must:
 
 The area owner can then merge the PR once the CI looks good (it's either green or the failures are investigated and determined to be unrelated to the PR).
 
-**Note**: Applying the `Servicing-approved` label ensures the `check-service-labels` CI job passes, which is a mandatory requirement for merging a PR in a servicing branch.
+**Note**: Applying the `Servicing-approved` label ensures the `check-service-labels` CI job passes, which is a mandatory requirement for merging a PR in a servicing branch.

docs/workflow/trimming/feature-switches.md

@@ -12,7 +12,6 @@ configurations but their defaults might vary as any SDK can set the defaults dif
 | DynamicCodeSupport | System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported | Changes RuntimeFeature.IsDynamicCodeSupported to false to allow testing AOT-safe fallback code without publishing for Native AOT. |
 | EnableGeneratedComInterfaceComImportInterop | System.Runtime.InteropServices.Marshalling.EnableGeneratedComInterfaceComImportInterop | When set to true, enables casting source-generated COM object wrappers to built-in COM-based COM interfaces. |
 | VerifyDependencyInjectionOpenGenericServiceTrimmability | Microsoft.Extensions.DependencyInjection.VerifyOpenGenericServiceTrimmability | When set to true, DependencyInjection will verify trimming annotations applied to open generic services are correct. |
-| _AggressiveAttributeTrimming | System.AggressiveAttributeTrimming | When set to true, aggressively trims attributes to allow for the most size savings possible, even if it could result in runtime behavior changes |
 | _ComObjectDescriptorSupport | System.ComponentModel.TypeDescriptor.IsComObjectDescriptorSupported | When set to true, supports creating a TypeDescriptor based view of COM objects. |
 | _DataSetXmlSerializationSupport | System.Data.DataSet.XmlSerializationIsSupported | When set to false, DataSet implementation of IXmlSerializable will throw instead of using trim-incompatible XML serialization. |
 | _DefaultValueAttributeSupport | System.ComponentModel.DefaultValueAttribute.IsSupported | When set to true, supports creating a DefaultValueAttribute at runtime. |

eng/Subsets.props

@@ -550,7 +550,7 @@
       </ItemGroup>
       <ItemGroup>
         <SharedFrameworkProjectToBuild Condition="'$(BuildMonoAOTCrossCompilerOnly)' != 'true'" Include="$(InstallerProjectRoot)pkg\sfx\Microsoft.NETCore.App\Microsoft.NETCore.App.Runtime.sfxproj" />
-        <SharedFrameworkProjectToBuild Condition="'$(BuildNativeAOTRuntimePack)' != 'true' and '$(RuntimeFlavor)' == '$(PrimaryRuntimeFlavor)' and '$(TargetsMobile)' != 'true'" Include="$(InstallerProjectRoot)pkg\sfx\bundle\Microsoft.NETCore.App.Bundle.bundleproj" />
+        <SharedFrameworkProjectToBuild Condition="'$(BuildNativeAOTRuntimePack)' != 'true' and '$(RuntimeFlavor)' == '$(PrimaryRuntimeFlavor)' and '$(TargetsMobile)' != 'true' and '$(DotNetBuildSourceOnly)' != 'true'" Include="$(InstallerProjectRoot)pkg\sfx\bundle\Microsoft.NETCore.App.Bundle.bundleproj" />
         <ProjectToBuild Include="@(SharedFrameworkProjectToBuild)" Category="packs" />
       </ItemGroup>
     </When>