Merge pull request #14199 from ghogen/msbuild-cleanup2

Clean up old, unsupported .NET version references

Author: JamesJBarnett

docs/msbuild/comparing-properties-and-items.md

@@ -74,7 +74,7 @@ Properties are passed to tasks as attributes. Within the task, an MSBuild proper
 
 Items are passed to tasks as <xref:Microsoft.Build.Framework.ITaskItem> objects. Within the task, <xref:Microsoft.Build.Framework.ITaskItem.ItemSpec%2A> represents the value of the item and <xref:Microsoft.Build.Framework.ITaskItem.GetMetadata%2A> retrieves its metadata.
 
-The item list of an item type can be passed as an array of `ITaskItem` objects. Beginning with the .NET Framework 3.5, items can be removed from an item list in a target by using the `Remove` attribute. Because items can be removed from an item list, it is possible for an item type to have zero items. If an item list is passed to a task, the code in the task should check for this possibility.
+The item list of an item type can be passed as an array of `ITaskItem` objects. Items can be removed from an item list in a target by using the `Remove` attribute. Because items can be removed from an item list, it is possible for an item type to have zero items. If an item list is passed to a task, the code in the task should check for this possibility.
 
 ## Property and item evaluation order
 

docs/msbuild/configure-tasks.md

@@ -12,13 +12,13 @@ ms.subservice: msbuild
 
 You can configure MSBuild targets and tasks to run out-of-process with MSBuild so that you can run tasks in contexts that differ from the one running the overall build. This can be useful when running tasks that are not compatible with 64-bit MSBuild and when targeting a different version of .NET Framework. 
 
-For example, you can target a 32-bit .NET Framework 2.0 application while the development computer is running on a 64-bit .NET Framework 4.5 operating system. You can also target computers that run with the .NET Framework 4 or earlier. The combination of 32- or 64-bitness and the specific .NET Framework version is known as the *target context*.
+For example, you can target a 32-bit .NET Framework 3.5 SP1 application while the development computer is running on a 64-bit .NET Framework 4.7.2 operating system. The combination of 32- or 64-bitness and the specific .NET Framework version is known as the *target context*.
 
 ## Tasks
 
- MSBuild runs certain build tasks out of process to target a larger set of contexts.  For example, a 32-bit MSBuild might run a build task in a 64-bit process. This is controlled by `UsingTask` arguments and `Task` parameters. The targets installed by the .NET Framework 4.5 set these arguments and parameters, and no changes are required to build applications for the various target contexts.
+ MSBuild runs certain build tasks out of process to target a larger set of contexts.  For example, a 32-bit MSBuild might run a build task in a 64-bit process. This is controlled by `UsingTask` arguments and `Task` parameters. The targets installed with MSBuild set these arguments and parameters, and no changes are required to build applications for the various target contexts.
 
- If you want to create your own target context, you must set these arguments and parameters appropriately. Look in the .NET Framework 4.5 *Microsoft.Common.targets* file and the *Microsoft.Common.Tasks* file for examples.  For information about how to create a custom task that can work with multiple target contexts, or how to modify existing tasks, see [How to: Configure targets and tasks](../msbuild/how-to-configure-targets-and-tasks.md).
+ If you want to create your own target context, you must set these arguments and parameters appropriately. Look in the *Microsoft.Common.targets* file and the *Microsoft.Common.Tasks* file for examples.  For information about how to create a custom task that can work with multiple target contexts, or how to modify existing tasks, see [How to: Configure targets and tasks](../msbuild/how-to-configure-targets-and-tasks.md).
 
 ## Errors arising from incorrect configuration
 

docs/msbuild/generatebootstrapper-task.md

@@ -148,27 +148,22 @@ In addition to the parameters listed above, this task inherits parameters from t
 
 ## Example
 
-The following example uses the `GenerateBootstrapper` task to install an application that must have the .NET Framework 2.0 installed as a prerequisite.
+The following example uses the `GenerateBootstrapper` task to install an application that must have the .NET Framework 4.8 installed as a prerequisite.
 
 ```xml
-<Project>
-
-    <ItemGroup>
-        <BootstrapperFile Include="Microsoft.Net.Framework.2.0">
-            <ProductName>Microsoft .NET Framework 2.0</ProductName>
-        </BootstrapperFile>
-    </ItemGroup>
-
-    <Target Name="BuildBootstrapper">
-        <GenerateBootstrapper
-            ApplicationFile="WindowsApplication1.application"
-            ApplicationName="WindowsApplication1"
-            ApplicationUrl="http://mycomputer"
-            BootstrapperItems="@(BootstrapperFile)"
-            OutputPath="C:\output" />
-    </Target>
-
-</Project>
+<ItemGroup>
+  <BootstrapperFile Include="Microsoft.Net.Framework.4.8">
+    <ProductName>.NET Framework 4.8</ProductName>
+  </BootstrapperFile>
+</ItemGroup>
+
+<Target Name="CustomBootstrapper">
+  <GenerateBootstrapper
+    ApplicationFile="MyApp.exe"
+    BootstrapperItems="@(BootstrapperFile)"
+    OutputPath="$(OutputPath)"
+    ComponentsLocation="Relative" />
+</Target>
 ```
 
 ## See also

docs/msbuild/import-element-msbuild.md

@@ -71,7 +71,7 @@ Imports the contents of one project file into another project file.
 
 ## Wildcards
 
- In the .NET Framework 4, MSBuild allows wildcards in the Project attribute. When there are wildcards, all matches found are sorted (for reproducibility), and then they are imported in that order as if the order had been explicitly set.
+ MSBuild allows wildcards in the Project attribute. When there are wildcards, all matches found are sorted (for reproducibility), and then they are imported in that order as if the order had been explicitly set.
 
  This is useful if you want to offer an extensibility point so that someone else can import a file without requiring you to explicitly add the file name to the importing file. For this purpose, *Microsoft.Common.Targets* contains the following line at the top of the file.
 

docs/msbuild/itemgroup-element-msbuild.md

@@ -58,7 +58,7 @@ In addition to the generic `Item` element, ItemGroup allows child elements that
 | Element | Description |
 | - | - |
 | [Project](../msbuild/project-element-msbuild.md) | Required root element of an MSBuild project file. |
-| [Target](../msbuild/target-element-msbuild.md) | Starting with .NET Framework 3.5, the `ItemGroup` element can appear inside a `Target` element. For more information, see [Targets](../msbuild/msbuild-targets.md). |
+| [Target](../msbuild/target-element-msbuild.md) | The `ItemGroup` element can appear inside a `Target` element. For more information, see [Targets](../msbuild/msbuild-targets.md). |
 
 ## Example
 

docs/msbuild/msbuild-multitargeting-overview.md

@@ -10,16 +10,14 @@ ms.subservice: msbuild
 ---
 # Target multiple framework versions and platforms
 
-By using MSBuild, you can compile an application to run on any one of several versions of the .NET Framework, and on any one of several system platforms. For example, you can compile an application to run on the .NET Framework 2.0 on a 32-bit platform, and compile the same application to run on the .NET Framework 4.5 on a 64-bit platform.
+By using MSBuild, you can compile an application to run on any one of several versions of the .NET Framework, and on any one of several system platforms. For example, you can compile an application to run on the .NET Framework 3.5 SP1 on a 32-bit platform, and compile the same application to run on the .NET Framework 4.7.2 on a 64-bit platform.
 
 > [!NOTE]
 > This article describes an older type of multitargeting that applies to .NET Framework builds in which a project can target only one framework and only one platform at a time. In .NET Core and .NET 5 and later, you can use a newer type of multitargeting by using the `TargetFrameworks` (plural) property in a project file. When you build with `dotnet build` or similar .NET CLI commands, or with Visual Studio after reloading the project, your build uses the newer type of multitargeting, in which multiple builds occur, once for each target framework listed. See [Target frameworks](/dotnet/standard/frameworks).
 
  These are some of the features of MSBuild targeting:
 
-- You can develop an application that targets an earlier version of the .NET Framework, for example, versions 2.0, 3.5, or 4.
-
-- You can target a framework other than the .NET Framework, for example, the Silverlight Framework.
+- You can develop an application that targets an earlier version of the .NET Framework, for example, version 3.5 SP1.
 
 - You can target a *framework profile*, which is a predefined subset of a target framework.
 
@@ -29,19 +27,19 @@ By using MSBuild, you can compile an application to run on any one of several ve
 
 ## Target framework and platform
 
- A *target framework* is the version of the .NET Framework that a project is built to run on, and a *target platform* is the system platform that the project is built to run on.  For example, you might want to target a .NET Framework 2.0 application to run on a 32-bit platform that is compatible with the 80x86 processor family (x86). The combination of target framework and target platform is known as the *target context*. For more information, see [Target framework and target platform](../msbuild/msbuild-target-framework-and-target-platform.md).
+ A *target framework* is the version of the .NET Framework that a project is built to run on, and a *target platform* is the system platform that the project is built to run on.  For example, you might want to target a .NET Framework 3.5 SP1 application to run on a 32-bit platform that is compatible with the 80x86 processor family (x86). The combination of target framework and target platform is known as the *target context*. For more information, see [Target framework and target platform](../msbuild/msbuild-target-framework-and-target-platform.md).
 
 ## Toolset (ToolsVersion)
 
- A Toolset collects together the tools, tasks, and targets that are used to create the application. A Toolset includes compilers such as *csc.exe* and *vbc.exe*, the common targets file (*microsoft.common.targets*), and the common tasks file (*microsoft.common.tasks*). The 4.5 Toolset can be used to target .NET Framework versions 2.0, 3.0, 3.5, 4, and 4.5. However, the 2.0 Toolset can only be used to target the .NET Framework version 2.0. For more information, see [Toolset (ToolsVersion)](../msbuild/msbuild-toolset-toolsversion.md).
+ A Toolset collects together the tools, tasks, and targets that are used to create the application. A Toolset includes compilers such as *csc.exe* and *vbc.exe*, the common targets file (*microsoft.common.targets*), and the common tasks file (*microsoft.common.tasks*). For more information, see [Toolset (ToolsVersion)](../msbuild/msbuild-toolset-toolsversion.md).
 
 ## Reference assemblies
 
  The reference assemblies that are specified in the Toolset help you design and build an application. These reference assemblies not only enable a particular target build, but also restrict components and features in the Visual Studio IDE to those that are compatible with the target. For more information, see [Resolve assemblies at design time](../msbuild/resolving-assemblies-at-design-time.md).
 
 ## Configure targets and tasks
 
- You can configure MSBuild targets and tasks to run out-of-process with MSBuild so that you can target contexts that are considerably different than the one you are running on.  For example, you can target a 32-bit, .NET Framework 2.0 application while the development computer is running on a 64-bit platform with .NET Framework 4.5. For more information, see [Configure targets and tasks](../msbuild/configure-tasks.md).
+ You can configure MSBuild targets and tasks to run out-of-process with MSBuild so that you can target contexts that are considerably different than the one you are running on.  For example, you can target a 32-bit, .NET Framework 3.5 SP1 application while the development computer is running on a 64-bit platform with .NET Framework 4.7.2. For more information, see [Configure targets and tasks](../msbuild/configure-tasks.md).
 
 ## Troubleshooting
 

docs/msbuild/msbuild-target-framework-and-target-platform.md

@@ -19,7 +19,7 @@ A project can be built to run on a *target framework*, which is a particular ver
 
  A target framework is the particular version of the .NET Framework that your project is built to run on. Specification of a target framework is required because it enables compiler features and assembly references that are exclusive to that version of the framework.
 
- Currently, the following versions of the .NET Framework are available for use:
+ Currently, the following versions of the .NET Framework are available for use, although some are no longer supported by Microsoft, and some have planned future dates beyond which they will no longer be supported. For the latest support information, see [.NET Framework](/lifecycle/products/microsoft-net-framework):
 
 - The .NET Framework 2.0 (included in Visual Studio 2005)
 

docs/msbuild/msbuild.md

@@ -79,7 +79,7 @@ The command line `dotnet build --help` lists the command-line options specific t
 
  MSBuild uses an XML-based project file format that's straightforward and extensible. The MSBuild project file format lets developers describe the items that are to be built, and also how they are to be built for different operating systems and configurations. In addition, the project file format lets developers author reusable build rules that can be factored into separate files so that builds can be performed consistently across different projects in the product.
 
- The Visual Studio build system stores project-specific logic in the project file itself, and uses imported MSBuild XML files with extensions like `.props` and `.targets` to define the standard build logic. The `.props` files define MSBuild properties, and `.targets` files define MSBuild targets. These imports are sometimes visible in the Visual Studio project file, but in newer projects such as .NET Core, .NET 5 and .NET 6 projects, you don't see the imports in the project file; instead, you see an SDK reference, which looks like this:
+ The Visual Studio build system stores project-specific logic in the project file itself, and uses imported MSBuild XML files with extensions like `.props` and `.targets` to define the standard build logic. The `.props` files define MSBuild properties, and `.targets` files define MSBuild targets. These imports are sometimes visible in the Visual Studio project file, but in .NET SDK projects, which are used in .NET Core (and .NET 5 and later), you don't see the imports in the project file; instead, you see an SDK reference, which looks like this:
 
 ```xml
 <Project Sdk="Microsoft.Net.Sdk">
@@ -179,7 +179,7 @@ The command line `dotnet build --help` lists the command-line options specific t
 
 ## <a name="BKMK_Multitargeting"></a> Multitargeting
 
- By using Visual Studio, you can compile an application to run on any one of several versions of .NET Framework or .NET Core, including .NET 5 and later. For example, you can compile an application to run on .NET Framework 4 on a 32-bit platform, and you can compile the same application to run on .NET Framework 4.8 on a 64-bit platform. The ability to compile to more than one framework is named multitargeting.
+ By using Visual Studio, you can compile an application to run on any one of several versions of .NET Framework or .NET Core, including .NET 5 and later. For example, you can compile an application to run on .NET Framework 3.5 SP1 on a 32-bit platform, and you can compile the same application to run on .NET Framework 4.8 on a 64-bit platform. The ability to compile to more than one framework is named multitargeting.
 
  These are some of the benefits of multitargeting:
 

docs/msbuild/registering-extensions-of-the-dotnet-framework.md

@@ -18,12 +18,12 @@ You can develop an assembly that extends a specific version of the .NET Framewor
 
  For example, assume that the Trey Research company has developed a library that extends the .NET Framework 4, and wants the library assemblies to appear in the **Add References** dialog box when a project targets the .NET Framework 4. Also assume that the assemblies are 32-bit assemblies running on a 32-bit computer or 64-bit assemblies running on a 64-bit computer, and that they will be installed in the *C:\TreyResearch\Extensions4\\* folder.
 
- Register this folder by using this key: **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\\.NETFramework\v4.0.21006\AssemblyFoldersEx\TreyResearch\\**. Give the key this default value: **C:\TreyResearch\Extensions4**.
+ Register this folder by using this key: **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\\.NETFramework\v4.0.30319\AssemblyFoldersEx\TreyResearch\\**. Give the key this default value: **C:\TreyResearch\Extensions4**.
 
 > [!NOTE]
 > The build number of the .NET Framework version may be different.
 
- To register a 32-bit assembly on a 64-bit computer, use the Wow6432 node, for example: **HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\\.NETFramework\v4.0.21006\AssemblyFoldersEx\TreyResearch\\**.
+ To register a 32-bit assembly on a 64-bit computer, use the Wow6432 node, for example: **HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\\.NETFramework\v4.0.30319\AssemblyFoldersEx\TreyResearch\\**.
 
 ### Related content
 

docs/msbuild/target-element-msbuild.md

@@ -68,8 +68,8 @@ Contains a set of tasks for MSBuild to execute sequentially.
 | Element | Description |
 | - | - |
 | [Task](../msbuild/task-element-msbuild.md) | Creates and executes an instance of an MSBuild task. There may be zero or more tasks in a target. |
-| [PropertyGroup](../msbuild/propertygroup-element-msbuild.md) | Contains a set of user-defined `Property` elements. Starting in the .NET Framework 3.5, a `Target` element may contain `PropertyGroup` elements. |
-| [ItemGroup](../msbuild/itemgroup-element-msbuild.md) | Contains a set of user-defined `Item` elements. Starting in the .NET Framework 3.5, a `Target` element may contain `ItemGroup` elements. For more information, see [Items](../msbuild/msbuild-items.md). |
+| [PropertyGroup](../msbuild/propertygroup-element-msbuild.md) | Contains a set of user-defined `Property` elements. A `Target` element may contain `PropertyGroup` elements. |
+| [ItemGroup](../msbuild/itemgroup-element-msbuild.md) | Contains a set of user-defined `Item` elements. A `Target` element may contain `ItemGroup` elements. For more information, see [Items](../msbuild/msbuild-items.md). |
 | [OnError](../msbuild/onerror-element-msbuild.md) | Causes one or more targets to execute if the `ContinueOnError` attribute is ErrorAndStop (or `false`) for a failed task. There may be zero or more `OnError` elements in a target. If `OnError` elements are present, they must be the last elements in the `Target` element.<br /><br /> For information about the `ContinueOnError` attribute, see [Task element (MSBuild)](../msbuild/task-element-msbuild.md). |
 
 ### Parent elements