Merged main into live

Author: mijacobs

docs/code-quality/migrate-from-legacy-analysis-to-net-analyzers.md

@@ -1,7 +1,7 @@
 ---
 title: Migrate from FxCop to source analysis (.NET)
 description: Analyze code for the first time or migrate your process from binary analysis (FxCop code analysis) to .NET analyzers for source analysis.
-ms.date: 09/17/2021
+ms.date: 04/30/2025
 ms.topic: conceptual
 f1_keywords:
  - "vs.projectpropertypages.codeanalysis"
@@ -50,6 +50,8 @@ To learn more about how to configure the .NET analyzers:
 
 - To find out about configuring analyzers using predefined rules with EditorConfig or a rule set file, see [Enable a category of rules](/dotnet/fundamentals/code-analysis/code-quality-rule-options).
 
+- To migrate from rule set files to EditorConfig, see [Convert an existing rule set file to an EditorConfig file](../code-quality/use-roslyn-analyzers.md#convert-an-existing-rule-set-file-to-an-editorconfig-file).
+
 ## Related content
 
 - [Migrate from FxCop analyzers to .NET analyzers](migrate-from-fxcop-analyzers-to-net-analyzers.md)

docs/code-quality/use-roslyn-analyzers.md

@@ -10,7 +10,7 @@ helpviewer_keywords:
 - code analysis, managed code
 - analyzers
 - Roslyn analyzers
-ms.date: 04/04/2024
+ms.date: 04/30/2025
 ---
 
 # Customize Roslyn analyzer rules
@@ -265,7 +265,7 @@ When you convert your existing rule set file to an EditorConfig file, save it at
 You can convert an existing rule set file to an EditorConfig file by using either the rule set editor or the command line.
 
 > [!NOTE]
-> .NET Core and .NET Standard projects don't support the menu commands for rule sets in Solution Explorer, for example, **Open Active Rule Set**. To specify a non-default rule set for a .NET Core or .NET Standard project, manually [add the **CodeAnalysisRuleSet** property](using-rule-sets-to-group-code-analysis-rules.md#specify-a-rule-set-for-a-project) to the project file. You can still configure the rules within the rule set in the rule set editor.
+> .NET Core and .NET 5+ projects don't support the menu commands for rule sets in Solution Explorer, for example, **Open Active Rule Set**. To specify a non-default rule set for a .NET Core or a .NET 5+ project, manually [add the **CodeAnalysisRuleSet** property](using-rule-sets-to-group-code-analysis-rules.md#specify-a-rule-set-for-a-project) to the project file. You can still configure the rules within the rule set in the rule set editor.
 
 To use the rule set editor, follow these steps. If your project already uses a specific rule set file for its `CodeAnalysisRuleSet` property value, you can convert it to an equivalent EditorConfig file from the rule set editor:
 
@@ -281,6 +281,11 @@ To use the rule set editor, follow these steps. If your project already uses a s
 
    The generated EditorConfig opens in the editor. Additionally, the MSBuild property `CodeAnalysisRuleSet` is updated in the project file so that it no longer references the original rule set file.
 
+   The original rule set file can be removed from the project.
+
+   > [!NOTE]
+   > In a .NET Framework project, the default rule set file can't be migrated or removed from the project.
+
 To use the command line, follow these steps:
 
 1. Install the NuGet package [Microsoft.CodeAnalysis.RulesetToEditorconfigConverter](https://www.nuget.org/packages/Microsoft.CodeAnalysis.RulesetToEditorconfigConverter).

docs/msbuild/customize-solution-build.md

@@ -1,7 +1,7 @@
 ---
-title: Customize the solution build
-description: Customize the solution build prepared by MSBuild for command-line builds of solutions with settings that don't affect project builds.
-ms.date: 02/28/2023
+title: Customize solution builds
+description: Customize the solution build MSBuild prepares for command-line builds with settings that don't affect project builds.
+ms.date: 04/29/2025
 ms.topic: how-to
 helpviewer_keywords:
 - MSBuild, transforms
@@ -10,13 +10,18 @@ author: ghogen
 ms.author: ghogen
 manager: mijacobs
 ms.subservice: msbuild
+
+#customer intent: As a builder, I want to know how to customize MSBuild solution builds, so I can extend solution builds with files and settings that affect different subsets of files.
+
 ---
 
-# Customize the solution build
+# Customize solution builds
+
+When MSBuild builds a solution file, it first translates the file internally into a project file, and then builds that project file. The generated project file can import a *before.\<solutionname>.sln.targets* file before it defines any targets, and import *after.\<solutionname>.sln.targets* after it imports the targets.
 
-When MSBuild builds a solution file, it first translates it internally into a project file and then builds that. The generated project file imports `before.{solutionname}.sln.targets` before defining any targets and `after.{solutionname}.sln.targets` after importing targets, including targets installed to the `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportBefore` and `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportAfter` directories.
+The *before* and *after* targets files are installed to the `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportBefore` and `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportAfter` directories.
 
-For example, you could define a new target to write a custom log message after building *MyCustomizedSolution.sln* by creating a file in the same directory named *after.MyCustomizedSolution.sln.targets* that contains
+So, for example, you could define a new target to write a custom log message after *MyCustomizedSolution.sln* builds, by creating the following file named *after.MyCustomizedSolution.sln.targets* in the same directory.
 
 ```xml
 <Project>
@@ -26,18 +31,20 @@ For example, you could define a new target to write a custom log message after b
 </Project>
 ```
 
-The solution build is separate from the project builds, so settings here do not affect project builds.
+The solution build is separate from the project builds, so these settings don't affect the project builds.
 
 > [!IMPORTANT]
-> Customizing the solution build in this way applies only to command-line builds with `MSBuild.exe` or `dotnet build`. It **does not** apply to builds inside Visual Studio. For this reason, it is not recommended to put customization at the solution level. A better alternative for customizing all projects in a solution is to use *Directory.Build.props* and *Directory.build.targets* files in the solution folder, as discussed elsewhere in this article.
+> Customizing the solution builds this way applies only to command-line builds using `MSBuild.exe` or `dotnet build`, and doesn't apply to builds inside Visual Studio. Therefore, it's best not to put customization at the solution level. A better alternative for customizing all projects in a solution is to use *Directory.Build.props* and *Directory.Build.targets* files in the solution folder.
 
-When you have many solution files that you want to extend in the same way, but you don't want to write to the `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\` folder (which usually requires elevated permissions), you can create the files *Directory.Solution.props* and *Directory.Solution.targets* and place them in the root path above the solution files you want to extend. *Directory.Solution.props* is imported at the beginning of the solution build, and *Directory.Solution.targets* is imported at the end of the solution build. When you build a solution file, *Directory.Build.props* and *Directory.Build.targets* are not imported, so you must use *Directory.Solution.props* and *Directory.Solution.targets* instead. They do not implicitly import each other.
+Writing to the `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile` folder usually requires elevated permissions. If you have many solution files to extend the same way, but you don't want to write to the *SolutionFile* folder, you can create the *Directory.Solution.props* and *Directory.Solution.targets* files and place them in the root path above the solution files you want to extend. *Directory.Solution.props* is imported at the beginning of the solution build, and *Directory.Solution.targets* is imported at the end of the solution build.
 
-When you have *Directory.Solution.props* or *Directory.Solution.targets* in a root folder, but you have a solution under that folder that you don't want to import them, you can use the solution-specific files mentioned previously `before.{solutionname}.sln.targets` and `after.{solutionname}.sln.targets` to set the properties `$(ImportDirectorySolutionProps)` and `$(ImportDirectorySolutionTargets)` to false. Or, you can use the properties `$(DirectorySolutionPropsPath)` and `$(DirectorySolutionTargetsPath)` to specify a different location for those files. This could be helpful if you have various subsets of your solutions that require certain property values or targets common to the subsets.
+When you build a solution file, *Directory.Build.props* and *Directory.Build.targets* aren't imported, so you must use *Directory.Solution.props* and *Directory.Solution.targets* instead. The two types of files don't implicitly import each other.
 
-> [!NOTE]
-> The solution build is supported with the `.slnx` solution file format in MSBuild 17.12 and later. Both `before.{solutionname}.slnx.targets` and `before.{solutionname}.sln.targets` work (and likewise for the `after` forms) with MSBuild 17.14 and later.
+When you have *Directory.Solution.props* or *Directory.Solution.targets* files in a root folder, but you don't want a solution under that folder to import those files, you can use the solution's *before.\<solutionname>.sln.targets* file to set the properties `ImportDirectorySolutionProps` and `ImportDirectorySolutionTargets` to `false`.
+
+Or, you can use the `$(DirectorySolutionPropsPath)` and `$(DirectorySolutionTargetsPath)` properties to specify a different location for those files. This approach can be helpful if subsets of your solutions require certain property values or targets in common.
 
-## Related content
+> [!NOTE]
+> The solution build is supported with the `.slnx` solution file format in MSBuild 17.12 and later. Both *before.\<solutionname>.slnx.targets* and *before.\<solutionname>.sln.targets*, and the corresponding *after* files, work with MSBuild 17.14 and later.
 
-- [Customize your build](customize-your-build.md).
+For more information about build customization options, see [Customize your build](customize-your-build.md).

docs/msbuild/customize-your-local-build.md

@@ -1,7 +1,7 @@
 ---
-title: Customize your local build
-description: Customize the build process just for your own local build without affecting files that you share with a source code repository.
-ms.date: 02/28/2023
+title: Customize local builds
+description: Customize the build process for local builds without affecting shared files in source code repositories.
+ms.date: 04/29/2025
 ms.topic: how-to
 helpviewer_keywords:
 - MSBuild, transforms
@@ -10,42 +10,41 @@ author: ghogen
 ms.author: ghogen
 manager: mijacobs
 ms.subservice: msbuild
+
+#customer intent: As a builder, I want to customize local builds, so that I can reproduce bugs or test configurations without affecting shared source code files.
+
 ---
 
 # Customize your local build
 
-When you work in a team that used a code repository like GitHub, source control, or any shared codebase, but you want to customize your builds on your local machine, perhaps temporarily to reproduce a bug or test a different configuration, it can be convenient to keep those customizations separate from the shared project files that are shared with the shared code repository. This article describes some build extensions available in MSBuild that let you make user-specific or local-only custom configurations.
+When you work with shared code in a code repository like GitHub, in source control, or with any shared codebase, you can use MSBuild to temporarily customize builds on your local machine. You might want to temporarily reproduce a bug or test a different configuration, and keep those customizations separate from the files in the shared code repository. This article describes some build extensions available in MSBuild that let you make user-specific or local-only custom build configurations.
 
-## .user file
+## Prerequisites
 
-Using `$(MSBuildProjectFullPath).user`, also referred as `.user` file in this context, is also an option. This file is intended to keep extensions, options, or variables that are specific to your local machine. It is not intended to be uploaded to source control, and it is automatically checked on `.gitignore`. For more extensive changes prefer changing the project itself, so that future maintainers do not have to know about this extension mechanism.
+- A Visual Studio project that builds with MSBuild.
 
-On supported multitargeted projects the `.user` file is automatically imported in inner builds and outer builds, so you can just create the file within the solution. If you are working on another type of build, you can still use the `.user` file. You can create it within your solution and then import it in your project file.
-```xml
-<Import Project="$(MSBuildProjectFullPath).user" Condition="Exists('$(MSBuildProjectFullPath).user')"/>
-```
+## Use the user file
 
-## MSBuildExtensionsPath and MSBuildUserExtensionsPath
+You can use `$(MSBuildProjectFullPath).user`, also called the *user* file in this context, to store extensions, options, or variables that are specific to your local machine. The user file isn't intended to be uploaded to source control, and is automatically checked on `.gitignore`. For more extensive changes, change the project itself, so future maintainers don't have to know about this extension mechanism.
 
-By convention, many core build logic files import
+On supported multitargeted projects, the user file is automatically imported in inner builds and outer builds, so you can create this file within the solution. If you're working on another type of build, you can use the user file by creating it within your solution and then importing it in your project file, as follows:
 
 ```xml
-$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\{TargetFileName}\ImportBefore\*.targets
+<Import Project="$(MSBuildProjectFullPath).user" Condition="Exists('$(MSBuildProjectFullPath).user')"/>
 ```
 
-before their contents, and
+<a name="msbuildextensionspath-and-msbuilduserextensionspath"></a>
+## Use MSBuildExtensionsPath and MSBuildUserExtensionsPath
 
-```xml
-$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\{TargetFileName}\ImportAfter\*.targets
-```
+By convention, many core build logic files import the `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportBefore\*.targets` file before their contents, and the `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\TargetFileName\ImportAfter\*.targets` file afterwards. This convention allows installed SDKs to augment the build logic of common project types.
 
-afterward. This convention allows installed SDKs to augment the build logic of common project types.
+The same directory structure is searched in `$(MSBuildUserExtensionsPath)`, which is the per-user folder *%LOCALAPPDATA%\\Microsoft\\MSBuild*. Files placed in that folder are imported for all builds of the corresponding project type run under that user's credentials.
 
-The same directory structure is searched in `$(MSBuildUserExtensionsPath)`, which is the per-user folder *%LOCALAPPDATA%\Microsoft\MSBuild*. Files placed in that folder will be imported for all builds of the corresponding project type run under that user's credentials. You can disable the user extensions by setting properties named after the importing file in the pattern `ImportUserLocationsByWildcardBefore{ImportingFileNameWithNoDots}`. For example, setting `ImportUserLocationsByWildcardBeforeMicrosoftCommonProps` to `false` would prevent importing `$(MSBuildUserExtensionsPath)\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*`.
+You can disable the user extensions by setting properties named after the importing file, in the pattern `ImportUserLocationsByWildcardBefore\<ImportingFileNameWithNoDots>`. For example, setting `ImportUserLocationsByWildcardBeforeMicrosoftCommonProps` to `false` prevents importing `$(MSBuildUserExtensionsPath\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*`.
 
-## Custom configuration based on project language
+## Create custom conditions based on project language
 
-If you need different behaviors depending on the .NET language (C#, Visual Basic, or F#), you can add property groups with conditions that depend on the project file extension in `$(MSBuildProjectExtension)` to define language-specific properties and their values.
+If you need different behaviors depending on the .NET language: C#, Visual Basic, or F#, you can add property groups with conditions that depend on the project file extension in `<MSBuildProjectExtension>` to define language-specific properties and their values.
 
 ```xml
 <PropertyGroup Condition="'$(MSBuildProjectExtension)' == '.vbproj'">
@@ -61,4 +60,5 @@ If you need different behaviors depending on the .NET language (C#, Visual Basic
 
 ## Related content
 
-- [Customize your build](customize-your-build.md).
+- [Customize your build](customize-your-build.md)
+- [Customize solution builds](customize-solution-build.md)

docs/windows/index.yml

@@ -157,6 +157,10 @@ additionalContent:
               url: /dotnet/maui/
             - text: Windows development with C++
               url: /cpp/windows/desktop-applications-visual-cpp
+            - text: Mobile development with C++
+              url: /cpp/cross-platform/
+            - text: Linux development with C++
+              url: /cpp/linux
         - title: Game development
           links:
             - text: Unity