Changing Windows_NT -> Windows for enabling TargetPlatformMoniker fea…

…ture of the sdk for platform specific tfms. (dotnet#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

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

docs/workflow/editing-and-debugging.md

@@ -20,7 +20,7 @@ what are in the repository. In particular
 
    * `src\coreclr\src\System.Private.CoreLib\System.Private.CorLib.sln` - This solution is for all managed (C#) code that is defined
    in the runtime itself.   This is all class library support of one form or another.
-   * `artifacts\obj\coreclr\Windows_NT.<Arch>.<BuildType>\CoreCLR.sln` - this solution contains most native (C++) projects
+   * `artifacts\obj\coreclr\windows.<Arch>.<BuildType>\CoreCLR.sln` - this solution contains most native (C++) projects
    associated with the repository, including
      * `coreclr` - This is the main runtime DLL (the GC, class loader, interop are all here)
      * `corjit` - This is the Just In Time (JIT) compiler that compiles .NET Intermediate language to native code.

docs/workflow/testing/coreclr/running-aspnet-benchmarks-with-crossgen2.md

@@ -185,7 +185,7 @@ using the following command.
 On Windows:
 
 ```powershell
-CoreRun.exe \runtime\artifacts\bin\coreclr\Windows_NT.x64.Release\crossgen2\crossgen2.dll
+CoreRun.exe \runtime\artifacts\bin\coreclr\windows.x64.Release\crossgen2\crossgen2.dll
 --Os --composite -o \path\to\results\composite\TotalComposite.dll \path\to\results\application\*.dll
 ```
 

docs/workflow/testing/coreclr/windows-test-instructions.md

@@ -61,13 +61,13 @@ In order to run all of the tests using your checked build:
 > src\tests\run.cmd checked
 ```
 
-This will generate a report named `TestRun_<arch>_<flavor>.html` (e.g. `TestRun_Windows_NT_x64_Checked.html`) in the subdirectory `<repo_root>\artifacts\log`. Any tests that failed will be listed in `TestRunResults_Windows_NT_x64_Checked.err`.
+This will generate a report named `TestRun_<arch>_<flavor>.html` (e.g. `TestRun_windows_x64_Checked.html`) in the subdirectory `<repo_root>\artifacts\log`. Any tests that failed will be listed in `TestRunResults_windows_x64_Checked.err`.
 
 ### Investigating Test Failures
 
 Upon completing a test run, you may find one or more tests have failed.
 
-The output of the test will be available in `Test` reports directory, but by default the directory will be something like `<repo_root>\artifacts\tests\coreclr\Windows_NT.x64.Checked\Reports\Exceptions\Finalization`.
+The output of the test will be available in `Test` reports directory, but by default the directory will be something like `<repo_root>\artifacts\tests\coreclr\windows.x64.Checked\Reports\Exceptions\Finalization`.
 
 There are 2 files of interest:
 
@@ -79,16 +79,16 @@ There are 2 files of interest:
 If you wish to re-run a failed test, follow the following steps:
 
 1) Set an environment variable, `CORE_ROOT`, pointing to the path to product binaries that was passed to run.cmd.
-For example using a checked build the location would be: `<repo_root>\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root`
+For example using a checked build the location would be: `<repo_root>\artifacts\tests\coreclr\windows.x64.Checked\Tests\Core_Root`
 
-2) Run the failed test, the command to which is also present in the test report for a failed test. It will be something like `<repo_root>\artifacts\tests\coreclr\Windows_NT.x64.Checked\Exceptions\Finalization\Finalizer.cmd`.
+2) Run the failed test, the command to which is also present in the test report for a failed test. It will be something like `<repo_root>\artifacts\tests\coreclr\windows.x64.Checked\Exceptions\Finalization\Finalizer.cmd`.
 
 If you wish to run the test under a debugger (e.g. [WinDbg](http://msdn.microsoft.com/library/windows/hardware/ff551063(v=vs.85).aspx)), append `-debug <debuggerFullPath>` to the test command. For example:
 
 ```
-> artifacts\tests\coreclr\Windows_NT.x64.Checked\Exceptions\Finalization\Finalizer.cmd -debug <debuggerFullPath>
+> artifacts\tests\coreclr\windows.x64.Checked\Exceptions\Finalization\Finalizer.cmd -debug <debuggerFullPath>
 ```
 
 ### Modifying a test
 
-If test changes are needed, make the change, and build the test project. This will binplace the binaries in the test binaries folder (e.g. `<repo_root>\artifacts\tests\coreclr\Windows_NT.x64.Checked\Exceptions\Finalization`). Then re-run the test following the instructions above.
+If test changes are needed, make the change, and build the test project. This will binplace the binaries in the test binaries folder (e.g. `<repo_root>\artifacts\tests\coreclr\windows.x64.Checked\Exceptions\Finalization`). Then re-run the test following the instructions above.

docs/workflow/testing/libraries/filtering-tests.md

@@ -148,7 +148,7 @@ _**A few common examples with the above attributes:**_
 
 - Run all tests acceptable on Windows that are not failing:
 ```cmd
-dotnet build <csproj_file> /t:Test /p:TargetOS=Windows_NT
+dotnet build <csproj_file> /t:Test /p:TargetOS=windows
 ```
 - Run all outer loop tests acceptable on OS X that are currently associated with active issues:
 ```sh

docs/workflow/testing/using-corerun.md

@@ -31,7 +31,7 @@ Consider that you already have a .NET application DLL called HelloWorld.dll and
 
 If you execute the following
 ```bat
-    set PATH=%PATH%;%CoreCLR%\artifacts\tests\coreclr\Windows_NT.x64.Debug\Tests\Core_Root\
+    set PATH=%PATH%;%CoreCLR%\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root\
     set CORE_LIBRARIES=%ProgramFiles%\dotnet\shared\Microsoft.NETCore.App\1.0.0
 
 
@@ -73,11 +73,11 @@ variable CORE_ROOT to this directory
 (running src\tests\build from the repository base) and running 'src\tests\run') you can do the following
 
 ```bat
-    set PATH=%PATH%;%CoreCLR%\artifacts\Product\Windows_NT.x64.Debug
-    set CORE_ROOT=%CoreCLR%\artifacts\tests\coreclr\Windows_NT.x64.Debug\Tests\Core_Root
+    set PATH=%PATH%;%CoreCLR%\artifacts\Product\windows.x64.Debug
+    set CORE_ROOT=%CoreCLR%\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root
 ```
 sets you up so that corerun can run any of the test.   For example
 ```bat
-    corerun artifacts\tests\coreclr\Windows_NT.X64.Debug\GC\Features\Finalizer\finalizeio\finalizeio\finalizeio.exe
+    corerun artifacts\tests\coreclr\windows.X64.Debug\GC\Features\Finalizer\finalizeio\finalizeio\finalizeio.exe
 ```
 runs the finalizerio test.

docs/workflow/using-dotnet-cli.md

@@ -179,7 +179,7 @@ which should make things work (but is fragile, confirm file timestamps that you
 Get this by simply listing the name of the `runtime.win-x64.Microsoft.NETCore.Runtime.CoreCLR` you built.
 
 ```bat
-    dir artifacts\bin\coreclr\Product\Windows_NT.x64.Release\.nuget\pkg
+    dir artifacts\bin\coreclr\Product\windows.x64.Release\.nuget\pkg
 ```
 
 and you will get name of the which looks something like this

eng/Configurations.props

@@ -58,7 +58,7 @@
     <TargetOS Condition="'$(TargetOS)' == '' and $([MSBuild]::IsOSPlatform('ILLUMOS'))">illumos</TargetOS>
     <TargetOS Condition="'$(TargetOS)' == '' and $([MSBuild]::IsOSPlatform('SOLARIS'))">Solaris</TargetOS>
     <TargetOS Condition="'$(TargetOS)' == '' and $([MSBuild]::IsOSUnixLike())">Linux</TargetOS>
-    <TargetOS Condition="'$(TargetOS)' == '' and $([MSBuild]::IsOSPlatform('WINDOWS'))">Windows_NT</TargetOS>
+    <TargetOS Condition="'$(TargetOS)' == '' and $([MSBuild]::IsOSPlatform('WINDOWS'))">windows</TargetOS>
     <CoreCLRTargetOS Condition="'$(CoreCLRTargetOS)' == ''">$(TargetOS)</CoreCLRTargetOS>
     <MonoTargetOS Condition="'$(MonoTargetOS)' == ''">$(TargetOS)</MonoTargetOS>
     <LibrariesTargetOS Condition="'$(LibrariesTargetOS)' == ''">$(TargetOS)</LibrariesTargetOS>

eng/Subsets.props

@@ -149,7 +149,7 @@
     <ProjectToBuild Include="$(CoreClrProjectRoot)src\System.Private.CoreLib\System.Private.CoreLib.csproj" Category="clr" />
   </ItemGroup>
 
-  <ItemGroup Condition="'$(TargetOS)' == 'Windows_NT' and ($(_subset.Contains('+clr.dactools+')) or $(_subset.Contains('+clr.runtime+')))">
+  <ItemGroup Condition="'$(TargetOS)' == 'windows' and ($(_subset.Contains('+clr.dactools+')) or $(_subset.Contains('+clr.runtime+')))">
     <ProjectToBuild Include="$(CoreClrProjectRoot)src\ToolBox\SOS\DacTableGen\DacTableGen.csproj;
                              $(CoreClrProjectRoot)src\ToolBox\SOS\DIALib\DIALib.ilproj"
                     Category="clr"/>