Merge main into live

.openpublishing.redirection.fundamentals.json

@@ -144,6 +144,14 @@
             "source_path_from_root": "/docs/fundamentals/code-analysis/style-rules/ide0270.md",
             "redirect_url": "/dotnet/fundamentals/code-analysis/style-rules/ide0029-ide0030-ide0270"
         },
+        {
+            "source_path_from_root": "/docs/fundamentals/code-analysis/style-rules/ide0390.md",
+            "redirect_url": "/dotnet/fundamentals/code-analysis/style-rules/ide0390-ide0391"
+        },
+        {
+            "source_path_from_root": "/docs/fundamentals/code-analysis/style-rules/ide0391.md",
+            "redirect_url": "/dotnet/fundamentals/code-analysis/style-rules/ide0390-ide0391"
+        },
         {
             "source_path_from_root": "/docs/fundamentals/code-analysis/style-rules/ide1006.md",
             "redirect_url": "/dotnet/fundamentals/code-analysis/style-rules/naming-rules"

docs/core/testing/microsoft-testing-platform-terminal-output.md

@@ -43,15 +43,18 @@ The progress bar is written based on the selected mode:
 
 ## Options
 
-| Option | Description |
-|---|---|
-| `--no-progress` | Disables reporting progress to screen. Deprecated in MTP 2.3.0 in favor of `--progress off`. |
-| `--progress` | Controls whether progress is shown. Valid values are `auto` (default), `on` (also accepts `true`, `enable`, `1`), and `off` (also accepts `false`, `disable`, `0`). Available in MTP starting with version 2.3.0. |
-| `--no-ansi` | Disables outputting ANSI escape characters to screen. |
-| `--ansi` | Controls whether ANSI escape characters are emitted. Valid values are `auto` (default), `on` (also accepts `true`, `enable`, `1`), and `off` (also accepts `false`, `disable`, `0`). Available in MTP starting with version 2.3.0. |
-| `--output` | Specifies the output verbosity when reporting tests. Valid values are `Normal` and `Detailed`. Default is `Normal`. |
-| `--show-stdout` | Determines when to show captured standard output of a test. Valid values are `All`, `Failed`, and `None`. Default is `All`. Available in MTP starting with version 2.2.1. |
-| `--show-stderr` | Determines when to show captured error output of a test. Valid values are `All`, `Failed`, and `None`. Default is `All`. Available in MTP starting with version 2.2.1. |
+| Option | MTP version | Description |
+|---|---|---|
+| `--no-progress` | — | Disables reporting progress to screen. Deprecated in MTP 2.3.0 in favor of `--progress off`. |
+| `--progress` | 2.3.0 | Controls whether progress is shown. Valid values are `auto` (default), `on` (also accepts `true`, `enable`, `1`), and `off` (also accepts `false`, `disable`, `0`). |
+| `--no-ansi` | — | Disables outputting ANSI escape characters to screen. |
+| `--ansi` | 2.3.0 | Controls whether ANSI escape characters are emitted. Valid values are `auto` (default), `on` (also accepts `true`, `enable`, `1`), and `off` (also accepts `false`, `disable`, `0`). |
+| `--output` | — | Specifies the output verbosity when reporting tests. Valid values are `Normal` and `Detailed`. Default is `Normal`. |
+| `--show-stdout` | 2.2.1 | Determines when to show captured standard output of a test. Valid values are `All`, `Failed`, and `None`. Default is `All`. |
+| `--show-stderr` | 2.2.1 | Determines when to show captured error output of a test. Valid values are `All`, `Failed`, and `None`. Default is `All`. |
+
+> [!NOTE]
+> A dash (—) in the **MTP version** column marks core options that aren't tied to a specific version because they've been available since the platform's initial releases.
 
 > [!NOTE]
 > Starting with MTP 2.3.0, when MTP detects that it runs inside an LLM or AI tool environment, it suppresses the startup banner and changes the default of `--show-stdout` and `--show-stderr` from `All` to `Failed` to reduce noise.

docs/core/testing/microsoft-testing-platform-test-reports.md

@@ -143,23 +143,23 @@ builder.TestHost.AddAzureDevOpsProvider();
 
 ### Options
 
-| Option | Description |
-|---|---|
-| `--report-azdo` | Enables the Azure DevOps report generator. Errors and warnings are written to the output in a format that Azure DevOps understands. |
-| `--report-azdo-severity` | Severity to use for reported events. Valid values are `error` (default) and `warning`. |
-| `--report-azdo-flaky-history` | Queries Azure DevOps test result history for the past N days (1-90) and annotates reported failures with flakiness context. Requires `--report-azdo`. |
-| `--report-azdo-demote-known-flaky` | Demotes failures that are flaky enough in the Azure DevOps history window (default threshold is 25%) from errors to warnings. Requires `--report-azdo` and `--report-azdo-flaky-history`. |
-| `--report-azdo-quarantine-file` | Path to a text file that lists quarantined test fully qualified names or glob patterns. Matching failures are reported as warnings. Requires `--report-azdo`. |
-| `--report-azdo-summary` | Writes a Markdown job summary at the end of the test run and uploads it through `##vso[task.uploadsummary]`. An optional file path argument overrides the default location (`{testResultsDir}/azdo-summary-{tfm}.md`). Requires `--report-azdo`. |
-| `--report-azdo-stackframe-filter` | Adds regex patterns, matched against the fully qualified type prefix of each stack frame, that are skipped when the extension locates the user's call site to annotate. The option is repeatable, up to 16 patterns, and each pattern is compiled with a 500-ms match timeout. These patterns are additive to the extension's built-in MSTest assertion-implementation prefixes. Requires `--report-azdo`. |
-| `--report-azdo-upload-artifacts` | Uploads test result files and/or adds build tags to Azure DevOps. Valid values are `off` (default), `tags-only`, `files`, and `all`. |
-| `--report-azdo-upload-artifact-include` | Includes files in the Azure DevOps artifact upload using glob patterns relative to the test results directory. Defaults to `**/*`. Requires `--report-azdo-upload-artifacts` to be a value other than `off`. |
-| `--report-azdo-upload-artifact-exclude` | Excludes files from the Azure DevOps artifact upload using glob patterns relative to the test results directory. Requires `--report-azdo-upload-artifacts` to be a value other than `off`. |
-| `--report-azdo-upload-artifact-name` | Overrides the Azure DevOps artifact container name. Defaults to `TestResults_{assemblyName}_{tfm}`. Requires `--report-azdo-upload-artifacts` to be a value other than `off`. |
-| `--publish-azdo-test-results` | Publishes test results live to the Azure DevOps **Tests** tab. |
-| `--publish-azdo-run-name` | Sets a custom Azure DevOps test run name for live test-result publishing. Requires `--publish-azdo-test-results`. |
+| Option | MTP version | Description |
+|---|---|---|
+| `--report-azdo` | 1.9.0 | Enables the Azure DevOps report generator. Errors and warnings are written to the output in a format that Azure DevOps understands. |
+| `--report-azdo-severity` | 1.9.0 | Severity to use for reported events. Valid values are `error` (default) and `warning`. |
+| `--report-azdo-flaky-history` | 2.3.0 | Queries Azure DevOps test result history for the past N days (1-90) and annotates reported failures with flakiness context. Requires `--report-azdo`. |
+| `--report-azdo-demote-known-flaky` | 2.3.0 | Demotes failures that are flaky enough in the Azure DevOps history window (default threshold is 25%) from errors to warnings. Requires `--report-azdo` and `--report-azdo-flaky-history`. |
+| `--report-azdo-quarantine-file` | 2.3.0 | Path to a text file that lists quarantined test fully qualified names or glob patterns. Matching failures are reported as warnings. Requires `--report-azdo`. |
+| `--report-azdo-summary` | 2.3.0 | Writes a Markdown job summary at the end of the test run and uploads it through `##vso[task.uploadsummary]`. An optional file path argument overrides the default location (`{testResultsDir}/azdo-summary-{tfm}.md`). Requires `--report-azdo`. |
+| `--report-azdo-stackframe-filter` | 2.3.0 | Adds regex patterns, matched against the fully qualified type prefix of each stack frame, that are skipped when the extension locates the user's call site to annotate. The option is repeatable, up to 16 patterns, and each pattern is compiled with a 500-ms match timeout. These patterns are additive to the extension's built-in MSTest assertion-implementation prefixes. Requires `--report-azdo`. |
+| `--report-azdo-upload-artifacts` | 2.3.0 | Uploads test result files and/or adds build tags to Azure DevOps. Valid values are `off` (default), `tags-only`, `files`, and `all`. |
+| `--report-azdo-upload-artifact-include` | 2.3.0 | Includes files in the Azure DevOps artifact upload using glob patterns relative to the test results directory. Defaults to `**/*`. Requires `--report-azdo-upload-artifacts` to be a value other than `off`. |
+| `--report-azdo-upload-artifact-exclude` | 2.3.0 | Excludes files from the Azure DevOps artifact upload using glob patterns relative to the test results directory. Requires `--report-azdo-upload-artifacts` to be a value other than `off`. |
+| `--report-azdo-upload-artifact-name` | 2.3.0 | Overrides the Azure DevOps artifact container name. Defaults to `TestResults_{assemblyName}_{tfm}`. Requires `--report-azdo-upload-artifacts` to be a value other than `off`. |
+| `--publish-azdo-test-results` | 2.3.0 | Publishes test results live to the Azure DevOps **Tests** tab. |
+| `--publish-azdo-run-name` | 2.3.0 | Sets a custom Azure DevOps test run name for live test-result publishing. Requires `--publish-azdo-test-results`. |
 
 > [!NOTE]
-> The Azure DevOps extension became stable in MTP 1.9.0 (`--report-azdo` and `--report-azdo-severity`). All other options in the table — `--report-azdo-flaky-history`, `--report-azdo-demote-known-flaky`, `--report-azdo-quarantine-file`, `--report-azdo-summary`, `--report-azdo-stackframe-filter`, `--report-azdo-upload-artifacts`, `--report-azdo-upload-artifact-include`, `--report-azdo-upload-artifact-exclude`, `--report-azdo-upload-artifact-name`, `--publish-azdo-test-results`, and `--publish-azdo-run-name` — are available in MTP starting with version 2.3.0.
+> The **MTP version** column lists the MTP release in which each option first became available in a stable build. The Azure DevOps extension itself became stable in MTP 1.9.0 with `--report-azdo` and `--report-azdo-severity`; the remaining options were added in MTP 2.3.0.
 
 The extension automatically detects that it is running in continuous integration (CI) environment by checking the `TF_BUILD` environment variable.

docs/core/testing/unit-testing-mstest-running-tests.md

@@ -23,9 +23,9 @@ The MSTest runner is open source and builds on the [MTP](./microsoft-testing-pla
 
 ## Enable MTP in an MSTest project
 
-It's recommended to use [MSTest SDK](./unit-testing-mstest-sdk.md) as it greatly simplifies your project configuration and updating the project, and it ensures a proper alignment of the versions of the platform (MTP) and its extensions.
+Use [MSTest SDK](./unit-testing-mstest-sdk.md) to greatly simplify your project configuration, version management, and alignment of MTP and its extensions.
 
-When you use `MSTest SDK`, by default you're opted in to using MTP.
+`MSTest.Sdk` replaces `Microsoft.NET.Sdk` as the project SDK, and MTP is enabled by default:
 
 ```xml
 <Project Sdk="MSTest.Sdk/4.1.0">
@@ -39,7 +39,12 @@ When you use `MSTest SDK`, by default you're opted in to using MTP.
 </Project>
 ```
 
-Alternatively, you can enable MSTest runner by adding the `EnableMSTestRunner` property and setting `OutputType` to `Exe` in your project file. You also need to ensure that you're using `MSTest 3.2.0` or newer. We strongly recommend you update to the latest MSTest version available.
+> [!NOTE]
+> `MSTest.Sdk` works only when your project can use `Microsoft.NET.Sdk` as its base SDK. If your project requires a different SDK, don't replace the `<Project Sdk="...">` value with `MSTest.Sdk`.
+>
+> For example, some ASP.NET Core integration test projects use `Microsoft.NET.Sdk.Web`. `MSTest.Sdk` derives from `Microsoft.NET.Sdk`, so it doesn't import the ASP.NET Core SDK targets that `Microsoft.NET.Sdk.Web` provides.
+
+You can also configure MSTest manually instead of using `MSTest.Sdk`. Manual configuration is required when your project needs a different top-level SDK (for example, `Microsoft.NET.Sdk.Web`), but you can also choose it with the standard `Microsoft.NET.Sdk`. Add the `EnableMSTestRunner` property and set `OutputType` to `Exe` in your project file. Then add the MSTest references that your project requires. Ensure that you're using MSTest 3.2.0 or newer, and update to the latest MSTest version available.
 
 Consider the following example project file:
 

docs/csharp/advanced-topics/interop/how-to-use-platform-invoke-to-play-a-wave-file.md

@@ -31,5 +31,5 @@ Compile and run the code.
 
 ## See also
 
-- [A Closer Look at Platform Invoke](../../../framework/interop/consuming-unmanaged-dll-functions.md#a-closer-look-at-platform-invoke)
-- [Marshaling Data with Platform Invoke](../../../framework/interop/marshalling-data-with-platform-invoke.md)
+- [A Closer Look at Platform Invoke](../../../standard/native-interop/consuming-unmanaged-dll-functions.md#a-closer-look-at-platform-invoke)
+- [Marshaling Data with Platform Invoke](../../../standard/native-interop/marshalling-data-with-platform-invoke.md)

docs/csharp/advanced-topics/interop/index.md

@@ -19,7 +19,7 @@ Interoperability enables you to preserve and take advantage of existing investme
 
 *Platform invoke* is a service that enables managed code to call unmanaged functions implemented in dynamic link libraries (DLLs), such as the Microsoft Windows API. It locates and invokes an exported function and marshals its arguments (integers, strings, arrays, structures, and so on) across the interoperation boundary as needed.
 
-For more information, see [Consuming Unmanaged DLL Functions](../../../framework/interop/consuming-unmanaged-dll-functions.md) and [How to use platform invoke to play a WAV file](./how-to-use-platform-invoke-to-play-a-wave-file.md).
+For more information, see [Consuming Unmanaged DLL Functions](../../../standard/native-interop/consuming-unmanaged-dll-functions.md) and [How to use platform invoke to play a WAV file](./how-to-use-platform-invoke-to-play-a-wave-file.md).
 
 > [!NOTE]
 > The [Common Language Runtime](../../../standard/clr.md) (CLR) manages access to system resources. Calling unmanaged code that is outside the CLR bypasses this security mechanism, and therefore presents a security risk. For example, unmanaged code might call resources in unmanaged code directly, bypassing CLR security mechanisms. For more information, see [Security in .NET](../../../standard/security/index.md).
@@ -38,7 +38,7 @@ You can consume a COM component from a C# project. The general steps are as foll
 1. Create an instance of a class defined in the RCW. Creating an instance of that class creates an instance of the COM object.
 1. Use the object just as you use other managed objects. When the object is reclaimed by garbage collection, the instance of the COM object is also released from memory.
 
-For more information, see [Exposing COM Components to the .NET Framework](../../../framework/interop/exposing-com-components.md).
+For more information, see [Exposing COM Components to the .NET Framework](../../../standard/native-interop/exposing-com-components.md).
 
 ## Exposing C# to COM
 
@@ -49,13 +49,13 @@ COM clients can consume C# types that have been correctly exposed. The basic ste
 1. Generate a COM type library and register it for COM usage.
    You can modify C# project properties to automatically register the C# assembly for COM interop. Visual Studio uses the [Regasm.exe (Assembly Registration Tool)](../../../framework/tools/regasm-exe-assembly-registration-tool.md), using the `/tlb` command-line switch, which takes a managed assembly as input, to generate a type library. This type library describes the `public` types in the assembly and adds registry entries so that COM clients can create managed classes.
 
- For more information, see [Exposing .NET Framework Components to COM](../../../framework/interop/exposing-dotnet-components-to-com.md) and [Example COM Class](./example-com-class.md).
+ For more information, see [Exposing .NET Framework Components to COM](../../../standard/native-interop/exposing-dotnet-components-to-com.md) and [Example COM Class](./example-com-class.md).
 
 ## See also
 
 - [Improving Interop Performance](/previous-versions/msp-n-p/ff647812(v=pandp.10))
 - [Introduction to Interoperability between COM and .NET](/office/client-developer/outlook/pia/introduction-to-interoperability-between-com-and-net)
 - [Introduction to COM Interop in Visual Basic](../../../visual-basic/programming-guide/com-interop/introduction-to-com-interop.md)
-- [Marshaling between Managed and Unmanaged Code](../../../framework/interop/interop-marshalling.md)
-- [Interoperating with Unmanaged Code](../../../framework/interop/index.md)
-- [Registering Assemblies with COM](../../../framework/interop/registering-assemblies-with-com.md)
+- [Marshaling between Managed and Unmanaged Code](../../../standard/native-interop/interop-marshalling.md)
+- [Interoperating with Unmanaged Code](../../../standard/native-interop/index.md)
+- [Registering Assemblies with COM](../../../standard/native-interop/registering-assemblies-with-com.md)

docs/csharp/language-reference/compiler-messages/cs1762.md

@@ -26,4 +26,4 @@ A reference was created to embedded interop assembly '\<assembly1>' because of a
 ## See also
 
 - [**EmbedInteropAssembly** (C# Compiler Options)](../compiler-options/inputs.md#embedinteroptypes)
-- [Interoperating with Unmanaged Code](../../../framework/interop/index.md)
+- [Interoperating with Unmanaged Code](../../../standard/native-interop/index.md)

docs/csharp/language-reference/compiler-messages/cs8355.md

@@ -31,5 +31,5 @@ class Program
 
 ## See also
 
-- [Default Marshalling Behavior](../../../framework/interop/default-marshalling-behavior.md)
+- [Default Marshalling Behavior](../../../standard/native-interop/default-marshalling-behavior.md)
 - [Reference parameters](../keywords/method-parameters.md#reference-parameters)

docs/csharp/language-reference/compiler-messages/generic-type-parameters-errors.md

@@ -440,7 +440,7 @@ For more information, see [Constraints on type parameters](../../programming-gui
 The <xref:System.Runtime.InteropServices.UnmanagedCallersOnlyAttribute> attribute marks methods that unmanaged code can call. These methods have strict requirements because the runtime must handle the transition between managed and unmanaged calling conventions.
 
 - Use only valid calling convention types in the `UnmanagedCallersOnly` attribute (**CS8893**). The `CallConvs` property of the attribute accepts only recognized calling convention types from the `System.Runtime.CompilerServices` namespace.
-- Use only [blittable types](/dotnet/framework/interop/blittable-and-non-blittable-types) as parameter and return types (**CS8894**). Methods marked with `UnmanagedCallersOnly` can't use managed types (such as `string` or `object`) as parameter or return types because unmanaged callers can't manage the garbage-collected references.
+- Use only [blittable types](../../../standard/native-interop/blittable-and-non-blittable-types.md) as parameter and return types (**CS8894**). Methods marked with `UnmanagedCallersOnly` can't use managed types (such as `string` or `object`) as parameter or return types because unmanaged callers can't manage the garbage-collected references.
 - Remove generic type parameters from `UnmanagedCallersOnly` methods and don't declare them in generic types (**CS8895**). Unmanaged calling conventions don't support generics because the runtime can't determine the correct calling convention for generic type substitutions.
 - Apply `UnmanagedCallersOnly` only to ordinary static, non-abstract, non-virtual methods or static local functions (**CS8896**). Instance methods, abstract methods, and virtual methods can't be marked with `UnmanagedCallersOnly` because unmanaged callers can't perform the dispatch mechanisms these methods require.
 

docs/csharp/language-reference/operators/snippets/shared/StackallocOperator.cs

@@ -72,7 +72,7 @@ private static void LimitStackAllocatedMemory(int inputLength)
     {
         // <SnippetLimitStackalloc>
         const int MaxStackLimit = 1024;
-        Span<byte> buffer = inputLength <= MaxStackLimit ? stackalloc byte[MaxStackLimit] : new byte[inputLength];
+        Span<byte> buffer = inputLength <= MaxStackLimit ? stackalloc byte[inputLength] : new byte[inputLength];
         // </SnippetLimitStackalloc>
     }
 }