Enable Pinvoke checker and baseline violations (#16704)

* Fix UWP Pinvoke checker condition

* analyzer baselines

* Remove redundant local define

* Remove redundant CA lines

* Special case Registry

* Fix BlockReflectionAttribute

* Replace NETNATIVE with uap define

* baselines

* Disable Pinvoke scan on specific projects

* Disable BlockReflectionAttribute on ilproj

* Revive 2 baselines

* Disable UWP validation on SQlClient

* Convert some defines to `uwp`

* Fix S.N.Primitives baseline

* Remove dead baselines

* Clean up NET_NATIVE defines

* Remove FEATURE_CORECLR except from shared sources

* Change Threading.Thread defines to just uapaot

* Fix comment

* Fix comment 2

* Change serialization uap defines to uapaot

* Rename EnableWinRT to UWPCompatible

* Fix UAP build for Console

* Fix uap condition in XML csproj

* Fix condition in XmlSerializer project

* Replace netcore50

* Remove dead #if

* Redundant console condition

* Redundant console condition2

* Trim baseline

* Revert Console baseline to pre UAP

* Fix MemoryMappedFiles uap build

* Fix S.Linq.Expressions build for UAP by temporarily disabling it

* Fix S.N.Sockets build for uap

* No plans to put SQLClient in UWP

* Fix RuntimeInformation build

* Fix MemoryMappedFiles build for Unix

* Add UWPCompatible to all netstandard versions

* Add EnablePinvokeAnalyzer to disable Pinvoke checking entirely for some reason

* Remove dead System.Xml.XmlSerializer.Tests.settings.targets

* Fix interop services build

* Remove last uap/uapaot define in Xml tests

* PInvoke check doc

* Fix PInvoke casing

* PInvoke file is case sensitive

* Remove unnecessary references to uapaot from projects that don't have uapaot configs

* Remove unnecessary uapaot from S.R.I.RI

* Replace UWPCompatible for TargetGroup in csproj conditions

* Reverse FileSystem edit as not ready to build for UWP

2 files changed, 41 insertions, 0 deletions

diff --git a/Documentation/README.md b/Documentation/README.md
index 1d778b9ea8..78dfd2ad23 100644
--- a/Documentation/README.md
+++ b/Documentation/README.md
@@ -46,12 +46,14 @@ Coding Guidelines
 - [Breaking Change Rules](coding-guidelines/breaking-change-rules.md)
 - [Project Guidelines](coding-guidelines/project-guidelines.md)
 - [Adding APIs Guidelines](coding-guidelines/adding-api-guidelines.md)
+- [Legal Native calls](building/pinvoke-checker.md)
 
 Building from Source
 ====================
 
 - [Building CoreFX on FreeBSD, Linux and OS X](building/unix-instructions.md)
 - [Code Coverage](building/code-coverage.md)
+- [Cross Building](building/cross-building.md)
 - [Package and Assembly File Versioning](building/versioning.md)
 
 Other Information
diff --git a/Documentation/building/pinvoke-checker.md b/Documentation/building/pinvoke-checker.md
new file mode 100644
index 0000000000..98aa8788a3
--- /dev/null
+++ b/Documentation/building/pinvoke-checker.md
@@ -0,0 +1,39 @@
+# PInvoke Analyzer
+
+During the build of any product library in CoreFX we use a Roslyn code analyzer to look for disallowed native calls (PInvokes). When there is a violation, it will fail the build. To fix the build, either find an alternative to the PInvoke or baseline the failure temporarily. To baseline it, add the function name in the format `module!entrypoint` to a file named PInvokeAnalyzerExceptionList.analyzerdata in the same folder as the project. [Here](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/PInvokeAnalyzerExceptionList.analyzerdata) is an example. 
+
+If you baseline a violation, please open an issue to fix it because the library likely cannot ship in this situation. It is better to not introduce the violation. We want to clean out any baselines. There are situations where a violation may be acceptable. One situation is where we are shipping the native implementation of the API. An example of this situation is `sni.dll` which is used by SqlClient.
+
+Each project is analyzed against one of two possible lists we maintain.
+
+## Legal UWP API's
+
+### Applies to
+This applies to product libraries that are being built for use in a modern Windows app (aka UWP app, or app running on UAP). When building the `uapaot` or `uap` configurations we will apply this check. If the library does not have a `uap` or `uapaot` configuration explicitly listed in `Configuration.props` in the project folder, when targeting `uap` or `uapaot` we will build the `netstandard` configuration, and apply this check.
+
+We do not currently apply this check to test binaries. Although when testing UWP libraries the tests must run within a test app, they do not need to pass through the store validation process. It is still possible they may call an API that does not work correctly within an app's security boundary and that call would have to be avoided.
+
+### Motivation
+Not all PInvokes are legal within a UWP app. An allow-list is enforced when the Windows store ingests an app, and also in a build step in the Visual Studio build process for apps. If we produce a library for UWP use, any PInvokes it performs must be to API's that are on the allow-list or the app using the library will fail validation.
+
+### Implementation
+To enforce this the analyzer consults the list [here](https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.CodeAnalysis/PackageFiles/PinvokeAnalyzer_Win32UWPApis.txt). 
+
+The analyzer is enabled by default in the configurations below by the setting of the MSBuild property `UWPCompatible`. We aim to make all our `netstandard` compliant libraries work within a UWP app, but in rare cases where a library cannot, the check can be disabled with `<UWPCompatible>false</UWPCompatible>` in the project file.
+
+There is also a more fine grained property `<EnablePInvokeUWPAnalyzer>false</EnablePInvokeUWPAnalyzer>` for temporary use.
+
+## Legal OneCore API's
+
+### Applies to
+This applies to all other product libraries in all other configurations targeted at Windows.
+
+We do not currently apply this check to test binaries as they do not need to run on Windows Nano.
+
+### Motivation
+.NET Core supports execution on Windows Nano, which has a reduced API surface area known as OneCore. To run on Windows Nano we cannot invoke any platform API that is not available on OneCore.
+
+### Implementation
+To enforce this the analyzer consults the list [here](https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.CodeAnalysis/PackageFiles/PinvokeAnalyzer_Win32Apis.txt). 
+
+The analyzer is enabled by default when building for Windows, not a test, and not building for UWP. We aim to make all such configurations OneCore compilant, but in the rare cases where a library cannot be, the check can be disabled with `<EnablePInvokeAnalyzer>false<EnablePInvokeAnalyzer>` in the project file.