mono/linux-packaging-mono
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Imported Upstream version 5.10.0.69

Browse Source 
Former-commit-id: fc39669a0b707dd3c063977486506b6793da2890
This commit is contained in:
Xamarin Public Jenkins (auto-signing)
2018-01-29 19:03:06 +00:00
parent d8f8abd549
commit e2950ec768
6283 changed files with 453847 additions and 91879 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
external/corefx/Documentation/api-guidelines/README.md vendored Normal file
View File

@@ -0,0 +1,13 @@
# API Design Guidelines
The guidelines in this folder represent work in progress API design guidelines.
The official guidelines can be found in the [documentation][docs] and as an
actual [book].
## Process
To submit new proposals for design guidelines, simply create a PR adding or
modifying an existing file.
[docs]: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/
[book]: https://amazon.com/dp/0321545613

54
external/corefx/Documentation/api-guidelines/System.Memory.md vendored Normal file
View File

@@ -0,0 +1,54 @@
# System.Memory Design Guidelines
`System.Memory` is a collection of types and features that make working with
buffers and raw memory more efficient while remaining type safe. The feature
specs can be found here:
* [`Span<T>`](https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md)
* [`Memory<T>`](https://github.com/dotnet/corefxlab/blob/master/docs/specs/memory.md)
## Overview
* `ReadOnlySpan<T>` is effectively the universal receiver, in that `T[]`, `T*`,
`Memory<T>`, `ReadOnlyMemory<T>`, `Span<T>`, `ArraySegment<T>` can all be
converted to it. So if you can declare your API to accept a `ReadOnlySpan<T>`
and behave efficiently, that's best, as any of these inputs can be used with
your method.
* Similarly for `Span<T>`, if you need write access in the implementation.
* It allows building safe public APIs that can operate on unmanaged memory
without forcing all consumers to use pointers (and thus becoming unsafe). The
implementation can still extract a raw pointer, therefore getting equivalent
performance if necessary.
* It's generally best for a synchronous method to accept `Span<T>` or
`ReadOnlySpan<T>`. However, since `ReadOnlySpan<T>`/`Span<T>` are stack-only
[1], this may be too limiting for the implementation. In particular, if the
implementation needs to be able to store the argument for later usage, such as
with an asynchronous method or an iterator, `ReadOnlySpan<T>`/`Span<T>` is
inappropriate. `ReadOnlyMemory<T>`/`Memory<T>` should be used in such
situations.
[1] *stack-only* isn't the best way to put it. Strictly speaking, these types
are called `ref`-like types. These types must be structs, cannot be fields
in classes, cannot be boxed, and cannot be used to instantiate generic
types. Value types containing fields of `ref`-like types must themselves be
`ref`-like types.
## Guidance
* **DO NOT** use pointers for methods operating on buffers. Instead, use
appropriate type from below. In performance critical code where bounds
checking is unacceptable, the method's implementation can still pin the span
and get the raw pointer if necessary. The key is that you don't spread the
pointer through the public API.
- Synchronous, read-only access needed: `ReadOnlySpan<T>`
- Synchronous, writable access needed: `Span<T>`
- Asynchronous, read-only access needed: `ReadOnlyMemory<T>`
- Asynchronous, writable access needed: `Memory<T>`
* **CONSIDER** using `stackalloc` with `Span<T>` when you need small temporary
storage but you need to avoid allocations and associated life-time management.
* **AVOID** providing overloads for both `ReadOnlySpan<T>` and `Span<T>` as `Span<T>`
can be implicitly converted to `ReadOnlySpan<T>`.
* **AVOID** providing overloads for both `ReadOnlySpan<T>`/`Span<T>` as well as
pointers and arrays as those can be implicitly converted to
`ReadOnlySpan<T>`/`Span<T>`.

34
external/corefx/Documentation/architecture/globalization-invariant-mode.md vendored
View File

@@ -98,18 +98,32 @@ When running on Linux, ICU is used to get the time zone display name. In invaria
## Enabling the invariant mode
Applications can enable the invariant mode by setting the config switch System.Globalization.Invariant to true, in the `runtimeconfig.json` file, as you can see in the following example:
Applications can enable the invariant mode by either of the following:
```json
{
"runtimeOptions": {
"configProperties": {
"System.Globalization.Invariant": true
},
1. in project file:
```xml
<ItemGroup>
<RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" />
</ItemGroup>
```
2. in `runtimeconfig.json` file:
```json
{
"runtimeOptions": {
"configProperties": {
"System.Globalization.Invariant": true
}
}
}
}
```
```
3. setting environment variable value `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT` to `true` or `1`.
Note: value set in project file or `runtimeconfig.json` has higher priority than the environment variable.
## APP behavior with and without the invariant config switch
- If the invariant config switch is not set or it is set false

68
external/corefx/Documentation/building/advanced-inner-loop-testing.md vendored Normal file
View File

@@ -0,0 +1,68 @@
# Advanced scenario - Build and run application code with csc/vbc and CoreRun
__Don't consider using this tutorial for anything else than inner-loop testing of corefx/coreclr binaries. Prefer using the official .NET Core SDK: https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=netcore2x__
This tutorial describes how to build and run application code that targets self-compiled .NET Core binaries without using Visual Studio, the .NET Core SDK Host (`dotnet.exe`) or a project file (e.g. `csproj`). Follow these steps to quickly validate changes you've made in the product e.g. by running benchmarks or tests on it.
If you are on Windows you currently need to use the `Developer Command Prompt for VS 2017` to build corefx/coreclr! For the sake of completeness, we have placed our repositories under `d:\git\`.
## Compile corefx with self-compiled coreclr binaries
If you've made changes to coreclr make sure to also build it and pass its binaries to corefx.
```
coreclr\build -release
corefx\build -release -- /p:CoreCLROverridePath=d:\git\coreclr\bin\Product\Windows_NT.x64.Release\
```
## Compile corefx with pre-compiled coreclr binaries
If you haven't made any changes to coreclr you're fine with just building corefx. This automatically picks pre-compiled coreclr binaries from MyGet.
```
corefx\build -release
```
## Create and prepare your application
We will build a sample application which outputs `Hello World!` to the console.
1. Create an application directory (in our example under `d:\git\`):
```
mkdir core-demo
cd core-demo
```
2. Save the following C# code to a file called `Program.cs` into your application folder:
```csharp
using System;
public class Program
{
public static void Main()
{
Console.WriteLine("Hello World!");
}
}
```
3. Copy the just built corefx assemblies into your application directory. When using Visual Studio or the .NET Core SDK Host (`dotnet.exe`) you usually compile against *reference assemblies*. For simplicity we compile against the same assembly set that we use during run time.
```
xcopy ..\corefx\bin\testhost\netcoreapp-Windows_NT-Release-x64\shared\Microsoft.NETCore.App\9.9.9 runtime /e /i /y /s
```
You don't need all the assemblies that are built by corefx but copying the entire directory makes it easier if you want to reference additional ones. At a minimum, this app will need the following assemblies to run:
- CoreClr assemblies: `clrjit.dll`, `CoreRun.exe`, `coreclr.dll`, `System.Private.CoreLib.dll`. For more information about the CoreClr parts, visit [Using your build](https://github.com/dotnet/coreclr/blob/master/Documentation/workflow/UsingYourBuild.md)
- CoreFx assemblies: `System.Runtime.dll`, `System.Runtime.Extensions.dll`, `System.Runtime.InteropServices.dll`, `System.Text.Encoding.Extensions.dll`, `System.Threading.dll`
## Compile your application
Use the C# Compiler (`csc`) to compile your C# code (`Program.cs`) against the copied assemblies. For our Hello World example we need to compile our application code against `System.Private.Corelib.dll`, `System.Runtime.dll`, `System.Runtime.Extensions.dll` and `System.Console.dll`. As described above these assemblies have dependencies on two other assemblies: `System.Text.Encoding.Extensions.dll` and `System.Threading.dll`.
```
.\runtime\corerun ..\corefx\tools\csc.dll /noconfig /r:runtime\System.Private.Corelib.dll /r:runtime\System.Runtime.dll /r:runtime\System.Runtime.Extensions.dll /r:runtime\System.Console.dll /out:runtime\Program.dll Program.cs
```
If you want to compile Visual Basic code simply replace `csc.dll` with `vbc.dll`.
## Run your application
`Corerun.exe` is part of the coreclr binaries and is best described as the host of your .NET Core application. Find more information at [Using CoreRun](https://github.com/dotnet/coreclr/blob/master/Documentation/workflow/UsingCoreRun.md).
```
cd runtime
.\corerun Program.dll
```
> Hello World!

3
external/corefx/Documentation/building/code-coverage.md vendored
View File

@@ -78,4 +78,7 @@ Some of the libraries for which contracts and tests live in the corefx repo are
1. Follow the steps outlined at [Testing with Private CoreClr Bits](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/developer-guide.md#testing-with-private-coreclr-bits). Make sure to include the optional steps listed as being required for code coverage.
2. Add /p:CodeCoverageAssemblies="System.Private.CoreLib" to the previously discussed msbuild command, e.g. msbuild /t:BuildAndTest /p:Coverage=true /p:CodeCoverageAssemblies="System.Private.CoreLib"
Note that you will also want to copy the System.Private.CoreLib.pdb along with the System.Private.CoreLib.dll. As of 10/2017 this PDB must be a windows PDB (Hopefully by early 2018 OpenCOver will directly support portable PDBs.
You can determine if it is a windows PDB by doing 'more System.Private.CoreLib.pdb. If it begins with 'Microsoft C/C++ MSF 7.00' it is a windows PDB) If you need a windows PDB the Pdb2Pdb tool will convert (or you can do a msbuild /t:rebuild /p:DebugType=full in the src\mscorlib)
The resulting code coverage report should now also include details for System.Private.CoreLib.

4
external/corefx/Documentation/building/unix-instructions.md vendored
View File

@@ -19,6 +19,10 @@ For more information about the different options when building, run `build.sh -?
### Linux
First, the package lists might need to be updated
`sudo apt-get update`
#### Native build
For Ubuntu 14.04, the following packages should be installed to build the native

16
external/corefx/Documentation/coding-guidelines/project-guidelines.md vendored
View File

@@ -88,6 +88,22 @@ All supported targets with unique windows/unix build for netcoreapp:
<PropertyGroup>
```
### Placeholder build configurations
Placeholder build configurations can be added to the `<BuildConfigurations>` property to indicate the build system that the specific project is inbox in that framework and that build configuration needs to be ignored.
Placeholder build configurations start with _ prefix.
Example:
When we have a project that has a `netstandard` build configuration that means that this project is compatible with any build configuration. So if we do a vertical build for `netfx` this project will be built as part of the vertical because `netfx` is compatible with `netstandard`. This means that in the runtime and testhost binaries the netstandard implementation will be included, and we will test against those assets instead of testing against the framework inbox asset. In order to tell the build system to not include this project as part of the `netfx` vertical we need to add a placeholder configuration:
```
<PropertyGroup>
<BuildConfigurations>
netstandard;
_netfx;
</BuildConfigurations>
</PropertyGroup>
```
## Options for building
A full or individual project build is centered around BuildConfiguration and will be setup in one of the following ways:

49
external/corefx/Documentation/debugging/unix-instructions.md vendored
View File

@@ -6,40 +6,61 @@ CoreFX can be debugged on unix using both lldb and visual studio code
## Using lldb and SOS
- Run the test using msbuild at least once with `/t:BuildAndTest`.
- Install version 3.9 of lldb and launch lldb with dotnet as the process and arguments matching the arguments used when running the test through msbuild.
- [Install version 3.9 of lldb](https://github.com/dotnet/coreclr/blob/master/Documentation/building/debugging-instructions.md#debugging-core-dumps-with-lldb) and launch lldb with dotnet as the process and arguments matching the arguments used when running the test through msbuild.
- Load the sos plugin using `plugin load libsosplugin.so`.
- Type `soshelp` to get help. You can now use all sos commands like `bpmd`.
You may need to supply a path to load SOS. It can be found next to libcoreclr.so. For example:
```
(lldb) plugin load libsosplugin.so
error: no such file
(lldb) image list libcoreclr.so
[ 0] ..... /home/dan/dotnet/shared/Microsoft.NETCoreApp/2.0.4/libcoreclr.so
(lldb) plugin load /home/dan/dotnet/shared/Microsoft.NETCoreApp/2.0.4/libcoreclr.so
```
## Debugging core dumps with lldb
It is also possible to debug .NET Core crash dumps using lldb and SOS. In order to do this, you need all of the following:
- A machine whose environment matches the one used to produce the crash dumps. For crash dumps occurring on CI machines, you can either
- Log onto a matching machine in the pool.
- Create a new VM from the matching image.
- You will find the dump url to download the crash dump file in the test logs, something similar to:
<pre>
2017-10-10 21:17:48,020: INFO: proc(54): run_and_log_output: Output: dumplingid: eefcb1cc36977ccf86f457ee28a33a7b4cc24e13
2017-10-10 21:17:48,020: INFO: proc(54): run_and_log_output: Output: <b>https://dumpling.azurewebsites.net/api/dumplings/archived/eefcb1cc36977ccf86f457ee28a33a7b4cc24e13</b>
</pre>
- The crash dump file. We have a service called "Dumpling" which collects, uploads, and archives crash dump files during all of our CI jobs and official builds.
- Matching runtime bits from the crash. To get these, you should either:
- On Linux, there is an utility called `createdump` (see [doc](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md "doc")) that can be setup to generate core dumps when a managed app throws an unhandled exception or faults.
- Matching coreclr/corefx runtime bits from the crash. To get these, you should either:
- Download the matching Jenkins archive onto your repro machine.
- Check out the corefx repository at the appropriate commit and re-build the necessary portions.
- lldb version 3.9.
- libsosplugin.so built against a matching version of lldb. The official libsosplugin.so is now built against 3.9.
- Symbols for libcoreclr.so. libcoreclr.so.dbg should be copied to your "runtime" folder. To get this file, you can:
- Build coreclr at the matching commit. In order to determine which commit was used to build a version of libcoreclr.so, run the following command:
`strings libcoreclr.so | grep "@(#)"`
- You can also download the matching "symbols" nuget package from myget.org. You want the same package version that is used to build corefx. There is a "Download Symbols" button in the myget UI for this purpose.
- Check out the coreclr and corefx repositories at the appropriate commit and re-build the necessary portions.
- You can also download the matching "symbols" nuget package from myget.org. There is a "Download Symbols" button in the myget UI for this purpose.
- lldb version 3.9. The SOS plugin (i.e. libsosplugin.so) provided is now built for lldb 3.9. In order to install lldb 3.9 just run the following commands:
```
~$ echo "deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.9 main" | sudo tee /etc/apt/sources.list.d/llvm.list
~$ wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key | sudo apt-key add -
~$ sudo apt-get update
~$ sudo apt-get install lldb-3.9
```
Once you have everything listed above, you are ready to start debugging. You need to specify an extra parameter to lldb in order for it to correctly resolve the symbols for libcoreclr.so. Use a command like this:
```
lldb -O "settings set target.exec-search-paths <runtime-path>" --core <core-file-path> <dotnet-path>
lldb-3.9 -O "settings set target.exec-search-paths <runtime-path>" -o "plugin load <path-to-libsosplugin.so>" --core <core-file-path> <host-path>
```
- `<runtime-path>`: The path containing libcoreclr.so.dbg, as well as the rest of the runtime and framework assemblies.
- `<core-file-path>`: The path to the core dump you are attempting to debug.
- `<dotnet-path>`: The path to the dotnet executable, potentially in the `<runtime-path>` folder.
- `<host-path>`: The path to the dotnet or corerun executable, potentially in the `<runtime-path>` folder.
- `<path-to-libsosplugin.so>`: The path to libsosplugin.so, should be in the `<runtime-path>` folder.
lldb should start debugging successfully at this point. You should see stacktraces with resolved symbols for libcoreclr.so. At this point, you can run `plugin load <libsosplugin.so-path>`, and begin using SOS commands, as above.
##### Example
```
lldb-3.9 -O "settings set target.exec-search-paths /home/parallels/Downloads/System.Drawing.Common.Tests/home/helixbot/dotnetbuild/work/2a74cf82-3018-4e08-9e9a-744bb492869e/Payload/shared/Microsoft.NETCore.App/9.9.9/" -o "plugin load /home/parallels/Downloads/System.Drawing.Common.Tests/home/helixbot/dotnetbuild/work/2a74cf82-3018-4e08-9e9a-744bb492869e/Payload/shared/Microsoft.NETCore.App/9.9.9/libsosplugin.so" --core /home/parallels/Downloads/System.Drawing.Common.Tests/home/helixbot/dotnetbuild/work/2a74cf82-3018-4e08-9e9a-744bb492869e/Work/f6414a62-9b41-4144-baed-756321e3e075/Unzip/core /home/parallels/Downloads/System.Drawing.Common.Tests/home/helixbot/dotnetbuild/work/2a74cf82-3018-4e08-9e9a-744bb492869e/Payload/shared/Microsoft.NETCore.App/9.9.9/dotnet
```
## Using Visual Studio Code
- Install [Visual Studio Code](https://code.visualstudio.com/)

146
external/corefx/Documentation/project-docs/benchmarking.md vendored Normal file
View File

@@ -0,0 +1,146 @@
# Benchmarking .NET Core 2.0 / 2.1 applications
We recommend using [BenchmarkDotNet](https://github.com/dotnet/BenchmarkDotNet) as it allows specifying custom SDK paths and measuring performance not just in-proc but also out-of-proc as a dedicated executable.
```
<ItemGroup>
<PackageReference Include="BenchmarkDotNet" Version="0.10.11" />
</ItemGroup>
```
## Defining your benchmark
See [BenchmarkDotNet](http://benchmarkdotnet.org/Guides/GettingStarted.htm) documentation -- minimally you need to adorn a public method with the `[Benchmark]` attribute but there are many other ways to customize what is done such as using parameter sets or setup/cleanup methods. Of course, you'll want to bracket just the relevant code in your benchmark, ensure there are sufficient iterations that you minimise noise, as well as leaving the machine otherwise idle while you measure.
# Benchmarking .NET Core 2.0 applications
For benchmarking .NET Core 2.0 applications you only need the .NET Core 2.0 SDK installed: https://www.microsoft.com/net/download/windows. Make sure that your `TargetFramework` property in your csproj is set to `netcoreapp2.0` and follow the official BenchmarkDotNet instructions: http://benchmarkdotnet.org.
# Benchmarking .NET Core 2.1 applications
Make sure to download the .NET Core 2.1 SDK zip archive (https://github.com/dotnet/core-setup#daily-builds) and extract it somewhere locally, e.g.: `C:\dotnet-nightly\`.
For the sake of this tutorial we won't modify the `PATH` variable and instead always explicitly call the `dotnet.exe` from the downloaded SDK folder.
The shared framework is a set of assemblies that are packed into a `netcoreapp` Nuget package which is used when you set your `TargetFramework` to `netcoreappX.X`. You can either decide to use your local self-compiled shared framework package or use the one which is bundled with the .NET Core 2.1 SDK.
## Alternative 1 - Using the shared framework from the .NET Core 2.1 SDK
Follow the instructions described here https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md#advanced-scenario---using-a-nightly-build-of-microsoftnetcoreapp and skip the last part which calls the `dotnet.exe` to run the application.
Add a benchmark class, configure it either with a manual configuration or by attributing it and pass the class type to the BenchmarkRunner:
```csharp
[MemoryDiagnoser]
// ...
public class Benchmark
{
// Benchmark code ...
}
public class Program
{
public static void Main()
{
BenchmarkRunner.Run<Benchmark>();
}
}
```
## Alternative 2 - Using your self-compiled shared framework
Follow the instructions described here https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md#more-advanced-scenario---using-your-local-corefx-build and skip the last part which calls the `dotnet.exe` to run the application.
Make sure to build your local corefx repository in RELEASE mode `.\build -release`! You currently need to have a self-contained application to inject your local shared framework package.
Currently there is no straightforward way to run your BenchmarkDotNet application in a dedicated process, therefore we are using the InProcess switch `[InProcess]`:
```csharp
[InProcess]
public class Benchmark
{
// Benchmark code ...
}
public class Program
{
public static void Main()
{
BenchmarkRunner.Run<Benchmark>();
}
}
```
# Benchmark multiple or custom .NET Core 2.x SDKs
Follow the instructions described here https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md#advanced-scenario---using-a-nightly-build-of-microsoftnetcoreapp and skip the last part which calls the `dotnet.exe` to run the application.
Whenever you want to benchmark an application simultaneously with one or multiple different .NET Core run time framework versions, you want to create a manual BenchmarkDotNet configuration file. Add the desired amount of Jobs and `NetCoreAppSettings` to specify the `targetFrameworkMoniker`, `runtimeFrameworkVersion` and `customDotNetCliPath`:
```csharp
using BenchmarkDotNet.Columns;
using BenchmarkDotNet.Configs;
using BenchmarkDotNet.Diagnosers;
using BenchmarkDotNet.Environments;
using BenchmarkDotNet.Exporters;
using BenchmarkDotNet.Jobs;
using BenchmarkDotNet.Loggers;
using BenchmarkDotNet.Toolchains.CsProj;
using BenchmarkDotNet.Toolchains.DotNetCli;
public class MainConfig : ManualConfig
{
public MainConfig()
{
// Job #1
Add(Job.Default
.With(Runtime.Core)
.With(CsProjCoreToolchain.From(new NetCoreAppSettings(
targetFrameworkMoniker: "netcoreapp2.1",
runtimeFrameworkVersion: "2.1.0-preview1-25919-02", // <-- Adjust version here
customDotNetCliPath: @"C:\dotnet-nightly\dotnet.exe", // <-- Adjust path here
name: "Core 2.1.0-preview"))));
// Job #2 which could be in-process (see Alternative #2)
// ...
// Job #3 which could be .NET Core 2.0
// ...
// Add whatever jobs you need
Add(DefaultColumnProviders.Instance);
Add(MarkdownExporter.GitHub);
Add(new ConsoleLogger());
Add(new HtmlExporter());
Add(MemoryDiagnoser.Default);
}
}
```
In your application entry point pass the configuration to the BenchmarkRunner:
```csharp
public class Benchmark
{
// Benchmark code ...
}
public class Program
{
public static void Main()
{
BenchmarkRunner.Run<Benchmark>(new MainConfig());
}
}
```
# Running the benchmark
To get valid results make sure to run your project in RELEASE configuration:
```
cd "path/to/your/benchmark/project"
"C:\dotnet-nightly\dotnet.exe" run -c Release
```
# Reporting results
Often in a Github Pull Request or issue you will want to share performance results to justify a change. If you add the `MarkdownExporter` job in the configuration (as you can see in Alternative 3), BenchmarkDotNet will have created a Markdown (*.md) file in the `BenchmarkDotNet.Artifacts` folder which you can paste in, along with the code you benchmarked.
# References
- [BenchmarkDotNet](http://benchmarkdotnet.org/)
- [BenchmarkDotNet Github](https://github.com/dotnet/BenchmarkDotNet)
- [.NET Core SDK](https://github.com/dotnet/core-setup)

173
external/corefx/Documentation/project-docs/dogfooding.md vendored
View File

@@ -1,32 +1,54 @@
# How to get up and running on .NET Core 2.0
# How to get up and running on .NET Core
This document provides the steps necessary to consume a nightly build of
.NET Core 2.0 runtime and SDK.
.NET Core runtime and SDK.
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. Acquire the latest nightly .NET Core SDK 2.0
1. Acquire the latest nightly .NET Core SDK by downloading the zip or tarball listed in https://github.com/dotnet/cli/blob/master/README.md#installers-and-binaries (for example, https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-win-x64.zip ) into a new folder.
- [Win 64-bit Latest Zip](https://dotnetcli.azureedge.net/dotnet/Sdk/master/dotnet-dev-win-x64.latest.zip) [Installer](https://dotnetcli.azureedge.net/dotnet/Sdk/master/dotnet-dev-win-x64.latest.exe)
- [macOS 64-bit Latest Tar](https://dotnetcli.azureedge.net/dotnet/Sdk/master/dotnet-dev-osx-x64.latest.tar.gz) [Installer](https://dotnetcli.azureedge.net/dotnet/Sdk/master/dotnet-dev-osx-x64.latest.pkg)
- [Others](https://github.com/dotnet/cli/blob/master/README.md#installers-and-binaries)
2. By default, the dotnet CLI will use the globally installed SDK if it matches the major/minor version you request and has a higher revision. To force it to use the locally installed SDK, you must set an environment variable `DOTNET_MULTILEVEL_LOOKUP=0` in your shell. You can use `dotnet --info` to verify what version of the Shared Framework it is using.
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.
3. Reminder: if you are using a local copy of the dotnet CLI, take care that when you type `dotnet` you do not inadvertently pick up a different copy that you may have in your path. On Windows, for example, if you use a Developer Command Prompt, a global copy may be in the path, so use the fully qualified path to your local `dotnet`. If you receive an error "The current .NET SDK does not support targeting .NET Core 2.1." then you may be executing an older `dotnet`.
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 executing `dotnet --info` -- the version should be greater than 2.2.0-* (dotnet CLI is currently numbered 2.2.0-* not 2.1.0-* ). Here is an example output at the time of writing:
```
>dotnet.exe --info
.NET Command Line Tools (2.2.0-preview1-007460)
After setting up dotnet you can verify you are using the newer version by:
Product Information:
Version: 2.2.0-preview1-007460
Commit SHA-1 hash: 173cc035e4
`dotnet --info` -- the version should be greater than 2.0.0-*
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: F:\dotnet\sdk\2.2.0-preview1-007460\
Microsoft .NET Core Shared Framework Host
Version : 2.1.0-preview1-25825-07
Build : 4c165c13bd390adf66f9af30a088d634d3f37a9d
```
4. Our nightly builds are uploaded to MyGet, not NuGet - so ensure the .NET Core MyGet feed is in your nuget configuration in case you need other packages from .NET Core that aren't included in the download. For example, on Windows you could edit `%userprofile%\appdata\roaming\nuget\nuget.config` or on Linux edit `~/.nuget/NuGet/NuGet.Config` to add this line:
```xml
<packageSources>
<add key="myget.dotnetcore" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
...
</packageSources>
```
(Documentation for configuring feeds is [here](https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior).)
## Setup the project
1. Create a new project
- Create a new folder for your app
- Create a new folder for your app and change to that folder
- Create project file by running `dotnet new console`
2. Restore packages so that you're ready to play:
@@ -37,25 +59,6 @@ $ dotnet restore
## Consume the new build
Edit your `Program.cs` to consume the new APIs, for example:
```CSharp
using System;
using System.Net;
class Program
{
static void Main(string[] args)
{
WebUtility.HtmlDecode("&amp;", Console.Out);
Console.WriteLine();
Console.WriteLine("Hello World!");
}
}
```
Run the bits:
```
$ dotnet run
```
@@ -65,7 +68,7 @@ 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
.NET Core 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.
@@ -84,8 +87,8 @@ runtime.
```XML
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeFrameworkVersion>2.0.0-beta-xyz-00</RuntimeFrameworkVersion> <!-- this line -->
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeFrameworkVersion>2.1.0-preview1-25825-07</RuntimeFrameworkVersion> <!-- modify build in this line -->
</PropertyGroup>
```
@@ -105,19 +108,21 @@ 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 -->
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeFrameworkVersion>2.1.0-preview1-25825-07</RuntimeFrameworkVersion> <!-- modify build in this line -->
<RuntimeIdentifier>win-x64</RuntimeIdentifier> <!-- make self-contained -->
</PropertyGroup>
```
```
$ dotnet restore
$ dotnet publish
$ bin\Debug\netcoreapp2.0\win7-x64\publish\App.exe
$ bin\Debug\netcoreapp2.1\win-x64\publish\App.exe
```
## Using your local CoreFx build
## More Advanced Scenario - Using your local CoreFx build
If you built corefx locally with `build -allconfigurations` after building binaries it will build NuGet packages containing them. You can use those in your projects.
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,
@@ -127,11 +132,11 @@ and run a self-contained application you need the following steps to consume you
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:
Once you find the version number (for this example assume it is `4.5.0-preview1-25830-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" />
<PackageReference Include="Microsoft.Private.CoreFx.NETCoreApp" Version="4.5.0-preview1-25830-0" />
</ItemGroup>
```
@@ -146,25 +151,26 @@ you need to tell the tooling to use the assets from your local package. To do th
Replacing the RID in `runtime.win-x64.Microsoft.Private.CoreFx.NETCoreApp` with the RID of your current build.
Note these 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 that package instead of "Microsoft.Private.CoreFx.NETCoreApp".
#### 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:
as a reference to our nightly dotnet-core feed on myget. The Nuget.Config file content should be:
```xml
<configuration>
<packageSources>
<add key="local coreclr" value="D:\git\corefx\bin\packages\Debug" />
<add key="local coreclr" value="D:\git\corefx\bin\packages\Debug" /> <!-- Change this to your own output path -->
<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**.
Be sure to correct the path to your build output above.
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.
You also have the alternative of modifying the Nuget.Config
at `%HOMEPATH%\AppData\Roaming\Nuget\Nuget.Config` (Windows) or `~/.nuget/NuGet/NuGet.Config` (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
@@ -178,9 +184,15 @@ dotnet publish
```
Now your publication directory should contain your local built CoreFx binaries.
#### 3 - Consuming updated packages
#### 3 - Consuming subsequent code changes by overwriting the binary (Alternative 1)
One possible problem with the technique above is that Nuget assumes that distinct builds have distinct version numbers.
To apply changes you subsequently make in your source tree, it's usually easiest to just overwrite the binary in the publish folder. Build the assembly containing your change as normal, then overwrite the assembly in your publish folder and running the app will pick up that binary. This relies on the fact that all the other binaries still match what is in your bin folder so everything works together.
#### 3 - Consuming subsequent code changes by rebuilding the package (Alternative 2)
This is more cumbersome than just overwriting the binaries, but is more correct.
First note 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
@@ -188,66 +200,13 @@ 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).
before packaging. You should see this number show up in the version number (e.g. 4.5.0-preview1-25830-03).
As an alternative you can delete the existing copy of the package from the Nuget cache. For example on
Alternatively just 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
%HOMEPATH%\.nuget\packages\Microsoft.Private.CoreFx.NETCoreApp\4.5.0-preview1-25830-0
%HOMEPATH%\.nuget\packages\runtime.win-x64.microsoft.private.corefx.netcoreapp\4.5.0-preview1-25830-0
```
which should make things work (but is fragile, confirm file timestamps that you are getting the version you expect)
which should make `dotnet restore` now pick up the new copy.
### 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.
## Finding specific builds
The URL scheme for the runtime is as follows:
```
https://dotnetcli.azureedge.net/dotnet/master/Installers/$version$/dotnet-$os$-$arch$.$version$.exe
https://dotnetcli.azureedge.net/dotnet/master/Installers/2.0.0-preview1-001915-00/dotnet-win-x64.2.0.0-preview1-001915-00.exe
```
The URL scheme for the SDK & CLI is as follows:
```
https://dotnetcli.azureedge.net/dotnet/Sdk/$version$/dotnet-dev-$os$-$arch.$version$.exe
https://dotnetcli.azureedge.net/dotnet/Sdk/2.0.0-preview1-005791/dotnet-dev-win-x86.2.0.0-preview1-005791.exe
```

30
external/corefx/Documentation/project-docs/issue-guide.md vendored
View File

@@ -44,7 +44,7 @@ Areas are tracked by labels area-&#42; (e.g. area-System.Collections). Each area
|-----------------------------------------------------------------------------------------------|------------------|-------------|
| [area-Infrastructure](https://github.com/dotnet/corefx/labels/area-Infrastructure) | [@weshaggard](https://github.com/weshaggard), [@ericstj](https://github.com/ericstj) |Covers:<ul><li>Packaging</li><li>Build and test infra for CoreFX repo</li><li>VS integration</li></ul><br/> |
| [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/> |
| [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.XmlSerializer</li></ul> Excluded:<ul><li>System.Runtime.Serialization.Formatters</li></ul> |
| [area-Serialization](https://github.com/dotnet/corefx/labels/area-Serialization) | [@huanwu](https://github.com/huanwu), [@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.XmlSerializer</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) | [@safern](https://github.com/safern) | |
@@ -52,14 +52,14 @@ Areas are tracked by labels area-&#42; (e.g. area-System.Collections). Each area
| [System.Collections](https://github.com/dotnet/corefx/labels/area-System.Collections) |**[@safern](https://github.com/safern)**, [@ianhays](https://github.com/ianhays) | </ul>Excluded:<ul><li>System.Array -> System.Runtime</li></ul> |
| [System.ComponentModel](https://github.com/dotnet/corefx/labels/area-System.ComponentModel) | **[@maryamariyan](https://github.com/maryamariyan)**, [@safern](https://github.com/safern) | |
| [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) | |
| [System.Composition](https://github.com/dotnet/corefx/labels/area-System.Composition) | [@ViktorHofer](https://github.com/ViktorHofer) | |
| [System.Composition](https://github.com/dotnet/corefx/labels/area-System.Composition) | **[@maryamariyan](https://github.com/maryamariyan)**, [@ViktorHofer](https://github.com/ViktorHofer) | |
| [System.Configuration](https://github.com/dotnet/corefx/labels/area-System.Configuration) | [@maryamariyan](https://github.com/maryamariyan) | |
| [System.Console](https://github.com/dotnet/corefx/labels/area-System.Console) | **[@joperezr](https://github.com/joperezr)**, [@ianhays](https://github.com/ianhays) | |
| [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), [@corivera](https://github.com/corivera) | |
| [System.Diagnostics](https://github.com/dotnet/corefx/labels/area-System.Diagnostics) | **[@joperezr](https://github.com/joperezr)**, [@wtgodbe](https://github.com/wtgodbe) | |
| [System.Diagnostics](https://github.com/dotnet/corefx/labels/area-System.Diagnostics) | **[@joperezr](https://github.com/joperezr)**, [@wtgodbe](https://github.com/wtgodbe) | <ul><li>System.Diagnostics.EventLog [@Anipik](https://github.com/Anipik)</li></ul> |
| [System.Diagnostics.Process](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Process) | **[@joperezr](https://github.com/joperezr)**, [@wtgodbe](https://github.com/wtgodbe) | |
| [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/> |
| [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 - [@adiaaida](https://github.com/adiaaida)</li><li>System.Diagnostics.Tracing</li><li>System.Diagnostics.TraceSource</li></ul><br/> |
| [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) | [@safern](https://github.com/safern) | |
| [System.Dynamic.Runtime](https://github.com/dotnet/corefx/labels/area-System.Dynamic.Runtime) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
@@ -68,34 +68,38 @@ Areas are tracked by labels area-&#42; (e.g. area-System.Collections). Each area
| [System.IO.Compression](https://github.com/dotnet/corefx/labels/area-System.IO.Compression) | **[@ViktorHofer](https://github.com/ViktorHofer)**, [@ianhays](https://github.com/ianhays) | |
| [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) | [@kouvel](https://github.com/kouvel) | |
| [System.Linq.Parallel](https://github.com/dotnet/corefx/labels/area-System.Linq.Parallel) | **[@tarekgh](https://github.com/tarekgh)**, [@kouvel](https://github.com/kouvel) | |
| [System.Management](https://github.com/dotnet/corefx/labels/area-System.Management) | **[@Anipik](https://github.com/Anipik)**, [@pjanotti](https://github.com/pjanotti) | WMI |
| [System.Memory](https://github.com/dotnet/corefx/labels/area-System.Memory) | [@KrzysztofCwalina](https://github.com/KrzysztofCwalina), [@ahsonkhan](https://github.com/ahsonkhan) | |
| [System.Net](https://github.com/dotnet/corefx/labels/area-System.Net) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | Included:<ul><li>System.Uri</li></ul> |
| [System.Net.Http](https://github.com/dotnet/corefx/labels/area-System.Net.Http) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | |
| [System.Net.Http.ManagedHandler](https://github.com/dotnet/corefx/labels/area-System.Net.Http.ManagedHandler) | [@geoffkizer](https://github.com/geoffkizer), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt), [@davidsh](https://github.com/davidsh) | |
| [System.Net.Security](https://github.com/dotnet/corefx/labels/area-System.Net.Security) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | |
| [System.Net.Sockets](https://github.com/dotnet/corefx/labels/area-System.Net.Sockets) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | |
| [System.Numerics](https://github.com/dotnet/corefx/labels/area-System.Numerics) | [@eerhardt](https://github.com/eerhardt), [@ViktorHofer](https://github.com/ViktorHofer) | |
| [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](https://github.com/dotnet/corefx/labels/area-System.Reflection) | [@AtsushiKan](https://github.com/AtsushiKan) | |
| [System.Reflection.Emit](https://github.com/dotnet/corefx/labels/area-System.Reflection.Emit) | [@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) | **[@krwq](https://github.com/krwq)**, [@tarekgh](https://github.com/tarekgh) | |
| [System.Runtime](https://github.com/dotnet/corefx/labels/area-System.Runtime) | **[@joperezr](https://github.com/joperezr)**, [@AlexGhiondea](https://github.com/AlexGhiondea) | 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>Uri -> System.Net</li><li>WebUtility -> System.Net</li></ul> |
| [System.Runtime.Caching](https://github.com/dotnet/corefx/labels/area-System.Runtime.Caching) | [@KKhurin](https://github.com/KKhurin), [@zhenlan](https://github.com/zhenlan) | |
| [System.Runtime.CompilerServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.CompilerServices) | **[@joperezr](https://github.com/joperezr)**, [@AlexGhiondea](https://github.com/AlexGhiondea) | |
| [System.Runtime.Extensions](https://github.com/dotnet/corefx/labels/area-System.Runtime.Extensions) | **[@joperezr](https://github.com/joperezr)**, [@AlexGhiondea](https://github.com/AlexGhiondea) | |
| [System.Runtime.InteropServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.InteropServices) | [@tijoytom](https://github.com/tijoytom), [@luqunl](https://github.com/luqunl) | Excluded:<ul><li>System.Runtime.InteropServices.RuntimeInfo</li></ul> |
| [System.Runtime.InteropServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.InteropServices) | [@luqunl](https://github.com/luqunl), [@shrah](https://github.com/shrah) | Excluded:<ul><li>System.Runtime.InteropServices.RuntimeInfo</li></ul> |
| [System.Runtime.Intrinsics](https://github.com/dotnet/corefx/labels/area-System.Runtime.Intrinsics) | [@eerhardt](https://github.com/eerhardt), [@CarolEidt](https://github.com/CarolEidt), [@RussKeldorph](https://github.com/RussKeldorph) | |
| [System.Security](https://github.com/dotnet/corefx/labels/area-System.Security) | [@bartonjs](https://github.com/bartonjs), [@ianhays](https://github.com/ianhays) | |
| System.ServiceModel | N/A | [dotnet/wcf](https://github.com/dotnet/wcf) (except System.ServiceModel.Syndication) |
| [System.ServiceModel.Syndication](https://github.com/dotnet/corefx/labels/area-System.ServiceModel.Syndication) | [@shmao](https://github.com/shmao), [@zhenlan](https://github.com/zhenlan) | |
| [System.ServiceProcess](https://github.com/dotnet/corefx/labels/area-System.ServiceProcess) | [@maryamariyan](https://github.com/maryamariyan) | |
| [System.ServiceModel.Syndication](https://github.com/dotnet/corefx/labels/area-System.ServiceModel.Syndication) | [@huanwu](https://github.com/huanwu), [@zhenlan](https://github.com/zhenlan) | |
| [System.ServiceProcess](https://github.com/dotnet/corefx/labels/area-System.ServiceProcess) | **[@maryamariyan](https://github.com/maryamariyan)**, [@Anipik](https://github.com/Anipik) | |
| [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) | **[@ViktorHofer](https://github.com/ViktorHofer)**, [@Priya91](https://github.com/Priya91) | |
| [System.Threading](https://github.com/dotnet/corefx/labels/area-System.Threading) | [@kouvel](https://github.com/kouvel) | |
| [System.Threading](https://github.com/dotnet/corefx/labels/area-System.Threading) | **[@kouvel](https://github.com/kouvel)**| |
| [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) | |
| [System.Xml](https://github.com/dotnet/corefx/labels/area-System.Xml) | **[@krwq](https://github.com/krwq)**, [@pjanotti](https://github.com/pjanotti) | |
| [System.Xml](https://github.com/dotnet/corefx/labels/area-System.Xml) | **[@krwq](https://github.com/krwq)**, [@pjanotti](https://github.com/pjanotti) | |
| **Microsoft contract assemblies** | | |
| [Microsoft.CSharp](https://github.com/dotnet/corefx/labels/area-Microsoft.CSharp) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
| [Microsoft.VisualBasic](https://github.com/dotnet/corefx/labels/area-Microsoft.VisualBasic) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
| [Microsoft.Win32](https://github.com/dotnet/corefx/labels/area-Microsoft.Win32) | [@maryamariyan](https://github.com/maryamariyan) | |
| [Microsoft.Win32](https://github.com/dotnet/corefx/labels/area-Microsoft.Win32) | **[@maryamariyan](https://github.com/maryamariyan)**, , [@Anipik](https://github.com/Anipik) | |
Note: Area triage will apply the new scheme (issue types and assignee) throughout 2016.