Merge remote-tracking branch 'upstream/main' into user_events_functional_runtime_test

Author: mdh1418

.CodeQL.yml

@@ -8,6 +8,7 @@ path_classifiers:
     # be excluded from analysis. If there is a problem at the API layer, the analysis
     # engine will detect the problem in the src/ implementations anyway.
     - src/libraries/**/ref/*
+  cmake_internal:
     # exclude artifacts/obj/**/CMakeFiles/**/CheckFunctionExists.c since CMake 
     # generates random directory names causing creation of duplicate issues 
     # related to obsolete encryption algorithm used. Note that CheckFuntionExists 

.azuredevops/dependabot.yml

@@ -0,0 +1,5 @@
+version: 2
+
+# Disabling dependabot on Azure DevOps as this is a mirrored repo. Updates should go through github.
+enable-campaigned-updates: false
+enable-security-updates: false

.github/copilot-instructions.md

@@ -23,6 +23,8 @@ In addition to the rules enforced by `.editorconfig`, you SHOULD:
 - When running tests, if possible use filters and check test run counts, or look at test logs, to ensure they actually ran.
 - Do not finish work with any tests commented out or disabled that were not previously commented out or disabled.
 - When writing tests, do not emit "Act", "Arrange" or "Assert" comments.
+- For markdown (`.md`) files, ensure there is no trailing whitespace at the end of any line.
+- When adding XML documentation to APIs, follow the guidelines at [`docs.prompt.md`](/.github/prompts/docs.prompt.md).
 
 ---
 

.github/prompts/docs.prompt.md

@@ -0,0 +1,63 @@
+---
+mode: 'agent'
+tools: ['changes', 'codebase', 'editFiles', 'problems']
+description: 'Ensure that C# types are documented with XML comments and follow best practices for documentation.'
+---
+
+# C# Documentation Best Practices
+
+- Public members should be documented with XML comments.
+- It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.
+
+## Guidance for all APIs
+
+- Use `<summary>` to provide a brief, one sentence, description of what the type or member does. Start the summary with a present-tense, third-person verb.
+- Use `<remarks>` for additional information, which can include implementation details, usage notes, or any other relevant context.
+- Use `<see langword>` for language-specific keywords like `null`, `true`, `false`, `int`, `bool`, etc.
+- Use `<c>` for inline code snippets.
+- Use `<example>` for usage examples on how to use the member.
+  - Use `<code>` for code blocks. `<code>` tags should be placed within an `<example>` tag. Add the language of the code example using the `language` attribute, for example, `<code language="csharp">`.
+- Use `<see cref>` to reference other types or members inline (in a sentence).
+- Use `<seealso>` for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
+- Use `<inheritdoc/>` to inherit documentation from base classes or interfaces.
+  - Unless there is major behavior change, in which case you should document the differences.
+
+## Methods
+
+- Use `<param>` to describe method parameters.
+  - The description should be a noun phrase that doesn't specify the data type.
+  - Begin with an introductory article.
+  - If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
+  - If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
+  - If the parameter is a Boolean, the wording should be of the form "`<see langword="true" />` to ...; otherwise, `<see langword="false" />`.".
+  - If the parameter is an "out" parameter, the wording should be of the form "When this method returns, contains .... This parameter is treated as uninitialized.".
+- Use `<paramref>` to reference parameter names in documentation.
+- Use `<typeparam>` to describe type parameters in generic types or methods.
+- Use `<typeparamref>` to reference type parameters in documentation.
+- Use `<returns>` to describe what the method returns.
+  - The description should be a noun phrase that doesn't specify the data type.
+  - Begin with an introductory article.
+  - If the return type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`.".
+
+## Constructors
+
+- The summary wording should be "Initializes a new instance of the <Class> class [or struct].".
+
+## Properties
+
+- The `<summary>` should start with:
+  - "Gets or sets..." for a read-write property.
+  - "Gets..." for a read-only property.
+  - "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
+- Use `<value>` to describe the value of the property.
+  - The description should be a noun phrase that doesn't specify the data type.
+  - If the property has a default value, add it in a separate sentence, for example, "The default is `<see langword="false" />`".
+  - If the value type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`. The default is ...".
+
+## Exceptions
+
+- Use `<exception cref>` to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
+- Document all exceptions thrown directly by the member.
+- For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
+- The description of the exception describes the condition under which it's thrown.
+  - Omit "Thrown if ..." or "If ..." at the beginning of the sentence. Just state the condition directly, for example "An error occurred when accessing a Message Queuing API."

.github/workflows/aspnetcore-sync.yml

@@ -16,14 +16,14 @@ jobs:
     runs-on: windows-latest
     steps:
     - name: Checkout aspnetcore
-      uses: actions/checkout@v5
+      uses: actions/checkout@v6
       with:
         # Test this script using changes in a fork
         repository: 'dotnet/aspnetcore'
         path: aspnetcore
         ref: main
     - name: Checkout runtime
-      uses: actions/checkout@v5
+      uses: actions/checkout@v6
       with:
         # Test this script using changes in a fork
         repository: 'dotnet/runtime'
@@ -42,7 +42,7 @@ jobs:
         mkdir ..\artifacts
         git status > ..\artifacts\status.txt
         git diff > ..\artifacts\diff.txt
-    - uses: actions/upload-artifact@v4
+    - uses: actions/upload-artifact@v5
       with:
         name: results
         path: artifacts

.github/workflows/backport.yml

@@ -46,7 +46,8 @@ jobs:
 
         **IMPORTANT**: If this backport is for a servicing release, please verify that:
 
-        - The PR target branch is `release/X.0-staging`, not `release/X.0`.
+        - For .NET 8 and .NET 9: The PR target branch is `release/X.0-staging`, not `release/X.0`.
+        - For .NET 10+: The PR target branch is `release/X.0` (no `-staging` suffix).
 
         ## Package authoring no longer needed in .NET 9
 

.github/workflows/bump-chrome-version.yml

@@ -16,7 +16,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v5
+        uses: actions/checkout@v6
       - name: Setup Branch
         run: |
           git config user.name github-actions[bot]

.github/workflows/copilot-setup-steps.yml

@@ -15,7 +15,7 @@ jobs:
     # You can define any steps you want, and they will run before the agent starts.
     # If you do not check out your code, Copilot will do this for you.
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v6
 
       - name: Install Dependencies
         env:

.github/workflows/jit-format.yml

@@ -33,7 +33,7 @@ jobs:
         with:
           dotnet-version: '8.0.x'
       - name: Checkout runtime
-        uses: actions/checkout@v5
+        uses: actions/checkout@v6
         with:
           path: runtime
       - name: Install Python
@@ -46,7 +46,7 @@ jobs:
           ROOTFS_DIR: ${{ matrix.os.rootfs }}
 
       - name: Publish format.patch
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v5
         with:
           path: runtime/format.patch
           name: format.${{matrix.os.name}}.patch

.github/workflows/locker.yml

@@ -23,7 +23,7 @@ jobs:
     if: ${{ github.repository_owner == 'dotnet' }}
     steps:
       - name: Checkout Actions
-        uses: actions/checkout@v5
+        uses: actions/checkout@v6
         with:
           repository: "microsoft/vscode-github-triage-actions"
           path: ./actions