Merged main into live

Author: mijacobs

.github/workflows/clean-repo.yml

@@ -39,7 +39,7 @@ jobs:
 
       # Create the PR for the work done by the "clean repo" tool
       - name: create-pull-request
-        uses: peter-evans/create-pull-request@67ccf781d68cd99b580ae25a5c18a1cc84ffff1f
+        uses: peter-evans/create-pull-request@dd2324fc52d5d43c699a5636bcf19fceaa70c284
         with:
           branch: create-cleanrepo-pull-request/patch
           title: "Monthly chores: Automated repo cleanup"

.github/workflows/whats-new.yml

@@ -41,7 +41,7 @@ jobs:
           savefile: './docs/ide/whats-new-visual-studio-docs.md'
 
       - name: create-pull-request
-        uses: peter-evans/create-pull-request@67ccf781d68cd99b580ae25a5c18a1cc84ffff1f
+        uses: peter-evans/create-pull-request@dd2324fc52d5d43c699a5636bcf19fceaa70c284
         with:
           branch: create-whatsnew-pull-request/patch
           title: "What's new article"

docs/data-tools/create-a-simple-data-application-by-using-adonet.md

@@ -1,7 +1,7 @@
 ---
-title: Display WPF Trace Information
-description: Visual Studio can receive debug trace information from WPF applications and display it in the Output window. Learn how to manage and customize WPF tracing. 
-ms.date: 11/04/2016
+title: Display WPF trace information for data binding
+description: Visual Studio can receive debug trace information for data binding from WPF applications and display it in the Output window. Learn how to manage and customize WPF tracing. 
+ms.date: 02/25/2025
 ms.topic: how-to
 dev_langs: 
   - CSharp
@@ -16,13 +16,14 @@ ms.author: mikejo
 manager: mijacobs
 ms.subservice: debug-diagnostics
 ---
-# Display WPF Trace Information
 
-Visual Studio can receive debug trace information from WPF applications and display that information in the **Output** window. To display debug trace information, WPF tracing must be enabled.
+# Display WPF trace information for data binding
+
+Visual Studio can receive debug trace information for data binding from WPF applications and display that information in the **Output** window. To display debug trace information, WPF tracing must be enabled.
 
  You can enable WPF tracing in your App.Config file or programmatically by using the <xref:System.Diagnostics.PresentationTraceSources> class. An easier way to enable WPF tracing is by using the **Options** window. WPF tracing for web applications is not supported.
 
-### To enable or customize WPF trace information
+## Enable or customize WPF trace information
 
 1. On the **Tools** menu, select **Options**.
 
@@ -32,51 +33,29 @@ Visual Studio can receive debug trace information from WPF applications and disp
 
 4. Under **General Output Settings**, select **All debug output**.
 
-5. In the box on the right, look for **WPF Trace Settings**.
-
-6. Open the **WPF Trace Settings** node.
+5. In the box on the right, open the **WPF Trace Settings** node.
 
-7. Under **WPF Trace Settings**, click the category of settings that you want to enable (for example, **Data Binding**).
+6. Under **WPF Trace Settings**, select **Data Binding**.
 
-     A drop-down list control appears in the Settings column next to **Data Binding** or whatever category you clicked.
+   A drop-down list control appears in the Settings column next to **Data Binding**.
 
-8. Click the drop-down list and select the type of trace information that you want to see: **All**, **Critical**, **Error**, **Warning**, **Information**, **Verbose**, or **ActivityTracing**.
+7. Click the drop-down list and select the type of trace information that you want to see.
 
-     **Critical** enables tracing of Critical events only.
+   - **Critical** enables tracing of Critical events only.
 
-     **Error** enables tracing of Critical and Error events.
+   - **Error** enables tracing of Critical and Error events.
 
-     **Warning** enables tracing of Critical, Error, and Warning events.
+   - **Warning** enables tracing of Critical, Error, and Warning events.
 
-     **Information** enables tracing of Critical, Error, Warning, and Information events.
+   - **Information** enables tracing of Critical, Error, Warning, and Information events.
 
-     **Verbose** enables tracing of Critical, Error, Warning, Information, and Verbose events.
+   - **Verbose** enables tracing of Critical, Error, Warning, Information, and Verbose events.
 
-     **ActivityTracing** enables tracing of Stop, Start, Suspend, Transfer, and Resume events.
+   - **ActivityTracing** enables tracing of Stop, Start, Suspend, Transfer, and Resume events.
 
      For more information about what these levels of trace information mean, see <xref:System.Diagnostics.SourceLevels>.
 
 9. Click **OK**.
 
-### To disable WPF trace information
-
-1. On the **Tools** menu, select **Options**.
-
-2. In the **Options** dialog box, in the box on the left, open the **Debugging** node.
-
-3. Under **Debugging**, click **Output Window**.
-
-4. In the box on the right, look for **WPF Trace Settings**.
-
-5. Open the **WPF Trace Settings** node.
-
-6. Under **WPF Trace Settings**, click the category of settings that you want to enable (for example, **Data Binding**).
-
-     A drop-down list control appears in the Settings column next to **Data Binding** or whatever category you clicked.
-
-7. Click the drop-down list and select **Off**.
-
-8. Click **OK**.
-
 ## Related content
 - [Debugging WPF](../debugger/debugging-wpf.md)

docs/data-tools/media/simpleappcancelfill.png

@@ -1,7 +1,7 @@
 ---
 title: 'Specify build events (Visual Basic)'
 description: Explore how to use build events in Visual Basic to run scripts, macros, or other actions as a part of the compilation process.
-ms.date: 12/13/2024
+ms.date: 2/20/2025
 ms.subservice: compile-build
 ms.topic: how-to
 helpviewer_keywords:
@@ -54,14 +54,16 @@ Build events are specified in the **Build Events** dialog box, available from th
 :::moniker-end
 
 > [!NOTE]
-> Add a `call` statement before all post-build commands that run *.bat* files. For example, `call C:\MyFile.bat` or `call C:\MyFile.bat call C:\MyFile2.bat`.
+> Add a `call` statement before all post-build commands that run `.bat` files. For example, `call C:\MyFile.bat` or `call C:\MyFile.bat call C:\MyFile2.bat`.
 
 > [!NOTE]
 > If your pre-build or post-build event does not complete successfully, you can terminate the build by having your event action exit with a code other than zero (0), which indicates a successful action.
 
+You can reference "macros" (actually MSBuild property names) in the scripts. To reference a property, use the syntax `$(PropertyName)`, which is substituted with the property value when the event script is executed. For a list of commonly used values, see [MSBuild common properties](../msbuild/common-msbuild-project-properties.md). There may be other properties as well as defined in the project file, in any imported files in the project file, in environment variables, or passed on the command line using the `-p` MSBuild switch during command-line builds.
+
 ## Example: How to change manifest information using a post-build event
 
-The following procedure shows how to set the minimum operating system version in the application manifest using an *.exe* command called from a post-build event (the *.exe.manifest* file in the project directory). The minimum operating system version is a four-part number such as 4.10.0.0. To do this, the command will change the `<dependentOS>` section of the manifest:
+The following procedure shows how to set the minimum operating system version in the application manifest using an `.exe` command called from a post-build event (the `.exe.manifest` file in the project directory). The minimum operating system version is a four-part number such as 4.10.0.0. To do this, the command will change the `<dependentOS>` section of the manifest:
 
 ```xml
 <dependentOS>
@@ -159,9 +161,9 @@ The following procedure shows how to set the minimum operating system version in
 
      `C:\TEMP\ChangeOSVersionVB.exe "$(TargetPath).manifest" 5.1.2600.0`
 
-     When you build the project, this command will change the minimum operating system version in the application manifest to 5.1.2600.0.
+     When you build the project, this command changes the minimum operating system version in the application manifest to 5.1.2600.0.
 
-     The `$(TargetPath)` macro expresses the full path for the executable being created. Therefore, *$(TargetPath).manifest* will specify the application manifest created in the *bin* directory. Publishing will copy this manifest to the publishing location that you set earlier.
+     The `$(TargetPath)` macro expresses the full path for the executable being created. Therefore, `$(TargetPath).manifest` specifes the application manifest created in the *bin* directory. Publishing copies this manifest to the publishing location that you set earlier.
 
 8. Publish the project again. Go to the **Publish** page and click **Publish Now**.
 

docs/data-tools/media/simpleappnav.png

@@ -117,6 +117,22 @@ Diamond dependencies occur when multiple versions of a package are present in th
 
 By following these practices, you can effectively manage version-specific dependencies in your .NET projects, ensuring compatibility and stability across different target frameworks. See [Manage package dependencies in .NET applications](/dotnet/core/tools/dependencies), [Dependencies](/dotnet/standard/library-guidance/dependencies), and [How NuGet resolves package dependencies](/nuget/concepts/dependency-resolution).
 
+## Specify runtime identifiers
+
+A runtime identifier (RID) specifies a target runtime environment, which consists of a unique combination of operating system and CPU. Runtime identifiers affect the architecture-dependent NuGet packages that are used. Runtime identifiers consist of a shorthand code, for example, `linux-x64`. For more information and a list of RID codes for each supported operating system and CPU, see [.NET RID catalog](/dotnet/core/rid-catalog).
+
+RIDs are specified using the `<RuntimeIdentifier>` property in the project file. You can also use the plural form `<RuntimeIdentifiers>` to specify multiple target architectures.
+
+For .NET Core projects, target frameworks and target runtimes specified as RIDs act separately, and may be used in any supported combination, including multiple RIDs and multiple target frameworks. For a .NET Framework target, you can only specify a single RID.
+
+There's a distinction between a build that is inherently independent of RID (by specifying `RuntimeIdentifiers`) and a build that targets an RID (by specifying `RuntimeIdentifier` or by using the `-r` option with the `dotnet` CLI).
+
+If you specify `RuntimeIdentifiers`, the RID affects the NuGet packages your application binaries depend on, but the binary itself only depends on the target framework. Therefore, in this scenario, although separate output folders are created for each different target framework (for example, `bin\Debug\netstandard2.0` and `bin\Debug\net8.0`), they are not created for each RID.
+
+Specifying `RuntimeIdentifiers` does not inherently mean each build or publish operation targets each of the RIDs that are specified. Instead, it signals to NuGet Restore the set of RID-specific NuGet packages that need to be downloaded during a restore operation. This means that it's feasible to do `dotnet restore && dotnet publish -r linux-x64 --no-restore` to download the correct runtime packages for the RID you specify.
+
+If a single RuntimeIdentifier is specified (either via `-r` on the CLI or setting the `RuntimeIdentifier` property in an MSBuild project file), then most operations become platform-specific, including `dotnet publish` and `dotnet build`. In this case, the output paths and several other MSBuild properties are modified. For example, the output directory of a build with a single RID will have the RID appended: `bin\Debug\<TFM>\<RID>`.
+
 ## Comparison Between .NET Framework and .NET Core Multitargeting
 
 Multitargeting for .NET Core (and .NET 5 and later) is very different and more powerful than [multitargeting for .NET Framework projects](msbuild-multitargeting-overview.md).