Imported Upstream version 5.2.0.175

Former-commit-id: bb0468d0f257ff100aa895eb5fe583fb5dfbf900

external/corefx/Documentation/project-docs/developer-guide.md

@@ -30,7 +30,7 @@ For more information about the different options that each task has, use the arg
 build -?
 ```
 
-###Build
+### Build
 The CoreFX build has two logical components, the native build which produces the "shims" (which provide a stable interface between the OS and managed code) and
 the managed build which produces the MSIL code and nuget packages that make up CoreFX.
 
@@ -64,14 +64,19 @@ build-tests
 build -debug -buildArch=x64
 ```
 
-- Building for different target frameworks
+- Building the src and then building and running the tests
 ```
-build -framework netcoreapp
-build -framework netfx
-build -framework uap
+build -tests
 ```
 
-###Build Native
+- Building for different target frameworks
+```
+build -framework=netcoreapp
+build -framework=netfx
+build -framework=uap
+```
+
+### Build Native
 The native build produces shims over libc, openssl, gssapi, libcurl and libz.
 The build system uses CMake (2.8.12 or higher) to generate Makefiles using clang (3.5 or higher).
 The build also uses git for generating some version information.
@@ -92,7 +97,7 @@ build-native -debug -buildArch=arm -- cross verbose
 
 For more information about extra parameters take a look at the scripts `build-native` under src/Native.
 
-###Build Managed
+### Build Managed
 Since the managed build uses the .NET Core CLI (which the build will download), managed components can only be built on a subset of distros.
 There are some additional prerequisites from the CLI which need to be installed. Both libicu and
 libunwind are used by CoreCLR to execute managed code, so they must be
@@ -112,7 +117,7 @@ build-managed -debug -buildArch=x64
 build-managed -debug -buildArch=x64 -os=Linux
 ```
 
-###Build And Run Tests
+### Build And Run Tests
 To build the tests and run them you can call the build-test script. The same parameters you pass to build should also be passed to build-tests script to ensure you are building and running the tests on the same configuration you have build the product on. However to run tests on the same machine you need to ensure the machine supports the configuration you are building.
 
 **Examples**
@@ -123,7 +128,7 @@ build-tests -skiptests
 
 - The following builds and runs all tests for netcoreapp in release configuration.
 ```
-build-tests -release -framework netcoreapp
+build-tests -release -framework=netcoreapp
 ```
 
 - The following example shows the argument `--`. Everything that is after it is not going to be processed and it is going to be passed as it is.
@@ -305,3 +310,32 @@ 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 as opposed to the .NET Native version.
 
 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 '\external\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:
+
+
+1. Build CoreCLR and note your output directory. Ex: `\coreclr\bin\Product\Windows_NT.x64.Release\` Note this will vary based on your OS/Architecture/Flavor and it is generally a good idea to use Release builds for CoreCLR when running CoreFx tests and the OS and Architecture should match what you are building in CoreFx.
+2. Build CoreFx either passing in the `CoreCLROverridePath` property or setting it as an environment variable:
+```
+build.cmd -- /p:CoreCLROverridePath=d:\git\coreclr\bin\Product\Windows_NT.x64.Release\
+```
+
+When we copy the files to override the CoreCLR we do a hard-link copy, so in general if you rebuild CoreCLR the new binaries should be reflected in CoreFx for subsequent builds of individual projects in corefx. However if you want to force refresh or if you want to just update the CoreCLR after you already ran `build.cmd` from CoreFx you can run the following command:
+
+```
+msbuild /p:CoreCLROverridePath=d:\git\coreclr\bin\Product\Windows_NT.x64.Release\ ./external/runtime/runtime.depproj
+```
+
+By convention the project will look for PDBs in a directory under `$(CoreCLROverridePath)/PDB` and if found will also copy them. If not found no PDBs will be copied. If you want to explicitly set the PDB path then you can pass `CoreCLRPDBOverridePath` property to that PDB directory.
+
+Also to aide with code coverage runs if the `Coverage` property is set to true we will skip copying any *.ni.* files to the output.
+
+Once you have updated your CoreCLR you can run tests however you usually do (via build-tests.cmd, individual test project, in VS, etc) and it should be using your copy of CoreCLR. If you want to verify that your bits are being used have a look in `\corefx\bin\testhost\netcoreapp-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\9.9.9` which is the shared framework directory used by corefx tests.
+
+If you prefer, you can use a Debug build of System.Private.CoreLib, but if you do you must also use a Debug build of the native portions of the runtime, e.g. coreclr.dll. Tests with a Debug runtime will execute much more slowly than with Release runtime bits.
+
+To collect code coverage that includes types in System.Private.CoreLib.dll, you'll need to follow the above steps, then
+
+`msbuild /p:CoreCLROverridePath=d:\git\coreclr\bin\Product\Windows_NT.x64.Release\ /t:rebuildandtest /p:Coverage=true /p:CodeCoverageAssemblies="System.Private.CoreLib"`

external/corefx/Documentation/project-docs/dogfooding.md

@@ -1,71 +1,35 @@
-# How to patch dotnet CLI with latest CoreFX
+# How to get up and running on .NET Core 2.0
 
-This document provides the steps necessary to consume a nightly build of CoreFX
-and CoreCLR.
+This document provides the steps necessary to consume a nightly build of
+.NET Core 2.0 runtime and SDK.
 
-Please note that these steps aren't necessary for official builds -- these steps
-are specific to consuming nightlies and thus unsupported builds. Also note that
-these steps are likely to change as we're simplifying this experience. Make
-sure to consult this document often.
+Please note that these steps are likely to change as we're simplifying
+this experience. Make sure to consult this document often.
 
 ## Install prerequisites
 
-1. Install CLI 2.0.0-alpha SDK
-    - [Win 64-bit Latest](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-dev-win-x64.latest.exe)
-    - [macOS 64-bit Latest](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-dev-osx-x64.latest.pkg)
-    - [Others](https://github.com/dotnet/cli/blob/master/README.md)
+1. Acquire the latest nightly .NET Core SDK 2.0
+
+- [Win 64-bit Latest Zip](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-dev-win-x64.latest.zip) [Installer](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-dev-win-x64.latest.exe)
+- [macOS 64-bit Latest Tar](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-dev-osx-x64.latest.tar.gz) [Installer](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-dev-osx-x64.latest.pkg)
+- [Others](https://github.com/dotnet/cli/blob/master/README.md#installers-and-binaries)
+
+To setup the SDK download the zip and extract it somewhere and add the root folder to your path or always fully
+qualify the path to dotnet in the root of this folder for all the instructions in this document.
+
+Note: Installer will put dotnet globally in your path which you might not want for dogfooding daily toolsets.
+
+After setting up dotnet you can verify you are using the newer version by:
+
+`dotnet --info` -- the version should be greater than 2.0.0-*
 
 ## Setup the project
 
 1. Create a new project
-    - Creat a new folder for your app
-    - Create project file by running `dotnet new`
+    - Create a new folder for your app
+    - Create project file by running `dotnet new console`
 
-2. Add the CoreFX MyGet feed to your NuGet configuration.
-    - You can do this globally but we recommend not doing this as this might
-      affect other projects on your machine and you probably don't want that.
-    - Instead, add a `nuget.config` that is local to your project. You can
-      just put it next to the `.csproj` file.
-      See the [NuGet docs](https://docs.nuget.org/ndocs/consume-packages/configuring-nuget-behavior)
-      for details.
-
-    ```xml
-    <configuration>
-      <packageSources>
-        <add key="CoreFX" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
-      </packageSources>
-    </configuration>
-    ```
-
-3. Select the nightly build from our feed
-    - <https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App>
-    - Presumably you want the latest version.
-
-In order to consume the latest build, you'll need to update your `.csproj`
-as follows:
-
-1. Update `TargetFramework`, add `RuntimeIdentifier` as below (ideally
-   `dotnet.exe` would infer your current architecture but it currently doesn't)
-2. Update package reference to match version selected above, as below
-
-```xml
-<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
-
-  <PropertyGroup>
-    <OutputType>Exe</OutputType>
-    <TargetFramework>netcoreapp2.0</TargetFramework>
-    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
-  </PropertyGroup>
-
-  <!-- Make sure to use Update, not Include! -->
-  <ItemGroup>
-    <PackageReference Update="Microsoft.NETCore.App" Version="2.0.0-beta-001386-00" />
-  </ItemGroup>
-
-</Project>
-```
-
-Restore packages so that you're ready to play:
+2. Restore packages so that you're ready to play:
 
 ```
 $ dotnet restore
@@ -97,3 +61,179 @@ $ dotnet run
 ```
 
 Rinse and repeat!
+
+## Advanced Scenario - Using a nightly build of Microsoft.NETCore.App
+
+When using the above instructions, your application will run against the same
+.NET Core 2.0 runtime that comes with the SDK. That works fine to get up and
+running quickly. However, there are times when you need to use a nightly build
+of Microsoft.NETCore.App which hasn't made its way into the SDK yet. To enable
+this, there are two options you can take.
+
+### Option 1: Framework-dependent
+
+This is the default case for applications - running against an installed .NET Core
+runtime.
+
+0. You still need to install the prerequisite .NET Core SDK from above.
+1. Also, install the specific .NET Core runtime you require:
+    - https://github.com/dotnet/core-setup#daily-builds
+    - Remember the version number you picked, you'll need it below
+2. Modify your .csproj to reference the nightly build of Microsoft.NETCore.App
+
+```XML
+  <PropertyGroup>
+    <OutputType>Exe</OutputType>
+    <TargetFramework>netcoreapp2.0</TargetFramework>
+    <RuntimeFrameworkVersion>2.0.0-beta-xyz-00</RuntimeFrameworkVersion> <!-- this line -->
+  </PropertyGroup>
+```
+
+```
+$ dotnet restore
+$ dotnet run
+```
+
+### Option 2: Self-contained
+
+In this case, the .NET Core runtime will be published along with your application.
+
+0. You still need to install the prerequisite .NET Core SDK from above.
+1. Modify your .csproj to reference the nightly build of Microsoft.NETCore.App *and*
+make it self-contained
+
+```XML
+  <PropertyGroup>
+    <OutputType>Exe</OutputType>
+    <TargetFramework>netcoreapp2.0</TargetFramework>
+    <RuntimeFrameworkVersion>2.0.0-beta-xyz-00</RuntimeFrameworkVersion> <!-- pick nightly build -->
+    <RuntimeIdentifier>win7-x64</RuntimeIdentifier> <!-- make self-contained -->
+  </PropertyGroup>
+```
+
+```
+$ dotnet restore
+$ dotnet publish
+$ bin\Debug\netcoreapp2.0\win7-x64\publish\App.exe
+```
+
+Note #1: There is a [bug](https://github.com/dotnet/sdk/issues/791) with `dotnet run` and
+self-contained applications. If you `dotnet run` and see an error `The library 'hostpolicy.dll'
+required to execute the application...`, you've hit this bug.
+
+Note #2: On non-Windows platforms, self-contained applications aren't runnable by default. You will
+see an error "Permission denied" when running the application. This is because of a
+[breaking change in the .NET Core runtime](https://github.com/dotnet/corefx/issues/15516) between 1.0 and 2.0.
+Either this breaking change needs to be fixed, or [NuGet will have to workaround the change]
+(https://github.com/NuGet/Home/issues/4424).
+
+To workaround this issue, run `chmod u+x bin/Debug/netcoreapp2.0/RID/publish/App` before executing
+your application.
+
+## Using your local CoreFx build
+
+To use your local built corefx packages you will need to be a self-contained application and so you will
+need to follow the "Self-contained" steps from above. Once you can successfully restore, build, publish,
+and run a self-contained application you need the following steps to consume your local built package.
+
+#### 1 - Get the Version number of the CoreFx package you built.
+
+Look for a package named `Microsoft.Private.CoreFx.NETCoreApp.<version>.nupkg` under `corefx\bin\packages\Debug` (or Release if you built a release version of corefx).
+
+Once you find the version number (for this example assume it is `4.4.0-beta-25102-0`) you need to add the following line to your project file:
+
+```
+  <ItemGroup>
+    <PackageReference Include="Microsoft.Private.CoreFx.NETCoreApp" Version="4.4.0-beta-25102-0" />
+  </ItemGroup>
+```
+
+#### 2 - Add your bin directory to the Nuget feed list
+
+By default the dogfooding dotnet SDK will create a Nuget.Config file next to your project, if it doesn't
+you can create one. Your config file will need a source for your local corefx package directory as well
+as a reference to our nightly dotnet-core feed on myget:
+
+```xml
+<configuration>
+  <packageSources>
+    <add key="local coreclr" value="D:\git\corefx\bin\packages\Debug" />
+    <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
+  </packageSources>
+</configuration>
+
+```
+Obviously **you need to update path in the XML to be the path to output directory for your build**.
+
+On Windows you also have the alternative of modifying the Nuget.Config
+at `%HOMEPATH%\AppData\Roaming\Nuget\Nuget.Config` (`~/.nuget/NuGet/NuGet.Config` on Linux) with the new location.
+This will allow your new runtime to be used on any 'dotnet restore' run by the current user.
+Alternatively you can skip creating this file and pass the path to your package directory using
+the -s SOURCE qualifer on the dotnet restore command below. The important part is that somehow
+you have told the tools where to find your new package.
+
+Once have made these modifications you will need to rerun the restore and publish as such.
+
+```
+dotnet restore
+dotnet publish
+```
+Now your publication directory should contain your local built CoreFx binaries.
+
+#### 3 - Consuming updated packages
+
+One possible problem with the technique above is that Nuget assumes that distinct builds have distinct version numbers.
+Thus if you modify the source and create a new NuGet package you must give it a new version number and use that in your
+application's project. Otherwise the dotnet.exe tool will assume that the existing version is fine and you
+won't get the updated bits. This is what the Minor Build number is all about. By default it is 0, but you can
+give it a value by setting the BuildNumberMinor environment variable.
+```bat
+    set BuildNumberMinor=3
+```
+before packaging. You should see this number show up in the version number (e.g. 4.4.0-beta-25102-03).
+
+As an alternative you can delete the existing copy of the package from the Nuget cache. For example on
+windows (on Linux substitute ~/ for %HOMEPATH%) you could delete
+```bat
+     %HOMEPATH%\.nuget\packages\Microsoft.Private.CoreFx.NETCoreApp\4.4.0-beta-25102-0
+```
+which should make things work (but is fragile, confirm file timestamps that you are getting the version you expect)
+
+### Consuming individual library packages
+
+The instructions above were only about updates to the binaries that are part of Microsoft.NETCore.App, if you want to test a package
+for library that ships in its own nuget package you can follow the same steps above but instead add a package reference to the
+individual library package from your `bin\packages\Debug` folder.
+
+## Consuming non-NetStandard assets in a .NET Core 2.0 application
+
+Currently if you reference a NuGet package that does not have a NETStandard asset in your .NET Core 2.0 application, you will hit package
+incompatibility errors when trying to restore packages. You can resolve this issue by adding `PackageTargetFallback` property
+(MSBuild equivalent of `imports`) to your .csproj:
+
+```XML
+  <PackageTargetFallback>$(PackageTargetFallback);net45</PackageTargetFallback>
+```
+
+Note that this can fix the problem if the package is actually compatible with netcoreapp2.0 (meaning it does not use types/APIs
+that are not available in netcoreapp2.0)
+
+For final release, we are considering modifying NuGet behavior to automatically consume the non-netstandard asset if there is no netstandard available.
+
+
+## Creating a .NET Core 2.0 console application from Visual Studio 2017
+
+File > New > Project > Console App (.NET Core)
+
+By default, Visual Studio creates a netcoreapp1.1 application. After installing the prerequisites mentioned above, you will
+need to modify your .csproj to target netcoreapp2.0 and reference the nightly build of Microsoft.NETCore.APP
+
+```XML
+  <PropertyGroup>
+    <OutputType>Exe</OutputType>
+    <TargetFramework>netcoreapp2.0</TargetFramework> <!-- this line -->
+    <RuntimeFrameworkVersion>2.0.0-beta-xyz-00</RuntimeFrameworkVersion> <!-- this line -->
+  </PropertyGroup>
+```
+
+In a future update to Visual Studio, it will no longer be necessary to make this edit.

external/corefx/Documentation/project-docs/glossary.md

@@ -103,13 +103,13 @@ A simple example of LINQ is
 var odds = source.Where(obj => obj.Id == 1).ToArray();
 ```
 
-####IQueryable<T> and Expressions
+#### IQueryable<T> and Expressions
 
 One of the big advantages of using LINQ over more common data processing patterns is that the function given to the LINQ function can be converted to an expression and then executed in some other form, like SQL or on another machine across the network. An expression is a in-memory representation of some logic to follow.
 
 For example, in the above sample `source` could actually be a database connection and the function call `Where(obj => obj.Id == 1)` would be conveted to a SQL WHERE clause: `WHERE ID = 1`, and then executed on the SQL server.
 
-####Parallel LINQ
+#### Parallel LINQ
 
 **Also referred to as**: PLINQ
 
@@ -138,4 +138,4 @@ The .NET platform currently doesn't contain a cross-platform XAML-based UI stack
 * [CSHTML5](http://www.cshtml5.com/): A product to compile WPF/.NET Framework applications into HTML5/CSS3/ECMAScript5 applications.
 * [WPFLight](https://github.com/ronnycsharp/WPFLight): An OSS project to create WPF on top of XNA/MonoGame.
 * [Perspex](https://github.com/Perspex/Perspex): A cross-platform UI framework based on WPF.
-* [Granular](https://github.com/yuvaltz/Granular): A OSS project to allow WPF applications to run in the browser.
+* [Granular](https://github.com/yuvaltz/Granular): A OSS project to allow WPF applications to run in the browser.

external/corefx/Documentation/project-docs/issue-guide.md

@@ -16,16 +16,16 @@ Sometimes after debate, we'll decide an issue isn't a good fit for CoreFx.  In t
 We use GitHub [labels](https://github.com/dotnet/corefx/labels) on our issues in order to classify them.  We have the following categories per issue:
 * **Area**: These area-* labels (e.g. [area-System.Collections](https://github.com/dotnet/corefx/labels/area-System.Collections)) call out the assembly or assemblies the issue applies to. In addition to labels per assembly, we have a few other area labels: [area-Infrastructure](https://github.com/dotnet/corefx/labels/area-Infrastructure), for issues that relate to our build or test infrastructure, and [area-Meta](https://github.com/dotnet/corefx/labels/area-Meta) for issues that deal with the repository itself, the direction of the .NET Core Platform, our processes, etc. See [full list of areas](#areas).
 * **Issue Type**: These labels classify the type of issue.  We use the following types:
- * [bug](https://github.com/dotnet/corefx/labels/bug): Bugs in an assembly.
- * api-* ([api-approved](https://github.com/dotnet/corefx/labels/api-approved), [api-needs-work](https://github.com/dotnet/corefx/labels/api-needs-work)): Issues which would add APIs to an assembly (see [API Review process](api-review-process.md) for details).
- * [enhancement](https://github.com/dotnet/corefx/labels/enhancement): Improvements to an assembly which do not add new APIs (e.g. performance improvements, code cleanup).
- * [test bug](https://github.com/dotnet/corefx/labels/test%20bug): Bugs in the tests for a specific assembly.
- * [test enhancement](https://github.com/dotnet/corefx/labels/test%20enhancement): Improvements in the tests for a specific assembly (e.g. improving test coverage).
- * [documentation](https://github.com/dotnet/corefx/labels/documentation): Issues related to documentation (e.g. incorrect documentation, enhancement requests).
- * [question](https://github.com/dotnet/corefx/labels/question): Questions about the product, source code, etc.
+  * [bug](https://github.com/dotnet/corefx/labels/bug): Bugs in an assembly.
+  * api-* ([api-approved](https://github.com/dotnet/corefx/labels/api-approved), [api-needs-work](https://github.com/dotnet/corefx/labels/api-needs-work), [api-ready-for-review](https://github.com/dotnet/corefx/labels/api-ready-for-review)): Issues which would add APIs to an assembly (see [API Review process](api-review-process.md) for details).
+  * [enhancement](https://github.com/dotnet/corefx/labels/enhancement): Improvements to an assembly which do not add new APIs (e.g. performance improvements, code cleanup).
+  * [test bug](https://github.com/dotnet/corefx/labels/test%20bug): Bugs in the tests for a specific assembly.
+  * [test enhancement](https://github.com/dotnet/corefx/labels/test%20enhancement): Improvements in the tests for a specific assembly (e.g. improving test coverage).
+  * [documentation](https://github.com/dotnet/corefx/labels/documentation): Issues related to documentation (e.g. incorrect documentation, enhancement requests).
+  * [question](https://github.com/dotnet/corefx/labels/question): Questions about the product, source code, etc.
 * **Other**:
- * [up for grabs](https://github.com/dotnet/corefx/labels/up%20for%20grabs): Small sections of work which we believe are well scoped.  These sorts of issues are a good place to start if you are new.  Anyone is free to work on these issues.
- * [needs more info](https://github.com/dotnet/corefx/labels/needs%20more%20info): Issues which need more information to be actionable.  Usually this will be because we can't reproduce a reported bug.  We'll close these issues after a little bit if we haven't gotten actionable information, but we welcome folks who have acquired more information to reopen the issue.
+  * [up for grabs](https://github.com/dotnet/corefx/labels/up%20for%20grabs): Small sections of work which we believe are well scoped.  These sorts of issues are a good place to start if you are new.  Anyone is free to work on these issues.
+  * [needs more info](https://github.com/dotnet/corefx/labels/needs%20more%20info): Issues which need more information to be actionable.  Usually this will be because we can't reproduce a reported bug.  We'll close these issues after a little bit if we haven't gotten actionable information, but we welcome folks who have acquired more information to reopen the issue.
 
 In addition to the above, we have a handful of other labels we use to help classify our issues.  Some of these tag cross cutting concerns (e.g. [tenet-performance](https://github.com/dotnet/corefx/labels/tenet-performance)), whereas others are used to help us track additional work needed before closing an issue (e.g. [api-needs-exposed](https://github.com/dotnet/corefx/labels/api-needs-exposed)).
 
@@ -42,24 +42,24 @@ Areas are tracked by labels area-* (e.g. area-System.Collections). Each area
 
 | Area                                                                                          | Owners / experts | Description |
 |-----------------------------------------------------------------------------------------------|------------------|-------------|
-| [area-Infrastructure](https://github.com/dotnet/corefx/labels/area-Infrastructure)                      | [@mellinoe](https://github.com/mellinoe), [@ericstj](https://github.com/ericstj), [@weshaggard](https://github.com/weshaggard) |Covers:<ul><li>Packaging</li><li>Build and test infra</li><li>VS intergation</li></ul><br/>**Triage in progress** |
-| [area-Meta](https://github.com/dotnet/corefx/labels/area-Meta)                                | [@tarekgh](https://github.com/tarekgh) | Issues without clear association to any specific API/contract, e.g. <ul><li>new contract proposals</li><li>cross-cutting code/test pattern changes (e.g. FxCop failures)</li><li>project-wide docs</li></ul> **Triage in progress** |
+| [area-Infrastructure](https://github.com/dotnet/corefx/labels/area-Infrastructure)                      | [@mellinoe](https://github.com/mellinoe), [@ericstj](https://github.com/ericstj), [@weshaggard](https://github.com/weshaggard) |Covers:<ul><li>Packaging</li><li>Build and test infra for CoreFX repo</li><li>VS integration</li></ul><br/>**Triage in progress** |
+| [area-Meta](https://github.com/dotnet/corefx/labels/area-Meta)                                | [@tarekgh](https://github.com/tarekgh) | Issues without clear association to any specific API/contract, e.g. <ul><li>new contract proposals</li><li>cross-cutting code/test pattern changes (e.g. FxCop failures)</li><li>project-wide docs</li></ul><br/>**Triage in progress** |
 | [area-Serialization](https://github.com/dotnet/corefx/labels/area-Serialization)              | [@shmao](https://github.com/shmao), [@zhenlan](https://github.com/zhenlan) | Packages:<ul><li>System.Runtime.Serialization.Xml</li><li>System.Runtime.Serialization.Json</li><li>System.Private.DataContractSerialization</li><li>System.Xml.XmlSerialization</li></ul> Excluded:<ul><li>System.Runtime.Serialization.Formatters</li></ul> |
 | **System contract assemblies** | | |
 | [System.AppContext](https://github.com/dotnet/corefx/labels/area-System.AppContext)           | [@AlexGhiondea](https://github.com/AlexGhiondea) |  |  |
-| [System.Buffers](https://github.com/dotnet/corefx/labels/area-System.Buffers)                 | [@alexperovich](https://github.com/alexperovich),  [@safern](https://github.com/safern) |  |
+| [System.Buffers](https://github.com/dotnet/corefx/labels/area-System.Buffers)                 | [@alexperovich](https://github.com/alexperovich), [@safern](https://github.com/safern) |  |
 | [System.CodeDom](https://github.com/dotnet/corefx/labels/area-System.CodeDom)                 | [@Priya91](https://github.com/Priya91) |  |
-| [System.Collections](https://github.com/dotnet/corefx/labels/area-System.Collections)         | [@ianhays](https://github.com/ianhays) | </ul>Excluded:<ul><li>System.Array -> System.Runtime</li></ul> |
+| [System.Collections](https://github.com/dotnet/corefx/labels/area-System.Collections)         | [@ianhays](https://github.com/ianhays), [@safern](https://github.com/safern) | </ul>Excluded:<ul><li>System.Array -> System.Runtime</li></ul> |
 | [System.ComponentModel](https://github.com/dotnet/corefx/labels/area-System.ComponentModel)   |  [@safern](https://github.com/safern), [@AlexGhiondea](https://github.com/AlexGhiondea) |  |
-| [System.ComponentModel.DataAnnotations](https://github.com/dotnet/corefx/labels/area-System.ComponentModel.DataAnnotations) | [@lajones](https://github.com/lajones), [@divega](https://github.com/divega) | **Pending triage** |
+| [System.ComponentModel.DataAnnotations](https://github.com/dotnet/corefx/labels/area-System.ComponentModel.DataAnnotations) | [@lajones](https://github.com/lajones), [@divega](https://github.com/divega), [@ajcvickers](https://github.com/ajcvickers) | **Triage in progress** |
 | [System.Composition](https://github.com/dotnet/corefx/labels/area-System.Composition)         | [@AlexGhiondea](https://github.com/AlexGhiondea) |  |
 | [System.Configuration](https://github.com/dotnet/corefx/labels/area-System.Configuration)     | [@JeremyKuhne](https://github.com/JeremyKuhne) |  |
 | [System.Console](https://github.com/dotnet/corefx/labels/area-System.Console)                 | [@ianhays](https://github.com/ianhays) |  |
-| [System.Data](https://github.com/dotnet/corefx/labels/area-System.Data)                       | [@saurabh500](https://github.com/saurabh500), [@YoungGah](https://github.com/YoungGah) |  |
+| [System.Data](https://github.com/dotnet/corefx/labels/area-System.Data)                       | [@saurabh500](https://github.com/saurabh500), [@corivera](https://github.com/corivera) |  |
 | [System.Data.SqlClient](https://github.com/dotnet/corefx/labels/area-System.Data.SqlClient)   | [@saurabh500](https://github.com/saurabh500), [@YoungGah](https://github.com/YoungGah) | **Pending triage** |
 | [System.Diagnostics](https://github.com/dotnet/corefx/labels/area-System.Diagnostics)         | [@joperezr](https://github.com/dotnet/joperezr) |  |
 | [System.Diagnostics.Process](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Process) | [@Priya91](https://github.com/Priya91) |  |
-| [System.Diagnostics.Tracing](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Tracing) |  | **Pending triage** |
+| [System.Diagnostics.Tracing](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Tracing) |  [@brianrob](https://github.com/brianrob), [@vancem](https://github.com/vancem), [@valenis](https://github.com/valenis)| Packages:<ul><li>System.Diagnostics.DiagnosticSource</li><li>System.Diagnostics.PerformanceCounter</li><li>System.Diagnostics.Tracing</li><li>System.Diagnostics.TraceSource</li></ul><br/>**Pending triage** |
 | [System.DirectoryServices](https://github.com/dotnet/corefx/labels/area-System.DirectoryServices) | [@tquerec](https://github.com/tquerec) |  |
 | [System.Drawing](https://github.com/dotnet/corefx/labels/area-System.Drawing)                 | [@alexperovich](https://github.com/alexperovich) |  |
 | [System.Dynamic.Runtime](https://github.com/dotnet/corefx/labels/area-System.Dynamic.Runtime) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) |  |
@@ -69,23 +69,24 @@ Areas are tracked by labels area-&#42; (e.g. area-System.Collections). Each area
 | [System.Linq](https://github.com/dotnet/corefx/labels/area-System.Linq)                       | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) |  |
 | [System.Linq.Expressions](https://github.com/dotnet/corefx/labels/area-System.Linq.Expressions)   | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) |  |
 | [System.Linq.Parallel](https://github.com/dotnet/corefx/labels/area-System.Linq.Parallel)     | [@alexperovich](https://github.com/alexperovich), [@kouvel](https://github.com/kouvel) |  |
+| [System.Memory](https://github.com/dotnet/corefx/labels/area-System.Memory)                   | [@KrzysztofCwalina](https://github.com/KrzysztofCwalina), [@ahsonkhan](https://github.com/ahsonkhan), [@shiftylogic](https://github.com/shiftylogic) | **Pending triage** |
 | [System.Net](https://github.com/dotnet/corefx/labels/area-System.Net)                         | [@davidsh](https://github.com/davidsh), [@CIPop](https://github.com/CIPop), [@Priya91](https://github.com/Priya91) | **Triage in progress** |
 | [System.Net.Http](https://github.com/dotnet/corefx/labels/area-System.Net.Http)               | [@davidsh](https://github.com/davidsh), [@CIPop](https://github.com/CIPop), [@Priya91](https://github.com/Priya91) | |
 | [System.Net.Security](https://github.com/dotnet/corefx/labels/area-System.Net.Security)       | [@davidsh](https://github.com/davidsh), [@CIPop](https://github.com/CIPop), [@Priya91](https://github.com/Priya91) | |
 | [System.Net.Sockets](https://github.com/dotnet/corefx/labels/area-System.Net.Sockets)         | [@davidsh](https://github.com/davidsh), [@CIPop](https://github.com/CIPop), [@Priya91](https://github.com/Priya91) | |
 | [System.Numerics](https://github.com/dotnet/corefx/labels/area-System.Numerics)               | [@mellinoe](https://github.com/mellinoe) |  |
-| [System.Reflection](https://github.com/dotnet/corefx/labels/area-System.Reflection)           | [@dnlharvey](https://github.com/dnlharvey), [@AtsushiKan](https://github.com/AtsushiKan) | **Pending triage** |
-| [System.Reflection.Emit](https://github.com/dotnet/corefx/labels/area-System.Reflection.Emit) | [@dnlharvey](https://github.com/dnlharvey), [@AtsushiKan](https://github.com/AtsushiKan) | **Pending triage** |
+| [System.Reflection](https://github.com/dotnet/corefx/labels/area-System.Reflection)           | [@dnlharvey](https://github.com/dnlharvey), [@AtsushiKan](https://github.com/AtsushiKan) |  |
+| [System.Reflection.Emit](https://github.com/dotnet/corefx/labels/area-System.Reflection.Emit) | [@dnlharvey](https://github.com/dnlharvey), [@AtsushiKan](https://github.com/AtsushiKan) |  |
 | [System.Reflection.Metadata](https://github.com/dotnet/corefx/labels/area-System.Reflection.Metadata) | [@tmat](https://github.com/tmat), [@nguerrera](https://github.com/nguerrera) |  |
-| [System.Resources](https://github.com/dotnet/corefx/labels/area-System.Resources)             | [@ramarag](https://github.com/ramarag), [@tarekgh](https://github.com/tarekgh) | **Pending triage** |
+| [System.Resources](https://github.com/dotnet/corefx/labels/area-System.Resources)             | [@ramarag](https://github.com/ramarag), [@tarekgh](https://github.com/tarekgh) | **Triage in progress** |
 | [System.Runtime](https://github.com/dotnet/corefx/labels/area-System.Runtime)                 | [@AlexGhiondea](https://github.com/AlexGhiondea), [@joperezr](https://github.com/dotnet/joperezr) | Included:<ul><li>System.Runtime.Serialization.Formatters</li><li>System.Runtime.InteropServices.RuntimeInfo</li><li>System.Array</li></ul>Excluded:<ul><li>Path -> System.IO</li><li>StopWatch -> System.Diagnostics</li><li>WebUtility -> System.Net</li></ul> |
 | [System.Runtime.CompilerServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.CompilerServices)   | [@AlexGhiondea](https://github.com/AlexGhiondea), [@joperezr](https://github.com/dotnet/joperezr) |  |
-| [System.Runtime.Extensions](https://github.com/dotnet/corefx/labels/area-System.Runtime.Extensions)   | [@AlexGhiondea](https://github.com/AlexGhiondea), [@joperezr](https://github.com/dotnet/joperezr) | **Pending triage** |
+| [System.Runtime.Extensions](https://github.com/dotnet/corefx/labels/area-System.Runtime.Extensions)   | [@AlexGhiondea](https://github.com/AlexGhiondea), [@joperezr](https://github.com/dotnet/joperezr) | **Triage in progress** |
 | [System.Runtime.InteropServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.InteropServices) | [@tijoytom](https://github.com/tijoytom), [@yizhang82](https://github.com/yizhang82) | Excluded:<ul><li>System.Runtime.InteropServices.RuntimeInfo</li></ul> |
 | [System.Security](https://github.com/dotnet/corefx/labels/area-System.Security)               | [@bartonjs](https://github.com/bartonjs), [@steveharter](https://github.com/steveharter) |  |
 | System.ServiceModel                                                                           | N/A | [dotnet/wcf](https://github.com/dotnet/wcf) |
 | [System.ServiceProcess](https://github.com/dotnet/corefx/labels/area-System.ServiceProcess)   | [@Priya91](https://github.com/Priya91) |  |
-| [System.Text.Encoding](https://github.com/dotnet/corefx/labels/area-System.Text.Encoding)     | [@krwq](https://github.com/krwq), [@tarekgh](https://github.com/tarekgh) |  |
+| [System.Text.Encoding](https://github.com/dotnet/corefx/labels/area-System.Text.Encoding)     | [@krwq](https://github.com/krwq), [@tarekgh](https://github.com/tarekgh) | Included:<ul><li>System.Text.Encoding**s**.Web</li></ul> |
 | [System.Text.RegularExpressions](https://github.com/dotnet/corefx/labels/area-System.Text.RegularExpressions) | [@Priya91](https://github.com/Priya91) |  |
 | [System.Threading](https://github.com/dotnet/corefx/labels/area-System.Threading)             | [@kouvel](https://github.com/kouvel), [@alexperovich](https://github.com/alexperovich) |  |
 | [System.Transactions](https://github.com/dotnet/corefx/labels/area-System.Transactions)       | [@jimcarley](https://github.com/jimcarley), [@qizhanMS](https://github.com/qizhanMS), [@dmetzgar](https://github.com/dmetzgar) |  |
@@ -101,9 +102,15 @@ Note: Area triage will apply the new scheme (issue types and assignee) throughou
 ### Triage rules - simplified
 
 1. Each issue has exactly one **area-&#42;** label
+    * Motivation: Issues with multiple areas have loose responbility (everyone blames the other side) and issues are double counted in reports.
 1. Issue has no **Assignee**, unless someone is working on the issue at the moment
+    * Motivation: Observation is that contributors are less likely to grab assigned issues, no matter what the repo rules say.
 1. Use **up for grabs** as much as possible, ideally with a quick note about next steps / complexity of the issue
 1. Set milestone to **Future**, unless you can 95%-commit you can fund the issue in specific milestone
-1. Each issue has exactly one "*issue type*" label (**bug**, **enhancement**, **api-needs-work**, **test bug**, etc.)
+    * Motivation: Helps communicate desire/timeline to community. Can spark further priority/impact discussion.
+1. Each issue has exactly one "*issue type*" label (**bug**, **enhancement**, **api-needs-work**, **test bug**, **test enhancement**, **question**, **documentation**, etc.)
+    * Don't be afraid to be wrong when deciding 'bug' vs. 'test bug' (flip a coin if you must). The most useful values for tracking are 'api-&#42;' vs. 'enhancement', 'question', and 'documentation'.
 1. Don't be afraid to say no, or close issues - just explain why and be polite
 1. Don't be afraid to be wrong - just be flexible when new information appears
+
+Feel free to use other labels if it helps your triage efforts (e.g. **needs more info**, **Design Discussion**, **blocked**, **blocking-partner**, **tenet-performance**, **tenet-compatibility**, **os-linux**/**os-windows**/**os-mac-os-x**/**os-unsupported**, **os-windows-uwp**/**os-windows-wsl**, **arm32**/**arm64**)

external/corefx/Documentation/project-docs/performance-tests.md

@@ -22,7 +22,7 @@ Running the tests
 ### Windows
 Performance test files (if present) are stored within a library's ```tests/Performance``` directory and contain test methods that are all marked with a perf-specific *Benchmark* attribute. The performance tests will only be run if the ```performance``` property is set to ```true```.
 
-To build and run the tests using msbuild for a project, run ```msbuild /t:BuildAndTest /p:Performance=true /p:ConfigurationGroup=Release /p:OSGroup=Windows_NT``` from the tests directory. If the v5.0 assemblies aren't installed on your system, an error will be raised and no tests will be run.
+To build and run the tests using msbuild for a project, run ```msbuild /t:BuildAndTest /p:Performance=true /p:ConfigurationGroup=Release /p:TargetOS=Windows_NT``` from the tests directory. If the v5.0 assemblies aren't installed on your system, an error will be raised and no tests will be run.
 
 Note: Because build.cmd runs tests concurrently, it's not recommended that you execute the perf tests using it.