Changing Windows_NT -> Windows for enabling TargetPlatformMoniker feature of the sdk for platform specific tfms. (#43651)

* eng change

* coreclr change

* libraries change

* tests change

* installer & mono change

* py files changed

* .md change

* .yml change

* remove redundant targetos property

* Windows_NT -> windows after ninja change

* fixing runtime build failure

Author: Anipik

docs/coding-guidelines/interop-guidelines.md

@@ -120,7 +120,7 @@ internal static partial class Interop // contents of Common\src\Interop\Windows\
 ```
 
 ### Build System
-When building dotnet/runtime, we use the "TargetOS" property to control what target platform we are building for. The valid values for this property are Windows_NT (which is the default value from MSBuild when running on Windows), Linux and OSX.
+When building dotnet/runtime, we use the "TargetOS" property to control what target platform we are building for. The valid values for this property are windows (which is the default value from MSBuild when running on Windows), Linux and OSX.
 
 #### Project Files
 Whenever possible, a single .csproj should be used per assembly, spanning all target platforms, e.g. System.Console.csproj includes conditional entries for when targeting Windows vs when targeting Linux. A property can be passed to dotnet build to control which flavor is built, e.g. `dotnet build /p:TargetOS=OSX System.Console.csproj`.

docs/coding-guidelines/project-guidelines.md

@@ -16,7 +16,7 @@ Below is a list of all the various options we pivot the project builds on:
 
 - **Target Frameworks:** .NETFramework, .NETStandard, .NETCoreApp
 - **Platform Runtimes:** .NETFramework (aka CLR/Desktop), CoreCLR, Mono
-- **OS:** Windows_NT, Linux, OSX, FreeBSD, AnyOS
+- **OS:** windows, Linux, OSX, FreeBSD, AnyOS
 - **Flavor:** Debug, Release
 
 ## Individual build properties
@@ -52,7 +52,7 @@ Pure netstandard configuration:
 All supported targets with unique windows/unix build for netcoreapp:
 ```
 <PropertyGroup>
-  <TargetFrameworks>$(NetCoreAppCurrent)-Windows_NT;$(NetCoreAppCurrent)-Unix;net461-Windows_NT</TargetFrameworks>
+  <TargetFrameworks>$(NetCoreAppCurrent)-windows;$(NetCoreAppCurrent)-Unix;net461-windows</TargetFrameworks>
 <PropertyGroup>
 ```
 
@@ -73,7 +73,7 @@ When building an individual project the `BuildTargetFramework` and `TargetOS` wi
 
 ## Supported full build settings
 - .NET Core latest on current OS (default) -> `$(NetCoreAppCurrent)-[RunningOS]`
-- .NET Framework latest -> `net48-Windows_NT`
+- .NET Framework latest -> `net48-windows`
 
 # Library project guidelines
 
@@ -100,7 +100,7 @@ Example:
 Example:
 ```
 <PropertyGroup>
-  <TargetFrameworks>netstandard2.0-Windows_NT;netstandard2.0-Unix</TargetFrameworks>
+  <TargetFrameworks>netstandard2.0-windows;netstandard2.0-Unix</TargetFrameworks>
 </PropertyGroup>
 <ItemGroup Condition="$(TargetFramework.StartsWith('netstandard2.0'))>...</ItemGroup>
 ```

docs/design/coreclr/jit/viewing-jit-dumps.md

@@ -63,8 +63,8 @@ The first thing to do is setup the .NET Core app we want to dump. Here are the s
 
     ```shell
     # Windows
-    robocopy /e <runtime-repo path>\artifacts\bin\coreclr\Windows_NT.<arch>.Release <app root>\bin\Release\net5.0\<rid>\publish > NUL
-    copy /y <runtime-repo path>\artifacts\bin\coreclr\Windows_NT.<arch>.Debug\clrjit.dll <app root>\bin\Release\net5.0\<rid>\publish > NUL
+    robocopy /e <runtime-repo path>\artifacts\bin\coreclr\windows.<arch>.Release <app root>\bin\Release\net5.0\<rid>\publish > NUL
+    copy /y <runtime-repo path>\artifacts\bin\coreclr\windows.<arch>.Debug\clrjit.dll <app root>\bin\Release\net5.0\<rid>\publish > NUL
 
     # Unix
     cp -rT <runtime-repo path>/artifacts/bin/coreclr/<OS>.<arch>.Release <app root>/bin/Release/net5.0/<rid>/publish

docs/pr-guide.md

@@ -74,7 +74,7 @@ If you have determined the failure is definitely not caused by changes in your P
 * Search for an [existing issue](https://github.com/dotnet/runtime/issues). Usually the test method name or (if a crash/hang) the test assembly name are good search parameters.
   * If there's an existing issue, add a comment with
     * a) the link to the build
-    * b) the affected configuration (ie `netcoreapp-Windows_NT-Release-x64-Windows.81.Amd64.Open`)
+    * b) the affected configuration (ie `net6.0-windows-Release-x64-Windows.81.Amd64.Open`)
     * c) all console output including the error message and stack trace from the Azure DevOps tab (This is necessary as retention policies are in place that recycle old builds.)
     * d) if there's a dump file (see Attachments tab in Azure DevOps) include that
     * If the issue is already closed, reopen it and update the labels to reflect the current failure state.

docs/project/garbage-collector-guidelines.md

@@ -37,17 +37,6 @@ This will run the stress framework for the default amount of time (15 hours) on
 ## Functional Testing ##
 A functional test run executes the same code as a stress run, but only runs for 30 minutes.
 
-It is recommended that you run at least some of the below PR-triggered CI jobs:
-
-```
-@dotnet_bot test Windows_NT Checked longgc
-@dotnet_bot test OSX10.12 Checked longgc
-@dotnet_bot test Ubuntu Checked longgc
-@dotnet_bot test Windows_NT Checked standalone_gc
-@dotnet_bot test OSX10.12 Checked standalone_gc
-@dotnet_bot test Ubuntu Checked standalone_gc
-```
-
 The "Long GC" tests are a series of GC tests whose running time is too long or memory usage is too high to run with
 the rest of the Priority 0 unit tests. The "Standalone GC" build mode builds and runs the GC in a semi-standalone manner
 (see https://github.com/dotnet/coreclr/projects/3).
@@ -56,7 +45,7 @@ You may also wish to run the GC Simulator tests. They may take up to 24 hours to
 due to poor interactions with the Linux OOM killer. However, they have proven to be quite useful in finding bugs in the past:
 
 ```
-@dotnet_bot test Windows_NT Release gcsimulator
+@dotnet_bot test windows Release gcsimulator
 @dotnet_bot test Ubuntu Release gcsimulator
 @dotnet_bot test OSX10.12 Release gcsimulator
 ```

docs/workflow/building/libraries/README.md

@@ -75,7 +75,7 @@ The libraries build has two logical components, the native build which produces
 The build settings (BuildTargetFramework, TargetOS, Configuration, Architecture) are generally defaulted based on where you are building (i.e. which OS or which architecture) but we have a few shortcuts for the individual properties that can be passed to the build scripts:
 
 - `-framework|-f` identifies the target framework for the build. Possible values include `net5.0` (currently the latest .NET version) or `net48` (the latest .NETFramework version). (msbuild property `BuildTargetFramework`)
-- `-os` identifies the OS for the build. It defaults to the OS you are running on but possible values include `Windows_NT`, `Unix`, `Linux`, or `OSX`. (msbuild property `TargetOS`)
+- `-os` identifies the OS for the build. It defaults to the OS you are running on but possible values include `windows`, `Unix`, `Linux`, or `OSX`. (msbuild property `TargetOS`)
 - `-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `Configuration`)
 - `-arch` identifies the architecture for the build. It defaults to `x64` but possible values include `x64`, `x86`, `arm`, or `arm64`. (msbuild property `TargetArchitecture`)
 

docs/workflow/building/libraries/freebsd-instructions.md

@@ -79,7 +79,7 @@ index 81b8c7b..bb26868 100644
 @@ -5,6 +5,7 @@
      <BuildArguments>$(Platform) $(Configuration) skiptests</BuildArguments>
      <BuildArguments Condition="'$(SkipDisablePgo)' != 'true'">$(BuildArguments) -nopgooptimize</BuildArguments>
-     <BuildArguments Condition="'$(TargetOS)' != 'Windows_NT'">$(BuildArguments) msbuildonunsupportedplatform</BuildArguments>
+     <BuildArguments Condition="'$(TargetOS)' != 'windows'">$(BuildArguments) msbuildonunsupportedplatform</BuildArguments>
 +    <BuildArguments Condition="'$(TargetOS)' == 'FreeBSD'">$(BuildArguments) -clang6.0</BuildArguments>
      <BuildArguments Condition="'$(UseSystemLibraries)' == 'true'">$(BuildArguments) cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE</BuildArguments>
      <BuildArguments Condition="$(Platform.Contains('arm'))">$(BuildArguments) skipnuget cross -skiprestore cmakeargs -DFEATURE_GDBJIT=TRUE</BuildArguments>

docs/workflow/debugging/coreclr/debugging.md

@@ -9,17 +9,17 @@ Debugging CoreCLR on Windows
 ============================
 
 1. Perform a build of the repo.
-2. Open solution \<reporoot\>\artifacts\obj\coreclr\Windows_NT.\<platform\>.\<configuration\>\CoreCLR.sln in Visual Studio. \<platform\> and \<configuration\> are based
+2. Open solution \<reporoot\>\artifacts\obj\coreclr\windows.\<platform\>.\<configuration\>\CoreCLR.sln in Visual Studio. \<platform\> and \<configuration\> are based
     on type of build you did. By default they are 'x64' and 'Debug'.
 3. Right-click the INSTALL project and choose ‘Set as StartUp Project’
 4. Bring up the properties page for the INSTALL project
 5. Select Configuration Properties->Debugging from the left side tree control
-6. Set Command=`$(SolutionDir)\..\..\..\bin\coreclr\Windows_NT.$(Platform).$(Configuration)\corerun.exe`
+6. Set Command=`$(SolutionDir)\..\..\..\bin\coreclr\windows.$(Platform).$(Configuration)\corerun.exe`
     1. This points to the folder where the built runtime binaries are present.
 7. Set Command Arguments=`<managed app you wish to run>` (e.g. HelloWorld.dll)
-8. Set Working Directory=`$(SolutionDir)\..\..\..\bin\coreclr\Windows_NT.$(Platform).$(Configuration)`
+8. Set Working Directory=`$(SolutionDir)\..\..\..\bin\coreclr\windows.$(Platform).$(Configuration)`
     1. This points to the folder containing CoreCLR binaries.
-9. Set Environment=`CORE_LIBRARIES=$(SolutionDir)\..\..\..\bin\runtime\<current tfm>-Windows_NT-$(Configuration)-$(Platform)`,
+9. Set Environment=`CORE_LIBRARIES=$(SolutionDir)\..\..\..\bin\runtime\<current tfm>-windows-$(Configuration)-$(Platform)`,
     where '\<current tfm\>' is the target framework of current branch, for example `netcoreapp3.1` `net5.0`.
     1. This points to the folder containing core libraries except `System.Private.CoreLib`.
     2. This step can be skipped if you are debugging CLR tests that references only `System.Private.CoreLib`.

docs/workflow/debugging/libraries/debugging-packages.md

@@ -101,5 +101,5 @@ dotnet build System.Net.ServicePoint.Tests.csproj -f netcoreapp2.0 /t:test /p:Ou
 Will run the test using the following pivot values:
 * Architecture: AnyCPU
 * Flavor: Debug
-* OS: Windows_NT
+* OS: windows
 * Target: netstandard2.0

docs/workflow/debugging/libraries/windows-instructions.md

@@ -33,15 +33,15 @@ To run a single test from command line:
 
 * Locate the test binary folder based on the CSPROJ name.
 
-For example: `src\System.Net.Sockets\tests\Functional\System.Net.Sockets.Tests.csproj` will build and output binaries at  `bin\tests\Windows_NT.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0`.
+For example: `src\System.Net.Sockets\tests\Functional\System.Net.Sockets.Tests.csproj` will build and output binaries at  `bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0`.
 
 * Execute the test
 
 Assuming that your repo is at `C:\corefx`:
 
 ```
-cd C:\corefx\bin\tests\Windows_NT.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0
-C:\corefx\bin\tests\Windows_NT.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0\CoreRun.exe xunit.console.dll System.Net.Sockets.Tests.dll -xml testResults.xml -notrait category=nonwindowstests -notrait category=OuterLoop -notrait category=failing
+cd C:\corefx\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0
+C:\corefx\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0\CoreRun.exe xunit.console.dll System.Net.Sockets.Tests.dll -xml testResults.xml -notrait category=nonwindowstests -notrait category=OuterLoop -notrait category=failing
 ```
 
 * If the test crashes or encounters a `Debugger.Launch()` method call, WinDBG will automatically start and attach to the `CoreRun.exe` process