Fix typo (#23300)

.Net -> .NET

10 files changed, 16 insertions, 16 deletions

diff --git a/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md b/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md
index 21678cad4e..7af4739d8b 100644
--- a/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md
+++ b/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md
@@ -45,7 +45,7 @@ And then there's the worst of both worlds: when you need to rewrite IL to call i
 
 **Q: Has anyone else tried making an IL-rewriting profiler?**
 
-Sure. If you want to learn from other people's experiences, read through the [Building Development and Diagnostic Tools for .Net Forum](http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=868&SiteID=1). Here are some interesting threads:
+Sure. If you want to learn from other people's experiences, read through the [Building Development and Diagnostic Tools for .NET Forum](http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=868&SiteID=1). Here are some interesting threads:
 
 [http://social.msdn.microsoft.com/Forums/en-NZ/netfxtoolsdev/thread/5f30596b-e7b7-4b1f-b8e1-8172aa8dde31](http://social.msdn.microsoft.com/Forums/en-NZ/netfxtoolsdev/thread/5f30596b-e7b7-4b1f-b8e1-8172aa8dde31)  
 [http://social.msdn.microsoft.com/Forums/en-GB/netfxtoolsdev/thread/c352266f-ded3-4ee2-b2f9-fbeb41a70c27](http://social.msdn.microsoft.com/Forums/en-GB/netfxtoolsdev/thread/c352266f-ded3-4ee2-b2f9-fbeb41a70c27)
diff --git a/Documentation/building/cross-building.md b/Documentation/building/cross-building.md
index 8554f731a5..9baca18377 100644
--- a/Documentation/building/cross-building.md
+++ b/Documentation/building/cross-building.md
@@ -139,7 +139,7 @@ The output is at bin/Product/<BuildOS>.arm.Debug/System.Private.CoreLib.dll.
 ```
     lgs@ubuntu ~/git/coreclr/ $ file ./bin/Product/Linux.arm.Debug/System.Private.CoreLib.dll 
     ./bin/Product/Linux.arm.Debug/System.Private.CoreLib.dll: PE32 executable (DLL) 
-    (console) ARMv7 Thumb Mono/.Net assembly, for MS Windows
+    (console) ARMv7 Thumb Mono/.NET assembly, for MS Windows
 ```
 
 Building coreclr for Linux ARM Emulator
diff --git a/Documentation/building/debugging-instructions.md b/Documentation/building/debugging-instructions.md
index a97433300a..86468b6bbf 100644
--- a/Documentation/building/debugging-instructions.md
+++ b/Documentation/building/debugging-instructions.md
@@ -208,4 +208,4 @@ Using Visual Studio
 - For managed debugging, there are some settings in Debug->Options, Debugging->General that might be useful:
   - Uncheck 'Just My Code'. This will allow you debug into the framework libraries.
   - Check 'Enable .NET Framework Source Stepping.' This will configure the debugger to download symbols and source automatically for runtime framework binaries. If you built the framework yourself this may be irrelevant because you already have all the source on your machine but it doesn't hurt.
-  - Check 'Suppress JIT optimzation on module load'. This tells the debugger to tell the .NET runtime JIT to generate debuggable code even for modules that may not have been compiled in a 'Debug' configuration by the C# compiler. This code is slower, but it provides much higher fidelity breakpoints, stepping, and local variable access. It is the same difference you see when debugging .Net apps in the 'Debug' project configuration vs. the 'Release' project configuration. 
+  - Check 'Suppress JIT optimzation on module load'. This tells the debugger to tell the .NET runtime JIT to generate debuggable code even for modules that may not have been compiled in a 'Debug' configuration by the C# compiler. This code is slower, but it provides much higher fidelity breakpoints, stepping, and local variable access. It is the same difference you see when debugging .NET apps in the 'Debug' project configuration vs. the 'Release' project configuration. 
diff --git a/Documentation/building/windows-instructions.md b/Documentation/building/windows-instructions.md
index b526148895..afb216fccb 100644
--- a/Documentation/building/windows-instructions.md
+++ b/Documentation/building/windows-instructions.md
@@ -88,7 +88,7 @@ Powershell version must be 3.0 or higher. This should be the case for Windows 8
 ## DotNet Core SDK
 While not strictly needed to build or test the .NET Core repository, having the .NET Core SDK installed lets you use the dotnet.exe command to run .NET Core applications in the 'normal' way.   We use this in the 
 [Using Your Build](../workflow/UsingYourBuild.md) instructions.  Visual Studio should have
-installed the .NET Core SDK, but in case it did not you can get it from the [Installing the .Net Core SDK](https://www.microsoft.com/net/core) page.  
+installed the .NET Core SDK, but in case it did not you can get it from the [Installing the .NET Core SDK](https://www.microsoft.com/net/core) page.  
 
 ## Adding to the default PATH variable
 
diff --git a/Documentation/design-docs/assemblyloadcontext.md b/Documentation/design-docs/assemblyloadcontext.md
index cf6c92cda1..c9575c4be6 100644
--- a/Documentation/design-docs/assemblyloadcontext.md
+++ b/Documentation/design-docs/assemblyloadcontext.md
@@ -18,7 +18,7 @@ Every .NET Core app has a **LoadContext** instance created during .NET Core Runt
 ### 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.
 
-Multiple assemblies with the same simple name cannot be loaded into a single load context (*Default* or *Custom*). Also, .Net Core ignores strong name token for assembly binding process.
+Multiple assemblies with the same simple name cannot be loaded into a single load context (*Default* or *Custom*). Also, .NET Core ignores strong name token for assembly binding process.
 
 ## How Load is attempted
 
diff --git a/Documentation/design-docs/code-versioning-profiler-breaking-changes.md b/Documentation/design-docs/code-versioning-profiler-breaking-changes.md
index 538693101d..1889e1c4c9 100644
--- a/Documentation/design-docs/code-versioning-profiler-breaking-changes.md
+++ b/Documentation/design-docs/code-versioning-profiler-breaking-changes.md
@@ -1,6 +1,6 @@
 # Code Versioning Profiler Breaking Changes #
 
-The runtime changes done as part of the code versioning feature will cause some (hopefully minor) breaking changes to be visible via the profiler API. My goal is to advertise these coming changes and solicit feedback about what will be easiest for profiler writers to absorb. Currently this feature is only under development in the .Net Core version of the runtime. If you solely support a profiler on full .Net Framework this change doesn't affect you.
+The runtime changes done as part of the code versioning feature will cause some (hopefully minor) breaking changes to be visible via the profiler API. My goal is to advertise these coming changes and solicit feedback about what will be easiest for profiler writers to absorb. Currently this feature is only under development in the .NET Core version of the runtime. If you solely support a profiler on full .NET Framework this change doesn't affect you.
 
 ## Underlying issue ##
 
diff --git a/Documentation/design-docs/code-versioning.md b/Documentation/design-docs/code-versioning.md
index 928f4a5512..4a4594bc5c 100644
--- a/Documentation/design-docs/code-versioning.md
+++ b/Documentation/design-docs/code-versioning.md
@@ -308,7 +308,7 @@ Generics can cause methods in domain-neutral modules to refer to types in domain
 CoreCLR is largely moving away from multiple AppDomains but I left the domain distinctions in place for a few reasons:
 
 1. Pragmatically the feature is a partial refactoring of ReJitManager and this is what ReJitManager did. Diverging from ReJitManager's design incurs extra time and risk of new issues.
-2. Maybe someday we will want to migrate similar functionality back to the desktop .Net SKU. Desktop supports multiple AppDomains so per-AppDomain handling would be required in that context.
+2. Maybe someday we will want to migrate similar functionality back to the desktop .NET SKU. Desktop supports multiple AppDomains so per-AppDomain handling would be required in that context.
 
 AppDomain unloading however has not been handled. If CoreCLR supports proper AppDomain unload at some point or the code moves back to desktop runtime we will need to handle this gap.
 
@@ -355,7 +355,7 @@ All other information such as Edit and Continue IL modifications, or a profiler
 
 - **Explicit** - These are configuration options that are encoded directly into the version tree data structures so they can be trivially read back at any time. Profiler ReJIT, generic instantiation, and tiered compilation settings are all explicit.
 - **Ambient** - These are configuration values that are immutable once set and apply to all code versions of the same method. This can be treated the same as if the build stage gave an explicit configuration result for each generated code version, but the policy in that build stage always returns the same answer. Then as a memory footprint optimization rather than save N copies of the same answer in N different versions, the runtime stores the answer once and knows that it applies to all code versions. For example the debugger can set a debuggable codegen flag that causes all methods in a module to jit differently. The runtime stores that flag in the module for efficiency, but we can map it back to the code version concept as if every code version had that flag in it and it happens to be the same for all versions.
-- **Unrecorded** - The final case are configuration options that do change per code version, but they aren't recorded in the NativeCodeVersion/ILCodeVersion data structures. Logically this configuration is part of the code version regardless of the runtime's ability trivially access it/compute it on demand. For example a .Net profiler can control whether a particular jitting of a method has Profiler Enter/Leave/Tailcall probes in it based on its response to the FunctionIDMapper2 callback during JIT code generation. If there was already a version of this function generated without ELT and the profiler wanted a new version that does have ELT then the profiler needs to create a new code version. The only technique it has available to create new code versions is to use ReJIT, but ELT isn't part of explicit configuration that ReJIT collects for the new code version. Instead the profiler records in its own data structures that the new ReJIT version should have a certain ELT configuration setting. Whenever code jits that corresponds to this version the runtime will query the profiler and then the profiler will respond with the appropriate ELT setting. In this way the ELT has logically become part of the profiler ReJIT stage configuration even though the runtime has no explicit record of it. Generalizing from this example, the runtime expects that all unrecorded code version configuration can be treated as a hidden portion of the configuration that is supplied by one of the explicitly configured build stages.
+- **Unrecorded** - The final case are configuration options that do change per code version, but they aren't recorded in the NativeCodeVersion/ILCodeVersion data structures. Logically this configuration is part of the code version regardless of the runtime's ability trivially access it/compute it on demand. For example a .NET profiler can control whether a particular jitting of a method has Profiler Enter/Leave/Tailcall probes in it based on its response to the FunctionIDMapper2 callback during JIT code generation. If there was already a version of this function generated without ELT and the profiler wanted a new version that does have ELT then the profiler needs to create a new code version. The only technique it has available to create new code versions is to use ReJIT, but ELT isn't part of explicit configuration that ReJIT collects for the new code version. Instead the profiler records in its own data structures that the new ReJIT version should have a certain ELT configuration setting. Whenever code jits that corresponds to this version the runtime will query the profiler and then the profiler will respond with the appropriate ELT setting. In this way the ELT has logically become part of the profiler ReJIT stage configuration even though the runtime has no explicit record of it. Generalizing from this example, the runtime expects that all unrecorded code version configuration can be treated as a hidden portion of the configuration that is supplied by one of the explicitly configured build stages.
 
 The runtime's current classification is:
 
diff --git a/Documentation/design-docs/inlining-plans.md b/Documentation/design-docs/inlining-plans.md
index 2279c16e37..79116092e9 100644
--- a/Documentation/design-docs/inlining-plans.md
+++ b/Documentation/design-docs/inlining-plans.md
@@ -31,12 +31,12 @@ overhead. It is anticipated that this work will encompass Machinery,
 Ability, and Profitability.
 
 LLILC does no inlining today. Since we aspire to have LLILC be a
-high-performance .Net code generator, we need to enable inlining in
+high-performance .NET code generator, we need to enable inlining in
 LLILC. LLILC can likely leverage much of LLVM's built-in inlining
 Machinery and Ability, but will need new code for Legality and
 Profitability.
 
-We envision various scenarios for .Net Code generation that impact
+We envision various scenarios for .NET Code generation that impact
 inlining: a first-tier JIT compiler, a higher-tier JIT compiler, a
 fast AOT compiler, and an optimizing AOT compiler. Each scenario calls
 for inlining, but the tradeoffs are different. For a given scenario,
@@ -221,7 +221,7 @@ xml or json markup):
 ```
 
 where `[o]` is a successful inline, `[x]` a failed inline, and
-indentation shows the inlining tree. For .Net compilation we'll need
+indentation shows the inlining tree. For .NET compilation we'll need
 some kind of persistent ID for methods, which may not be all that easy
 to come by. 
 
diff --git a/Documentation/design-docs/tiered-compilation.md b/Documentation/design-docs/tiered-compilation.md
index fbea857e50..70bb014338 100644
--- a/Documentation/design-docs/tiered-compilation.md
+++ b/Documentation/design-docs/tiered-compilation.md
@@ -40,11 +40,11 @@ Design
 
 ## Historical context ##
 
-Tiered Compilation was prototyped in 2016, introduced into the runtime code in 2017, and offered as an opt-in Preview feature in .Net Core 2.1 RTM in 2018. This design doc was written after the fact. We had been trying to mitigate runtime startup and performance problems for nearly 20 years with various forms of pre-compilation (NGEN, ReadyToRun, MulticoreJit) but this was the first serious foray into using compilation tiers to achieve similar goals. The IL interpreter appears similar but as best I understand it was not primarily targeted at performance, but rather at portability into environments that did not allow jitting. Although the idea of tiered compilation had come up repeatedly in the past it had never gained the degree of consensus/acceptance/momentum necessary to move forward relative to other performance investments.
+Tiered Compilation was prototyped in 2016, introduced into the runtime code in 2017, and offered as an opt-in Preview feature in .NET Core 2.1 RTM in 2018. This design doc was written after the fact. We had been trying to mitigate runtime startup and performance problems for nearly 20 years with various forms of pre-compilation (NGEN, ReadyToRun, MulticoreJit) but this was the first serious foray into using compilation tiers to achieve similar goals. The IL interpreter appears similar but as best I understand it was not primarily targeted at performance, but rather at portability into environments that did not allow jitting. Although the idea of tiered compilation had come up repeatedly in the past it had never gained the degree of consensus/acceptance/momentum necessary to move forward relative to other performance investments.
 
 ## Goals ##
 
-1. Improve the steady state and startup performance of typical .Net Core workloads while minimizing regressions.
+1. Improve the steady state and startup performance of typical .NET Core workloads while minimizing regressions.
 2. Compliment existing precompilation techniques so that developers can leverage the best of both options.
 
 
diff --git a/Documentation/project-docs/jit-testing.md b/Documentation/project-docs/jit-testing.md
index bebcf2106e..a4a560b577 100644
--- a/Documentation/project-docs/jit-testing.md
+++ b/Documentation/project-docs/jit-testing.md
@@ -25,7 +25,7 @@ all OS platforms.
 TBD).
 5. Tests in CI can be run on private changes (currently tied to PRs; this may
 be sufficient).
-6. Test strategy harmonious with other .Net repo test strategies.
+6. Test strategy harmonious with other .NET repo test strategies.
 7. Test harness behaves reasonably on test failure. Easy to get at repro steps 
 for subsequent debugging.
 8. Tests must allow fine-grained inspection of JIT outputs, for instance
@@ -58,7 +58,7 @@ formatting).
 2. Some have deep desktop CLR dependence (testing a desktop CLR feature that
 is not present in CoreCLR).
 3. Some require tools not yet available in CoreCLR (ilasm in particular).
-4. Some test windows features and won’t be relevant to other OS platforms.
+4. Some test windows features and won't be relevant to other OS platforms.
 5. Some tests may not be able to be freely redistributed.
 
 We have done an internal inventory and identified roughly 1000 tests that
@@ -68,7 +68,7 @@ moving these.
 ### Test script capabilities
 
 We need to ensure that the CoreCLR repo contains a suitably
-hookable test script. Core testing is driven by xunit but there’s typically a
+hookable test script. Core testing is driven by xunit but there's typically a
 wrapper around this (runtest.cmd today) to facilitate test execution. 
 
 The proposal is to implement platform-neutral variant of runtest.cmd that