Remove UAP target (dotnet/corefx#41759)

* Remove Uap target

* Remove RemoteInvokeForUap wrapper calls entirely

* Harvest S.D.SqlClient on UWP

* Disable UWP PInvoke analyzer

* Enable WindowsRuntime* tests on netcoreapp

Commit migrated from dotnet/corefx@3b6ec2b

docs/libraries/coding-guidelines/adding-api-guidelines.md

@@ -49,7 +49,7 @@ the implementation without compat concerns in future releases.
 
 **Update pkg**
  - If changing the target framework
-    - Update `SupportedFramework` metadata on the ref ProjectReference to declare the set of concrete platforms you expect your library to support. (see [Specific platform mappings](https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#nuget)). Generally will be a combination of netcoreapp2.x, netfx46x, uap10.x, and/or `$(AllXamarinFrameworks)`.
+    - Update `SupportedFramework` metadata on the ref ProjectReference to declare the set of concrete platforms you expect your library to support. (see [Specific platform mappings](https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#nuget)). Generally will be a combination of netcoreapp2.x, netfx46x, and/or `$(AllXamarinFrameworks)`.
   - If assembly or package version is updated the package index needs to be updated by running
     `dotnet msbuild <Library>/pkg/<Library>.pkgproj /t:UpdatePackageIndex`
 

docs/libraries/coding-guidelines/netstandard20-corefx-infra.md

@@ -78,19 +78,5 @@ Provides compatibility between NETCore.App and libraries built against NETStanda
 ### End goal
 
 - CoreFx does not build any reference assemblies for NETStandard.
-- For every library in NETStandard.Library, the only configurations in CoreFx are framework-specific.  EG: NETCoreApp1.2, UAP10.1
+- For every library in NETStandard.Library, the only configurations in CoreFx are framework-specific.  EG: netcoreapp3.0, net472
 - For every library in NETCore.App but not in NETStandard.Library there must be a framework-specific configuration for NETCoreApp1.2.  Other configurations may exist to ship in a package, but those will not be built by folks building just NETCore.App.
-
-### Getting there (WIP)
-
-Folks still consume our current packages so we need to keep building those until we transition.
-
-1. Create a new NETCore.App package: Microsoft.Private.CoreFx.NETCore.App.  This will be an identity package with every ref that targets NETCore.App and runtime-specific packages that have all runtime impl's that apply to NETCore.App.
-2. Filter the content of Microsoft.Private.CoreFx.NETCore.App to just the things that are part of NETCore, and their closure.
-3. Transition tests to use Microsoft.Private.CoreFx.NETCore.App.
-4. Delete packages for things that are only part of Microsoft.Private.CoreFx.NETCore.App and don't ship independently.
-  - Delete configurations for libraries that are no longer used
-  - As packages are deleted we'll need to opt-in to Microsoft.Private.CoreFx.NETCore.App in some way.
-    - proposal:
-      - each CSProj is evaluated for layout path in the context of all of its build configurations.
-      - We'll determine applicability similar to how we do for pkgprojs to identify which config to binplace.

docs/libraries/coding-guidelines/project-guidelines.md

@@ -4,19 +4,17 @@ once before you can iterate and work on a given library project.
 
 ## Behind the scenes with build.cmd/sh
 
-- Setup tools (currently done in init-tools but will later be a boot-strap script in run.cmd/sh)
+- Setup tools (currently done in restore in build.cmd/sh)
 - Restore external dependencies
  - CoreCLR - Copy to `bin\runtime\$(BuildConfiguration)`
  - Netstandard Library - Copy to `bin\ref\netstandard`
- - UAP - Copy to `bin\runtime\$(BuildConfiguration)`
  - NetFx targeting pack - Copy to `bin\ref\netfx`
 - Build targeting pack
  - Build src\ref.builds which builds all references assembly projects. For reference assembly project information see [ref](#ref)
 - Build product
  - Build src\src.builds which builds all the source library projects. For source library project information see [src](#src).
 - Sign product
  - Build src\sign.proj
-//**CONSIDER**: We should make this as part of the src.builds file instead of a separate project file.
 
 ## Behind the scenes with build-test.cmd/sh
 - build-test.cmd cannot be ran successfully until build.cmd has been ran at least once for a `BuildConfiguration`.
@@ -30,7 +28,7 @@ once before you can iterate and work on a given library project.
 # Build Pivots
 Below is a list of all the various options we pivot the project builds on:
 
-- **Target Frameworks:** NetFx (aka Desktop), netstandard (aka dotnet/Portable), NETCoreApp (aka .NET Core), UAP (aka UWP/Store/netcore50)
+- **Target Frameworks:** NetFx (aka Desktop), netstandard (aka dotnet/Portable), NETCoreApp (aka .NET Core)
 - **Platform Runtimes:** NetFx (aka CLR/Desktop), CoreCLR, Mono
 - **OS:** Windows_NT, Linux, OSX, FreeBSD, AnyOS
 - **Flavor:** Debug, Release
@@ -39,7 +37,7 @@ Below is a list of all the various options we pivot the project builds on:
 ## Individual build properties
 The following are the properties associated with each build pivot
 
-- `$(TargetGroup) -> netstandard | netcoreapp | netfx | uap`
+- `$(TargetGroup) -> netstandard | netcoreapp | netfx`
 //**CONSIDER**: naming netcoreappcorert something shorter maybe just corert.
 - `$(OSGroup) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
 - `$(ConfigurationGroup) -> Release | [defaults to Debug when empty]`
@@ -82,7 +80,6 @@ All supported targets with unique windows/unix build for netcoreapp:
     netcoreapp-Windows_NT;
     netcoreapp-Unix;
     netfx-Windows_NT;
-    uap-Windows_NT;
   </BuildConfigurations>
 <PropertyGroup>
 ```
@@ -125,15 +122,14 @@ Temporary versions are at https://github.com/dotnet/corefx/blob/dev/eng/src/Tool
 ## Supported full build configurations
 - .NET Core latest on current OS (default) -> `netcoreapp-[RunningOS]`
 - .NET Framework latest -> `netfx-Windows_NT`
-- UAP F5 -> `uap-Windows_NT`
 
 ## Project configurations for VS
 For each unique configuration needed for a given library project a configuration entry separated by a ';' should be added to the project so it can be selected and built in VS and also clearly identify the various configurations.<BR/>
 
 `$(TargetGroup)-$(OSGroup)-$(ConfigurationGroup)|$(Platform`
 - Note that the majority of managed projects, currently all in corefx, $(Platform) is overridden to be AnyCPU.
 
-`<Configurations>netcoreapp-Unix-Debug;netcoreapp-Unix-Release;netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release;uap-Windows_NT-Debug;uap-Windows_NT-Release</Configurations>`
+`<Configurations>netcoreapp-Unix-Debug;netcoreapp-Unix-Release;netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release</Configurations>`
 
 ####*Examples*
 Project configurations with a unique implementation on Unix and Windows
@@ -142,7 +138,7 @@ Project configurations with a unique implementation on Unix and Windows
 ```
 Project configurations that are unique for a few different target frameworks and runtimes
 ```xml
-<Configurations>netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release;uap-Windows_NT-Debug;uap-Windows_NT-Release</Configurations>
+<Configurations>netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release</Configurations>
 ```
 
 ## Updating Configurations
@@ -246,7 +242,6 @@ Each source file should use the following guidelines
   - `.CoreCLR.cs` - implementation specific to CoreCLR runtime
   - `.Win32.cs` - implementation based on [Win32](https://en.wikipedia.org/wiki/Windows_API)
   - `.WinRT.cs` - implementation based on [WinRT](https://en.wikipedia.org/wiki/Windows_Runtime)
-  - `.Uap.cs` - implementation specific to UAP, also known as [UWP](https://en.wikipedia.org/wiki/Universal_Windows_Platform)
 
 ## Define naming convention
 As mentioned in [Conventions for forked code](conventions-for-forked-code) `#ifdef`ing the code is the last resort as it makes code harder to maintain overtime. If we do need to use `#ifdef`'s we should use the following conventions:

docs/libraries/project-docs/developer-guide.md

@@ -31,7 +31,7 @@ Calling the script `build` attempts to build both the native and managed code.
 
 The build configurations 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. It defaults to `netcoreapp` but possible values include `netcoreapp`, `netfx` or `uap`. (msbuild property `TargetGroup`)
+- `-framework|-f` identifies the target framework for the build. It defaults to `netcoreapp` but possible values include `netcoreapp` or `netfx`. (msbuild property `TargetGroup`)
 - `-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 `OSGroup`)
 - `-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `ConfigurationGroup`)
 - `-arch` identifies the architecture for the build. It defaults to `x64` but possible values include `x64`, `x86`, `arm`, or `arm64`. (msbuild property `ArchGroup`)
@@ -63,7 +63,6 @@ build -restore -build -buildtests -test
 ```
 build -framework netcoreapp
 build -framework netfx
-build -framework uap
 ```
 
 - Build only managed components and skip the native build
@@ -174,11 +173,6 @@ For libraries that have multiple build configurations the configurations will be
 dotnet msbuild System.Net.NetworkInformation.csproj /p:OSGroup=Linux
 ```
 
-- Build project for uap (not if trying to build on non-windows you also need to specify OSGroup=Windows_NT)
-```
-dotnet msbuild System.Net.NetworkInformation.csproj /p:TargetGroup=uap
-```
-
 - Build release version of library
 ```
 dotnet msbuild System.Net.NetworkInformation.csproj /p:ConfigurationGroup=Release
@@ -433,17 +427,6 @@ If coverage succeeds, the individual report can be found at `$(TestPath)\report\
 
 Code coverage reports from the continuous integration system are available from the links on the front page of the corefx repo.
 
-### Building tests with UWP (Windows only)
-
-This will allow you to build and run against `uap`, the managed version of the UWP Framework subset, used when debugging UWP applications in Visual Studio:
-```cmd
-cd src\Microsoft.CSharp\tests
-dotnet msbuild /t:BuildAndTest /p:TargetGroup=uap
-```
-In this case, your test will get executed within the context of a wrapper UWP application, targeting the Managed uap.
-
-The CoreFX build and test suite is a work in progress, as are the [building and testing instructions](../README.md). The .NET Core team and the community are improving Linux and OS X support on a daily basis and are adding more tests for all platforms. See [CoreFX Issues](https://github.com/dotnet/corefx/issues) to find out about specific work items or report issues.
-
 ## Testing with private CoreCLR bits
 
 Generally the CoreFx build system gets the CoreCLR from a NuGet package which gets pulled down and correctly copied to the various output directories by building '\eng\restore\runtime\runtime.depproj' which gets built as part of `build.cmd/sh`. For folks that want to do builds and test runs in corefx with a local private build of coreclr you can follow these steps:

docs/libraries/project-docs/pullrequest-builds.md

@@ -9,7 +9,6 @@ As part of our Pull Requests we have some validation builds where we build the p
 | Windows x86_Release | netcoreapp | X | X |
 | Windows x64_Debug | netcoreapp | X | X |
 | Windows NETFX_x86_Release | netfx | X | X |
-| Windows UWP_CoreCLR_x64_Debug | uap | X | X |
 | Linux x64_Release | netcoreapp | X | X |
 | Linux arm64_Release | netcoreapp | X | X |
 | Linux arm_Release | netcoreapp | X |   |

docs/libraries/project-docs/support-dotnet-core-instructions.md

@@ -4,7 +4,7 @@ Want to make your libraries multi-platform? Want to see how much work is require
 
 ## How to Use Portability Analyzer
 
-To begin using the .NET Portability Analyzer, download the extension from the Visual Studio Gallery. You can configure it in Visual Studio via  *Tools* >> *Options* >> *.NET Portability Analyzer* and select your Target Platforms. For now, please use ASP.NET 5 as a proxy for all .NET Core 5-based platforms (e.g. [Windows 10 .NET UAP apps](http://blogs.windows.com/buildingapps/2015/03/02/a-first-look-at-the-windows-10-universal-app-platform/)). 
+To begin using the .NET Portability Analyzer, download the extension from the Visual Studio Gallery. You can configure it in Visual Studio via  *Tools* >> *Options* >> *.NET Portability Analyzer* and select your Target Platforms.
 
 ![](../images/portability_screenshot.png)
 

eng/Packaging.props

@@ -79,6 +79,4 @@
         <SkipPackageFileCheck>true</SkipPackageFileCheck>
     </File>
   </ItemGroup>
-
-  <Import Condition="'$(MSBuildProjectExtension)' == '.pkgproj'" Project="$(MSBuildThisFileDirectory)disableUap.targets" />
 </Project>

eng/Packaging.targets

@@ -1,9 +1,8 @@
 <Project>
   <!-- Add validation for netcoreapp5.0 to package build and testing -->
   <ItemGroup>
-    <DefaultValidateFramework Include="netcoreapp5.0">
-      <RuntimeIDs>@(NETCoreApp30RIDs)</RuntimeIDs>
-    </DefaultValidateFramework>
+    <DefaultValidateFramework Include="netcoreapp5.0" RuntimeIDs="@(NETCoreApp30RIDs)" />
+    <DefaultValidateFramework Remove="uap10.0.16300" />
   </ItemGroup>
 
   <!--     There are some packages where we require only one ref for a specific framework to be present. In order to avoid problems with this package when targetting 

eng/configurations/targetgroups.props

@@ -7,31 +7,6 @@
       <UWPCompatible>true</UWPCompatible>
       <CompatibleWith>netstandard1.4</CompatibleWith>
     </TargetGroups>
-    <TargetGroups Include="uap10.0.16299">
-      <TargetFramework>uap10.0.16299</TargetFramework>
-      <TargetFrameworkIdentifier>UAP</TargetFrameworkIdentifier>
-      <TargetFrameworkVersion>10.0.16299</TargetFrameworkVersion>
-      <UWPCompatible>true</UWPCompatible>
-      <Imports>netcore50</Imports>
-      <CompatibleWith>netstandard</CompatibleWith>
-    </TargetGroups>
-    <TargetGroups Include="uapvnext">
-      <TargetFramework>$(UAPvNextTFM)</TargetFramework>
-      <TargetFrameworkIdentifier>$(UAPvNextTFI)</TargetFrameworkIdentifier>
-      <TargetFrameworkVersion>$(UAPvNextVersion)</TargetFrameworkVersion>
-      <UWPCompatible>true</UWPCompatible>
-      <Imports>uap10.0.16299</Imports>
-      <CompatibleWith>netstandard2.1</CompatibleWith>
-    </TargetGroups>
-    <!-- uap is an alias for uapvNext any/coreclr runtime -->
-    <TargetGroups Include="uap">
-      <TargetFramework>$(UAPvNextTFM)</TargetFramework>
-      <TargetFrameworkIdentifier>$(UAPvNextTFI)</TargetFrameworkIdentifier>
-      <TargetFrameworkVersion>$(UAPvNextVersion)</TargetFrameworkVersion>
-      <UWPCompatible>true</UWPCompatible>
-      <Imports>uapvnext</Imports>
-      <CompatibleWith>netstandard2.1</CompatibleWith>
-    </TargetGroups>
     <TargetGroups Include="netstandard1.0">
       <TargetFramework>netstandard1.0</TargetFramework>
       <!-- By default, netstandard libraries will be held to the UWP compatibility bar;

eng/pipelines/libraries/corefx-base.yml

@@ -19,7 +19,7 @@ parameters:
   # Required: as part of the strategy matrix, the following variables should be defined
   #     _BuildConfig: Debug | Release
   #     _architecture: x64 | x86 | arm | arm64
-  #     _framework: (netcoreapp, netfx, uap, etc).
+  #     _framework: (netcoreapp, netfx).
   #     _helixQueues: Windows.Amd64 (Only needed if submitToHelix -> true.) -- Queues should be separated by + if multiple.
 
   # Required: empty | innerloop | outerloop | all

eng/pipelines/libraries/windows.yml

@@ -46,13 +46,7 @@ stages:
                 _BuildConfig: Release
                 _architecture: x86
                 _framework: netfx
-                _helixQueues: $(uapNetfxQueues)
-
-              UAP_x64_Debug:
-                _BuildConfig: Debug
-                _architecture: x64
-                _framework: uap
-                _helixQueues: $(uapNetfxQueues)
+                _helixQueues: $(netFxQueues)
 
             # Full test matrix
             ${{ if eq(parameters.fullMatrix, 'true') }}:
@@ -74,23 +68,16 @@ stages:
                 _BuildConfig: Release
                 _architecture: x86
                 _framework: netfx
-                _helixQueues: $(uapNetfxQueues)
+                _helixQueues: $(netFxQueues)
                 _skipPublishPackages: true # In NETFX leg we don't produce packages
 
               NETFX_x64_Release:
                 _BuildConfig: Release
                 _architecture: x64
                 _framework: netfx
-                _helixQueues: $(uapNetfxQueues)
+                _helixQueues: $(netFxQueues)
                 _skipPublishPackages: true # In NETFX leg we don't produce packages
 
-              UAP_x64_Release:
-                _BuildConfig: Release
-                _architecture: x64
-                _framework: uap
-                _helixQueues: $(uapNetfxQueues)
-                _skipPublishPackages: true # In UWP we don't produce packages
-
         pool:
           name: Hosted VS2017
 
@@ -99,7 +86,7 @@ stages:
 
         variables:
           - nanoQueues: "`(Windows.Nano.1809.Amd64.Open`)[email protected]/dotnet-buildtools/prereqs:nanoserver-1809-helix-amd64-61052b7-20190723211353"
-          - uapNetfxQueues: Windows.10.Amd64.ClientRS5.Open
+          - netFxQueues: Windows.10.Amd64.ClientRS5.Open
 
           - ${{ if eq(parameters.fullMatrix, 'false') }}:
             - netcoreappWindowsQueues: Windows.7.Amd64.Open+Windows.81.Amd64.Open+Windows.10.Amd64.Client19H1.ES.Open

eng/restore/binplacePackages/Configurations.props

@@ -14,7 +14,6 @@
       netcoreapp2.0;
       netcoreapp3.0;
       netcoreapp;
-      uap10.0.16299;
     </BuildConfigurations>
   </PropertyGroup>
 </Project>