.NET Core to .NET branding changes (dotnet#33694)

Contributes to dotnet#33680

Author: jkotas

README.md

@@ -3,10 +3,10 @@
 [![Build Status](https://dnceng.visualstudio.com/public/_apis/build/status/dotnet/runtime/runtime?branchName=master)](https://dnceng.visualstudio.com/public/_build/latest?definitionId=686&branchName=master)
 [![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/runtime)
 
-This repo contains the code to build the .NET Core runtime, libraries and shared host (`dotnet`) installers for
-all supported platforms, as well as the sources to .NET Core runtime and libraries.
+This repo contains the code to build the .NET runtime, libraries and shared host (`dotnet`) installers for
+all supported platforms, as well as the sources to .NET runtime and libraries.
 
-## What is .NET Core?
+## What is .NET?
 
 Official Starting Page: https://dotnet.microsoft.com/
 
@@ -33,11 +33,11 @@ Also see info about related [Microsoft .NET Core and ASP.NET Core Bug Bounty Pro
 
 ## Filing issues
 
-This repo should contain issues that are tied to the runtime, the class libraries and frameworks, the installation of the `dotnet` binary (sometimes known as the `muxer`) and installation of the .NET Core runtime and libraries.
+This repo should contain issues that are tied to the runtime, the class libraries and frameworks, the installation of the `dotnet` binary (sometimes known as the `muxer`) and installation of the .NET runtime and libraries.
 
 For other issues, please use the following repos:
 
-- For overall .NET Core SDK issues, file in the [dotnet/sdk](https://github.com/dotnet/sdk) repo
+- For overall .NET SDK issues, file in the [dotnet/sdk](https://github.com/dotnet/sdk) repo
 - For ASP.NET issues, file in the [dotnet/aspnetcore](https://github.com/dotnet/aspnetcore) repo.
 
 ## Useful Links
@@ -49,7 +49,7 @@ For other issues, please use the following repos:
 
 ## .NET Foundation
 
-.NET Core is a [.NET Foundation](https://www.dotnetfoundation.org/projects) project.
+.NET Runtime is a [.NET Foundation](https://www.dotnetfoundation.org/projects) project.
 
 There are many .NET related projects on GitHub.
 

THIRD-PARTY-NOTICES.TXT

@@ -1,5 +1,5 @@
-.NET Core uses third-party libraries or other resources that may be
-distributed under licenses different than the .NET Core software.
+.NET Runtime uses third-party libraries or other resources that may be
+distributed under licenses different than the .NET Runtime software.
 
 In the event that we accidentally failed to list a required notice, please
 bring it to our attention. Post an issue or email us:

docs/coding-guidelines/api-guidelines/nullability.md

@@ -1,10 +1,10 @@
 # Nullability annotations
 
-C# 8 provides an opt-in feature that allows for the compiler to  track reference type nullability in order to catch potential null dereferences.  We are adopting that feature across .NET Core's libraries, working up from the bottom of the stack.  We're doing this for three primary reasons, in order of importance:
+C# 8 provides an opt-in feature that allows for the compiler to  track reference type nullability in order to catch potential null dereferences.  We are adopting that feature across .NET's libraries, working up from the bottom of the stack.  We're doing this for three primary reasons, in order of importance:
 
-- **To annotate the .NET Core surface area with appropriate nullability annotations.**  While this could be done solely in the reference assemblies, we're doing it first in the implementation to help validate the selected annotations.
+- **To annotate the .NET surface area with appropriate nullability annotations.**  While this could be done solely in the reference assemblies, we're doing it first in the implementation to help validate the selected annotations.
 - **To help validate the nullability feature itself.**  With millions of lines of C# code, we have a very large and robust codebase with which to try out the feature and find areas in which it shines and areas in which we can improve it.  The work to annotate System.Private.CoreLib in .NET Core 3.0 helped to improve the feature as shipped in C# 8, and annotating the rest of the libraries will continue to be helpful in this regard.
-- **To find null-related bugs in .NET Core itself.** We expect to find relatively few meaningful bugs, due to how relatively well-tested the codebases are and how long they've been around.
+- **To find null-related bugs in .NET Runtime itself.** We expect to find relatively few meaningful bugs, due to how relatively well-tested the codebases are and how long they've been around.
 
 ## Breaking Change Guidance
 

docs/coding-guidelines/cross-platform-performance-and-eventing.md

@@ -252,7 +252,7 @@ Given the significant work required to bring all of this infrastructure up, this
 
 We’ll use the following scenarios when defining priorities:
 
-- P1: Performance analysis in support of bring-up of the .NET Core runtime and framework on Linux and OS X.
+- P1: Performance analysis in support of bring-up of the .NET runtime and framework on Linux and OS X.
 - P2: Performance analysis of ASP.NET running on .NET Core on Linux and OS X.
 
 To support these scenarios, we need the following capabilities:

docs/design/features/assemblyloadcontext.md

@@ -13,7 +13,7 @@ In .NET Core, we have exposed a [managed API surface](https://github.com/dotnet/
 ## Types of LoadContext
 ### Default LoadContext
 
-Every .NET Core app has a **LoadContext** instance created during .NET Core Runtime startup that we will refer to as the *Default LoadContext*. All application assemblies (including their transitive closure) are loaded within this **LoadContext** instance.
+Every .NET app has a **LoadContext** instance created during .NET Runtime startup that we will refer to as the *Default LoadContext*. All application assemblies (including their transitive closure) are loaded within this **LoadContext** instance.
 
 ### Custom LoadContext
 For scenarios that wish to have isolation between loaded assemblies, applications can create their own **LoadContext** instance by deriving from **System.Runtime.Loader.AssemblyLoadContext** type and loading the assemblies within that instance.
@@ -46,7 +46,7 @@ If the *Default LoadContext* fallback also did not resolve the load (or was not
 
 ## Constraints
 
-* **System.Private.CoreLib.dll** is only loaded once, and into the **Default LoadContext**, during the .NET Core Runtime startup as it is a logical extension of the same. It cannot be loaded into **Custom LoadContext**.
+* **System.Private.CoreLib.dll** is only loaded once, and into the **Default LoadContext**, during the .NET Runtime startup as it is a logical extension of the same. It cannot be loaded into **Custom LoadContext**.
 * Currently, custom **LoadContext** cannot be unloaded once created. This is a feature we are looking into for a future release.
 * If an attempt is made to load a [Ready-To-Run (R2R)](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/readytorun-overview.md) image from the same location in multiple load context's, then precompiled code can only be used from the first image that got loaded. The subsequent images will have their code JITted. This happens because subsequent loading binaries from the same location results in OS mapping them to the same memory as the previous one was mapped to and thus, could corrupt internal state information required for use precompiled code.
 

docs/design/features/host-components.md

@@ -30,7 +30,7 @@ The main reason to split the entry-point host and the `hostfxr` is to allow for
 ## Host Policy
 The host policy library implements all the policies to actually load the runtime, apply configuration, resolve all app's dependencies and calls the runtime to run the app or load the required component.
 
-The host policy library lives in the runtime folder and is versioned alongside it. Which version is used is specified by the app as it specifies which version of the .NET Core runtime to use (done directly or indirectly by referencing the `Microsoft.NETCore.App` framework, or carrying everything app-local).
+The host policy library lives in the runtime folder and is versioned alongside it. Which version is used is specified by the app as it specifies which version of the .NET runtime to use (done directly or indirectly by referencing the `Microsoft.NETCore.App` framework, or carrying everything app-local).
 
 Host policy library reads the `.deps.json` file of the app (and the `.deps.json` of all the referenced frameworks). It resolves all the assemblies specified in the `.deps.json` for the app and frameworks and creates a list of assembly paths (also called TPA). It does a similar thing for native dependencies as well.
 

docs/design/features/host-download-urls.md

@@ -9,14 +9,14 @@ The host uses different URLs for different scenarios. These different URLs are d
 
 This URL is part of the output of `dotnet --info`:
 ```console
-To install additional .NET Core runtimes or SDKs:
+To install additional .NET runtimes or SDKs:
   https://aka.ms/dotnet-download
 ```
 
 It's also part of the error when an SDK command is executed and there's no SDK installed:
 ```
-  It was not possible to find any installed .NET Core SDKs
-  Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
+  It was not possible to find any installed .NET SDKs
+  Did you mean to run .NET SDK commands? Install a .NET SDK from:
       https://aka.ms/dotnet-download
 ```
 

docs/design/features/host-error-codes.md

@@ -46,7 +46,7 @@ For example the `hostfxr` may look at its location and try to deduce the locatio
 
 * `LibHostInitFailure` (`0x8000808e`) - Initialization of the `hostpolicy` library failed. The `corehost_load` method takes a structure with lot of initialization parameters. If the version of this structure doesn't match the expected value, this error code is returned. This would in general mean incompatibility between the `hostfxr` and `hostpolicy`, which should really only happen if somehow a newer `hostpolicy` is used by older `hostfxr`. This typically means corrupted installation.
 
-* `LibHostSdkFindFailure` (`0x80008091`) - Failure to find the requested SDK. This happens in the `hostfxr` when an SDK (also called CLI) command is used with `dotnet`. In this case the hosting layer tries to find an installed .NET Core SDK to run the command on. The search is based on deduced install location and on the requested version from potential `global.json` file. If either no matching SDK version can be found, or that version exists, but it's missing the `dotnet.dll` file, this error code is returned.
+* `LibHostSdkFindFailure` (`0x80008091`) - Failure to find the requested SDK. This happens in the `hostfxr` when an SDK (also called CLI) command is used with `dotnet`. In this case the hosting layer tries to find an installed .NET SDK to run the command on. The search is based on deduced install location and on the requested version from potential `global.json` file. If either no matching SDK version can be found, or that version exists, but it's missing the `dotnet.dll` file, this error code is returned.
 
 * `LibHostInvalidArgs` (`0x80008092`) - Arguments to `hostpolicy` are invalid. This is used in three unrelated places in the `hostpolicy`, but in all cases it means the component calling `hostpolicy` did something wrong:
   * Command line arguments for the app - the failure would typically mean that wrong argument was passed or such. For example if the application main assembly is not specified on the command line. On its own this should not happen as `hostfxr` should have parsed and validated all command line arguments.

docs/design/features/localization-options.md

@@ -2,7 +2,7 @@
 
 The .NET Core host and runtime contain messages that can be displayed to both end-users and developers. Currently, all such messages are displayed in English.
 
-Other managed components built on top of .NET Core (e.g. SDK, WinForms, WPF) have already been localized, so a process already exists for handling translation and localizing assets, while the .NET Core runtime handles satellite assembly loading. The host and runtime are different in that they have messages that originate from native components and must continue to do so. While the runtime does contain some managed resources, this document focusses on localization of native resources.
+Other managed components built on top of .NET Runtime (e.g. SDK, WinForms, WPF) have already been localized, so a process already exists for handling translation and localizing assets, while the runtime handles satellite assembly loading. The host and runtime are different in that they have messages that originate from native components and must continue to do so. While the runtime does contain some managed resources, this document focusses on localization of native resources.
 
 The goal is to support:
 
@@ -63,7 +63,7 @@ Some infrastructure is in place for loading of resources on Windows, but is not
 
 Each host component will include English resource strings by default. If the resource for the appropriate locale could not be found, the host components can always fall back to English.
 
-`dotnet`, `hostfxr`, and `hostpolicy` will each have separate resources that will be installed by the .NET Core runtime. These components can be different versions, so their resources must be separate.
+`dotnet`, `hostfxr`, and `hostpolicy` will each have separate resources that will be installed by the .NET runtime. These components can be different versions, so their resources must be separate.
 
 `apphost` will have a single localized message. All languages will be included in the executable itself. The message will direct the user to a URL that will contain localized content.
 
@@ -109,7 +109,7 @@ Possible options for hosts:
   - If the hosts are newer than installed runtime, new messages would not be localized
   - Issues:
     - Compatibility concerns for resource IDs / format values
-    - Awkward split deployment since `*host` components are not normally part of the .NET Core runtime install
+    - Awkward split deployment since `*host` components are not normally part of the .NET runtime install
 
   - Options:
     1. Separate resource for each host
@@ -121,7 +121,7 @@ Possible options for hosts:
 
 `comhost`, `ijwhost`, `winrthost`, and `nethost` are designed to be consumed by a component that .NET Core does not own and intentionally do not show messages to the user. As such, they sit at a low priority for localization support.
 
-`apphost` is the end-user-facing host. The amount of logic and messaging in `apphost` is intentionally limited. The most important message it contains for an end-user is for the missing .NET Core runtime scenario, so it should not rely on resources installed via the .NET Core runtime. 
+`apphost` is the end-user-facing host. The amount of logic and messaging in `apphost` is intentionally limited. The most important message it contains for an end-user is for the missing .NET runtime scenario, so it should not rely on resources installed via the .NET runtime. 
 
 Embedding resources in the `apphost` would make for the most stream-lined user experience (particularly around deployment). Since the `apphost` is sensitive to size, the number of messages will be pared down to one generic localized message which directs the user to a URL.
 
@@ -167,10 +167,10 @@ It is also an option to create tooling directly integrated in the dotnet/runtime
 Each platform has its own standard way and file formats for handling localization. There are two main approaches that can be taken here:
   1. Convert a base format to platform-specific localization formats and use platform-specific localization support
       - Requires a tool/script to convert file formats at build time
-      - Uses platform support and standard localization methods that the .NET Core team will not need to maintain
+      - Uses platform support and standard localization methods that the .NET team will not need to maintain
       - Different method for handling localized resources on each platform
   2. Create a custom solution: storage format for string resources, tools for generation from the [translated assets (.xlf)](#translated-assets), and implementation for reading
-      - Requires design of completely custom support that will need to be maintained by the .NET Core team on all platforms
+      - Requires design of completely custom support that will need to be maintained by the .NET team on all platforms
       - Allows support for both string resources from file or memory
       - All platforms could use the same method for handling localized resources