Fix .NET Core 3.x naming - restore .NET Core naming for 3.x and earlier versions

Co-authored-by: danroth27 <1874516+danroth27@users.noreply.github.com>

Author: Copilot

aspnetcore/fundamentals/target-aspnetcore.md

@@ -24,9 +24,9 @@ As preview releases of ASP.NET Core are made available, breaking changes are pos
 
 ## Use the ASP.NET Core shared framework
 
-With the release of .NET 3.0, many ASP.NET Core assemblies are no longer published to NuGet as packages. Instead, the assemblies are included in the `Microsoft.AspNetCore.App` shared framework, which is installed with the .NET SDK and runtime installers. For a list of packages no longer being published, see [Remove obsolete package references](xref:migration/22-to-30#remove-obsolete-package-references).
+With the release of .NET Core 3.0, many ASP.NET Core assemblies are no longer published to NuGet as packages. Instead, the assemblies are included in the `Microsoft.AspNetCore.App` shared framework, which is installed with the .NET SDK and runtime installers. For a list of packages no longer being published, see [Remove obsolete package references](xref:migration/22-to-30#remove-obsolete-package-references).
 
-As of .NET 3.0, projects using the `Microsoft.NET.Sdk.Web` MSBuild SDK implicitly reference the shared framework. Projects using the `Microsoft.NET.Sdk` or `Microsoft.NET.Sdk.Razor` SDK must reference ASP.NET Core to use ASP.NET Core APIs in the shared framework.
+As of .NET Core 3.0, projects using the `Microsoft.NET.Sdk.Web` MSBuild SDK implicitly reference the shared framework. Projects using the `Microsoft.NET.Sdk` or `Microsoft.NET.Sdk.Razor` SDK must reference ASP.NET Core to use ASP.NET Core APIs in the shared framework.
 
 To reference ASP.NET Core, add the following `<FrameworkReference>` element to your project file:
 
@@ -114,7 +114,7 @@ This section doesn't discuss multi-targeting to support multiple versions of MVC
 
 A project that includes [Razor views](xref:mvc/views/overview) or [Razor Pages](xref:razor-pages/index) must use the [Microsoft.NET.Sdk.Razor SDK](xref:razor-pages/sdk).
 
-If the project targets .NET 3.x, it requires:
+If the project targets .NET Core 3.x, it requires:
 
 * An `AddRazorSupportForMvc` MSBuild property set to `true`.
 * A `<FrameworkReference>` element for the shared framework.
@@ -145,7 +145,7 @@ If the project targets .NET Standard instead, a [Microsoft.AspNetCore.Mvc](https
 
 ### Tag Helpers
 
-A project that includes [Tag Helpers](xref:mvc/views/tag-helpers/intro) should use the `Microsoft.NET.Sdk` SDK. If targeting .NET 3.x, add a `<FrameworkReference>` element for the shared framework. For example:
+A project that includes [Tag Helpers](xref:mvc/views/tag-helpers/intro) should use the `Microsoft.NET.Sdk` SDK. If targeting .NET Core 3.x, add a `<FrameworkReference>` element for the shared framework. For example:
 
 [!code-xml[](target-aspnetcore/samples/single-tfm/netcoreapp3.1-basic-library.csproj)]
 
@@ -155,7 +155,7 @@ If targeting .NET Standard (to support versions earlier than ASP.NET Core 3.x),
 
 ### View components
 
-A project that includes [View components](xref:mvc/views/view-components) should use the `Microsoft.NET.Sdk` SDK. If targeting .NET 3.x, add a `<FrameworkReference>` element for the shared framework. For example:
+A project that includes [View components](xref:mvc/views/view-components) should use the `Microsoft.NET.Sdk` SDK. If targeting .NET Core 3.x, add a `<FrameworkReference>` element for the shared framework. For example:
 
 [!code-xml[](target-aspnetcore/samples/single-tfm/netcoreapp3.1-basic-library.csproj)]
 
@@ -169,7 +169,7 @@ Multi-targeting is required to author a library that supports multiple variants
 
 * ASP.NET Core 2.1 targeting .NET Framework 4.6.1
 * ASP.NET Core 2.x targeting .NET 2.x
-* ASP.NET Core 3.x targeting .NET 3.x
+* ASP.NET Core 3.x targeting .NET Core 3.x
 
 The following project file supports these variants via the `TargetFrameworks` property:
 
@@ -179,7 +179,7 @@ With the preceding project file:
 
 * The `Markdig` package is added for all consumers.
 * A reference to [Microsoft.AspNetCore.Mvc.Razor](https://www.nuget.org/packages/Microsoft.AspNetCore.Mvc.Razor) is added for consumers targeting .NET Framework 4.6.1 or later or .NET 2.x. Version 2.1.0 of the package works with ASP.NET Core 2.2 because of backwards compatibility.
-* The shared framework is referenced for consumers targeting .NET 3.x. The `Microsoft.AspNetCore.Mvc.Razor` package is included in the shared framework.
+* The shared framework is referenced for consumers targeting .NET Core 3.x. The `Microsoft.AspNetCore.Mvc.Razor` package is included in the shared framework.
 
 Alternatively, .NET Standard 2.0 could be targeted instead of targeting both .NET 2.1 and .NET Framework 4.6.1:
 
@@ -194,20 +194,20 @@ If your library needs to call platform-specific APIs, target specific .NET imple
 
 ## Use an API that hasn't changed
 
-Imagine a scenario in which you're upgrading a middleware library from .NET 2.2 to 3.1. The ASP.NET Core middleware APIs being used in the library haven't changed between ASP.NET Core 2.2 and 3.1. To continue supporting the middleware library in .NET 3.1, take the following steps:
+Imagine a scenario in which you're upgrading a middleware library from .NET Core 2.2 to 3.1. The ASP.NET Core middleware APIs being used in the library haven't changed between ASP.NET Core 2.2 and 3.1. To continue supporting the middleware library in .NET Core 3.1, take the following steps:
 
 * Follow the [standard library guidance](/dotnet/standard/library-guidance/).
 * Add a package reference for each API's NuGet package if the corresponding assembly doesn't exist in the shared framework.
 
 ## Use an API that changed
 
-Imagine a scenario in which you're upgrading a library from .NET 2.2 to .NET 3.1. An ASP.NET Core API being used in the library has a [breaking change](/dotnet/core/compatibility/breaking-changes) in ASP.NET Core 3.1. Consider whether the library can be rewritten to not use the broken API in all versions.
+Imagine a scenario in which you're upgrading a library from .NET Core 2.2 to .NET Core 3.1. An ASP.NET Core API being used in the library has a [breaking change](/dotnet/core/compatibility/breaking-changes) in ASP.NET Core 3.1. Consider whether the library can be rewritten to not use the broken API in all versions.
 
 If you can rewrite the library, do so and continue to target an earlier target framework (for example, .NET Standard 2.0 or .NET Framework 4.6.1) with package references.
 
 If you can't rewrite the library, take the following steps:
 
-* Add a target for .NET 3.1.
+* Add a target for .NET Core 3.1.
 * Add a `<FrameworkReference>` element for the shared framework.
 * Use the [#if preprocessor directive](/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-if) with the appropriate target framework symbol to conditionally compile code.
 
@@ -224,16 +224,16 @@ Imagine that you want to use an ASP.NET Core API that was introduced in ASP.NET
 
 If the library functionally requires the API and there's no way to implement it down-level:
 
-* Target .NET 3.x only.
+* Target .NET Core 3.x only.
 * Add a `<FrameworkReference>` element for the shared framework.
 
 If the library can implement the feature in a different way:
 
-* Add .NET 3.x as a target framework.
+* Add .NET Core 3.x as a target framework.
 * Add a `<FrameworkReference>` element for the shared framework.
 * Use the [#if preprocessor directive](/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-if) with the appropriate target framework symbol to conditionally compile code.
 
-For example, the following Tag Helper uses the <xref:Microsoft.AspNetCore.Hosting.IWebHostEnvironment> interface introduced in ASP.NET Core 3.1. Consumers targeting .NET 3.1 execute the code path defined by the `NETCOREAPP3_1` target framework symbol. The Tag Helper's constructor parameter type changes to <xref:Microsoft.AspNetCore.Hosting.IHostingEnvironment> for .NET 2.1 and .NET Framework 4.6.1 consumers. This change was necessary because ASP.NET Core 3.1 marked `IHostingEnvironment` as obsolete and recommended `IWebHostEnvironment` as the replacement.
+For example, the following Tag Helper uses the <xref:Microsoft.AspNetCore.Hosting.IWebHostEnvironment> interface introduced in ASP.NET Core 3.1. Consumers targeting .NET Core 3.1 execute the code path defined by the `NETCOREAPP3_1` target framework symbol. The Tag Helper's constructor parameter type changes to <xref:Microsoft.AspNetCore.Hosting.IHostingEnvironment> for .NET Core 2.1 and .NET Framework 4.6.1 consumers. This change was necessary because ASP.NET Core 3.1 marked `IHostingEnvironment` as obsolete and recommended `IWebHostEnvironment` as the replacement.
 
 ```csharp
 [HtmlTargetElement("script", Attributes = "asp-inline")]

aspnetcore/grpc/grpcweb.md

@@ -51,7 +51,7 @@ Alternatively, the gRPC-Web middleware can be configured so that all services su
 :::code language="csharp" source="~/grpc/grpcweb/sample/8.x/GrpcGreeter/Program.cs" id="snippet_WebEnableAllServices" highlight="9":::
 
 > [!NOTE]
-> There is a known issue that causes gRPC-Web to fail when [hosted by HTTP.sys](xref:fundamentals/servers/httpsys) in .NET 3.x.
+> There is a known issue that causes gRPC-Web to fail when [hosted by HTTP.sys](xref:fundamentals/servers/httpsys) in .NET Core 3.x.
 >
 > A workaround to get gRPC-Web working on HTTP.sys is available in [Grpc-web experimental and UseHttpSys()? (grpc/grpc-dotnet #853)](https://github.com/grpc/grpc-dotnet/issues/853#issuecomment-610078202).
 

aspnetcore/grpc/grpcweb/includes/grpcweb3-5.md

@@ -36,7 +36,7 @@ Alternatively, the gRPC-Web middleware can be configured so that all services su
 [!code-csharp[](~/grpc/grpcweb/sample/3-5.x/AllServicesSupportExample_Startup.cs?name=snippet_1&highlight=12)]
 
 > [!NOTE]
-> There is a known issue that causes gRPC-Web to fail when [hosted by HTTP.sys](xref:fundamentals/servers/httpsys) in .NET 3.x.
+> There is a known issue that causes gRPC-Web to fail when [hosted by HTTP.sys](xref:fundamentals/servers/httpsys) in .NET Core 3.x.
 >
 > A workaround to get gRPC-Web working on HTTP.sys is available in [Grpc-web experimental and UseHttpSys()? (grpc/grpc-dotnet #853)](https://github.com/grpc/grpc-dotnet/issues/853#issuecomment-610078202).
 

aspnetcore/grpc/grpcweb/includes/grpcweb6-7.md

@@ -36,7 +36,7 @@ Alternatively, the gRPC-Web middleware can be configured so that all services su
 :::code language="csharp" source="~/grpc/grpcweb/sample/8.x/GrpcGreeter/Program.cs" id="snippet_WebEnableAllServices" highlight="9":::
 
 > [!NOTE]
-> There is a known issue that causes gRPC-Web to fail when [hosted by HTTP.sys](xref:fundamentals/servers/httpsys) in .NET 3.x.
+> There is a known issue that causes gRPC-Web to fail when [hosted by HTTP.sys](xref:fundamentals/servers/httpsys) in .NET Core 3.x.
 >
 > A workaround to get gRPC-Web working on HTTP.sys is available in [Grpc-web experimental and UseHttpSys()? (grpc/grpc-dotnet #853)](https://github.com/grpc/grpc-dotnet/issues/853#issuecomment-610078202).
 

aspnetcore/grpc/interprocess/includes/interprocess5-7.md

@@ -12,7 +12,7 @@ Processes running on the same machine can be designed to communicate with each o
 
 gRPC calls are sent from a client to a server. To communicate between apps on a machine with gRPC, at least one app must host an ASP.NET Core gRPC server.
 
-ASP.NET Core and gRPC can be hosted in any app using .NET 3.1 or later by adding the `Microsoft.AspNetCore.App` framework to the project.
+ASP.NET Core and gRPC can be hosted in any app using .NET Core 3.1 or later by adding the `Microsoft.AspNetCore.App` framework to the project.
 
 [!code-xml[](~/grpc/interprocess/Server.csproj?highlight=4-6)]
 

aspnetcore/grpc/migration.md

@@ -21,7 +21,7 @@ Due to the implementation of the underlying stack, not all features work in the
 gRPC C-core and gRPC for .NET have different platform support:
 
 * **gRPC C-core**: A C++ gRPC implementation with its own TLS and HTTP/2 stacks. The `Grpc.Core` package is a .NET wrapper around gRPC C-core and contains a gRPC client and server. It supports .NET Framework, .NET, and .NET 5 or later.
-* **gRPC for .NET**: Designed for .NET 3.x and .NET 5 or later. It uses TLS and HTTP/2 stacks built into modern .NET releases. The `Grpc.AspNetCore` package contains a gRPC server that is hosted in ASP.NET Core and requires .NET 3.x or .NET 5 or later. The `Grpc.Net.Client` package contains a gRPC client. The client in `Grpc.Net.Client` has limited support for .NET Framework using <xref:System.Net.Http.WinHttpHandler>.
+* **gRPC for .NET**: Designed for .NET Core 3.x and .NET 5 or later. It uses TLS and HTTP/2 stacks built into modern .NET releases. The `Grpc.AspNetCore` package contains a gRPC server that is hosted in ASP.NET Core and requires .NET Core 3.x or .NET 5 or later. The `Grpc.Net.Client` package contains a gRPC client. The client in `Grpc.Net.Client` has limited support for .NET Framework using <xref:System.Net.Http.WinHttpHandler>.
 
 For more information, see <xref:grpc/supported-platforms>.
 

aspnetcore/grpc/performance.md

@@ -62,7 +62,7 @@ var channel = GrpcChannel.ForAddress("https://localhost", new GrpcChannelOptions
 
 :::moniker-end
 
-There are a couple of workarounds for .NET 3.1 apps:
+There are a couple of workarounds for .NET Core 3.1 apps:
 
 * Create separate gRPC channels for areas of the app with high load. For example, the `Logger` gRPC service might have a high load. Use a separate channel to create the `LoggerClient` in the app.
 * Use a pool of gRPC channels, for example,  create a list of gRPC channels. `Random` is used to pick a channel from the list each time a gRPC channel is needed. Using `Random` randomly distributes calls over multiple connections.

aspnetcore/grpc/supported-platforms.md

@@ -29,7 +29,7 @@ gRPC on .NET supports both wire-formats. `application/grpc` is used by default.
 
 ## ASP.NET Core gRPC server requirements
 
-Hosting gRPC services with ASP.NET Core requires .NET 3.x or later.
+Hosting gRPC services with ASP.NET Core requires .NET Core 3.x or later.
 
 > [!div class="checklist"]
 >

aspnetcore/grpc/troubleshoot.md

@@ -67,7 +67,7 @@ The .NET gRPC client can call insecure gRPC services by specifing `http` in the
 There are some additional requirements to call insecure gRPC services depending on the .NET version an app is using:
 
 * .NET 5 or later requires [Grpc.Net.Client](https://www.nuget.org/packages/Grpc.Net.Client) version 2.32.0 or later.
-* .NET 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`. For more information see [Asp.Net Core 3.x: Call insecure gRPC services with the .NET client](xref:grpc/troubleshoot?view=aspnetcore-3.1#call-insecure-grpc-services-with-net-client-2):
+* .NET Core 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`. For more information see [Asp.Net Core 3.x: Call insecure gRPC services with the .NET client](xref:grpc/troubleshoot?view=aspnetcore-3.1#call-insecure-grpc-services-with-net-client-2):
 
 > [!IMPORTANT]
 > Insecure gRPC services must be hosted on a HTTP/2-only port. For more information, see [ASP.NET Core protocol negotiation](xref:grpc/aspnetcore#protocol-negotiation).

aspnetcore/grpc/troubleshoot/includes/troubleshoot3-7.md

@@ -82,7 +82,7 @@ The .NET gRPC client can call insecure gRPC services by specifing `http` in the
 There are some additional requirements to call insecure gRPC services depending on the .NET version an app is using:
 
 * .NET 5 or later requires [Grpc.Net.Client](https://www.nuget.org/packages/Grpc.Net.Client) version 2.32.0 or later.
-* .NET 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`:
+* .NET Core 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`:
 
     ```csharp
     // This switch must be set before creating the GrpcChannel/HttpClient.
@@ -94,7 +94,7 @@ There are some additional requirements to call insecure gRPC services depending
     var client = new Greet.GreeterClient(channel);
     ```
 
-The `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch is only required for .NET 3.x. It does nothing in .NET 5 and isn't required.
+The `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch is only required for .NET Core 3.x. It does nothing in .NET 5 and isn't required.
 
 > [!IMPORTANT]
 > Insecure gRPC services must be hosted on a HTTP/2-only port. For more information, see [ASP.NET Core protocol negotiation](xref:grpc/aspnetcore#protocol-negotiation).
@@ -422,7 +422,7 @@ The .NET gRPC client can call insecure gRPC services by specifing `http` in the
 There are some additional requirements to call insecure gRPC services depending on the .NET version an app is using:
 
 * .NET 5 or later requires [Grpc.Net.Client](https://www.nuget.org/packages/Grpc.Net.Client) version 2.32.0 or later.
-* .NET 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`:
+* .NET Core 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`:
 
     ```csharp
     // This switch must be set before creating the GrpcChannel/HttpClient.
@@ -434,7 +434,7 @@ There are some additional requirements to call insecure gRPC services depending
     var client = new Greet.GreeterClient(channel);
     ```
 
-The `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch is only required for .NET 3.x. It does nothing in .NET 5 and isn't required.
+The `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch is only required for .NET Core 3.x. It does nothing in .NET 5 and isn't required.
 
 > [!IMPORTANT]
 > Insecure gRPC services must be hosted on a HTTP/2-only port. For more information, see [ASP.NET Core protocol negotiation](xref:grpc/aspnetcore#protocol-negotiation).
@@ -671,7 +671,7 @@ The .NET gRPC client can call insecure gRPC services by specifing `http` in the
 There are some additional requirements to call insecure gRPC services depending on the .NET version an app is using:
 
 * .NET 5 or later requires [Grpc.Net.Client](https://www.nuget.org/packages/Grpc.Net.Client) version 2.32.0 or later.
-* .NET 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`:
+* .NET Core 3.x requires additional configuration. The app must set the `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch to `true`:
 
     ```csharp
     // This switch must be set before creating the GrpcChannel/HttpClient.
@@ -683,7 +683,7 @@ There are some additional requirements to call insecure gRPC services depending
     var client = new Greet.GreeterClient(channel);
     ```
 
-The `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch is only required for .NET 3.x. It does nothing in .NET 5 and isn't required.
+The `System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport` switch is only required for .NET Core 3.x. It does nothing in .NET 5 and isn't required.
 
 > [!IMPORTANT]
 > Insecure gRPC services must be hosted on a HTTP/2-only port. For more information, see [ASP.NET Core protocol negotiation](xref:grpc/aspnetcore#protocol-negotiation).