Imported Upstream version 5.0.0.42

Former-commit-id: fd56571888259555122d8a0f58c68838229cea2b

external/corefx/.editorconfig

@@ -0,0 +1,42 @@
+# editorconfig.org
+
+# top-most EditorConfig file
+root = true
+
+# Default settings:
+# A newline ending every file
+# Use 4 spaces as indentation
+[*]
+insert_final_newline = true
+indent_style = space
+indent_size = 4
+
+[project.json]
+indent_size = 2
+
+# C++ Files
+[*.{cpp,h,in}]
+curly_bracket_next_line = true
+indent_brace_style = Allman
+
+# Xml project files
+[*.{csproj,vcxproj,vcxproj.filters,proj,nativeproj,locproj}]
+indent_size = 2
+
+# Xml build files
+[*.builds]
+indent_size = 2
+
+# Xml files
+[*.{xml,stylecop,resx,ruleset}]
+indent_size = 2
+
+# Xml config files
+[*.{props,targets,config,nuspec}]
+indent_size = 2
+
+# Shell scripts
+[*.sh]
+end_of_line = lf
+[*.{cmd, bat}]
+end_of_line = crlf

external/corefx/.gitattributes

@@ -0,0 +1,67 @@
+###############################################################################
+# Set default behavior to automatically normalize line endings.
+###############################################################################
+* text=auto
+
+###############################################################################
+# Set default behavior for command prompt diff.
+#
+# This is need for earlier builds of msysgit that does not have it on by
+# default for csharp files.
+# Note: This is only used by command line
+###############################################################################
+#*.cs     diff=csharp
+
+###############################################################################
+# Set the merge driver for project and solution files
+#
+# Merging from the command prompt will add diff markers to the files if there
+# are conflicts (Merging from VS is not affected by the settings below, in VS
+# the diff markers are never inserted). Diff markers may cause the following 
+# file extensions to fail to load in VS. An alternative would be to treat
+# these files as binary and thus will always conflict and require user
+# intervention with every merge. To do so, just uncomment the entries below
+###############################################################################
+#*.sln       merge=binary
+#*.csproj    merge=binary
+#*.vbproj    merge=binary
+#*.vcxproj   merge=binary
+#*.vcproj    merge=binary
+#*.dbproj    merge=binary
+#*.fsproj    merge=binary
+#*.lsproj    merge=binary
+#*.wixproj   merge=binary
+#*.modelproj merge=binary
+#*.sqlproj   merge=binary
+#*.wwaproj   merge=binary
+
+###############################################################################
+# behavior for image files
+#
+# image files are treated as binary by default.
+###############################################################################
+#*.jpg   binary
+#*.png   binary
+#*.gif   binary
+
+###############################################################################
+# diff behavior for common document formats
+# 
+# Convert binary document formats to text before diffing them. This feature
+# is only available from the command line. Turn it on by uncommenting the 
+# entries below.
+###############################################################################
+#*.doc   diff=astextplain
+#*.DOC   diff=astextplain
+#*.docx  diff=astextplain
+#*.DOCX  diff=astextplain
+#*.dot   diff=astextplain
+#*.DOT   diff=astextplain
+#*.pdf   diff=astextplain
+#*.PDF   diff=astextplain
+#*.rtf   diff=astextplain
+#*.RTF   diff=astextplain
+
+# Force bash scripts to always use lf line endings so that if a repo is accessed
+# in Unix via a file share from Windows, the scripts will work.
+*.sh text eol=lf

external/corefx/.gitignore

@@ -0,0 +1,272 @@
+syntax: glob
+
+### VisualStudio ###
+
+# Tool Runtime Dir
+/[Tt]ools/
+
+# User-specific files
+*.suo
+*.user
+*.userosscache
+*.sln.docstates
+
+# Build results
+[Dd]ebug/
+[Dd]ebugPublic/
+[Rr]elease/
+[Rr]eleases/
+x64/
+x86/
+build/
+bld/
+[Bb]in/
+[Oo]bj/
+msbuild.log
+msbuild.err
+msbuild.wrn
+
+# Cross building rootfs
+cross/rootfs/
+# add x86 as it is ignored in 'Build results'
+!cross/x86
+
+# Visual Studio 2015
+.vs/
+
+# Visual Studio 2015 Pre-CTP6
+*.sln.ide
+*.ide/
+
+# MSTest test Results
+[Tt]est[Rr]esult*/
+[Bb]uild[Ll]og.*
+
+#NUNIT
+*.VisualState.xml
+TestResult.xml
+
+# Build Results of an ATL Project
+[Dd]ebugPS/
+[Rr]eleasePS/
+dlldata.c
+
+*_i.c
+*_p.c
+*_i.h
+*.ilk
+*.meta
+*.obj
+*.pch
+*.pdb
+*.pgc
+*.pgd
+*.rsp
+*.sbr
+*.tlb
+*.tli
+*.tlh
+*.tmp
+*.tmp_proj
+*.log
+*.vspscc
+*.vssscc
+.builds
+*.pidb
+*.svclog
+*.scc
+
+# Chutzpah Test files
+_Chutzpah*
+
+# Visual C++ cache files
+ipch/
+*.aps
+*.ncb
+*.opendb
+*.opensdf
+*.sdf
+*.cachefile
+*.VC.db
+
+# Visual Studio profiler
+*.psess
+*.vsp
+*.vspx
+
+# TFS 2012 Local Workspace
+$tf/
+
+# Guidance Automation Toolkit
+*.gpState
+
+# ReSharper is a .NET coding add-in
+_ReSharper*/
+*.[Rr]e[Ss]harper
+*.DotSettings.user
+
+# JustCode is a .NET coding addin-in
+.JustCode
+
+# TeamCity is a build add-in
+_TeamCity*
+
+# DotCover is a Code Coverage Tool
+*.dotCover
+
+# NCrunch
+_NCrunch_*
+.*crunch*.local.xml
+
+# MightyMoose
+*.mm.*
+AutoTest.Net/
+
+# Web workbench (sass)
+.sass-cache/
+
+# Installshield output folder
+[Ee]xpress/
+
+# DocProject is a documentation generator add-in
+DocProject/buildhelp/
+DocProject/Help/*.HxT
+DocProject/Help/*.HxC
+DocProject/Help/*.hhc
+DocProject/Help/*.hhk
+DocProject/Help/*.hhp
+DocProject/Help/Html2
+DocProject/Help/html
+
+# Click-Once directory
+publish/
+
+# Publish Web Output
+*.[Pp]ublish.xml
+*.azurePubxml
+*.pubxml
+*.publishproj
+
+# NuGet Packages
+*.nuget.props
+*.nuget.targets
+*.nupkg
+**/packages/*
+
+# NuGet package restore lockfiles
+project.lock.json
+
+# Windows Azure Build Output
+csx/
+*.build.csdef
+
+# Windows Store app package directory
+AppPackages/
+
+# Others
+*.Cache
+ClientBin/
+[Ss]tyle[Cc]op.*
+~$*
+*.dbmdl
+*.dbproj.schemaview
+*.pfx
+*.publishsettings
+node_modules/
+*.metaproj
+*.metaproj.tmp
+bin.localpkg/
+
+# RIA/Silverlight projects
+Generated_Code/
+
+# Backup & report files from converting an old project file
+# to a newer Visual Studio version. Backup files are not needed,
+# because we have git ;-)
+_UpgradeReport_Files/
+Backup*/
+UpgradeLog*.XML
+UpgradeLog*.htm
+
+# SQL Server files
+*.mdf
+*.ldf
+
+# Business Intelligence projects
+*.rdl.data
+*.bim.layout
+*.bim_*.settings
+
+# Microsoft Fakes
+FakesAssemblies/
+
+### MonoDevelop ###
+
+*.pidb
+*.userprefs
+
+### Windows ###
+
+# Windows image file caches
+Thumbs.db
+ehthumbs.db
+
+# Folder config file
+Desktop.ini
+
+# Recycle Bin used on file shares
+$RECYCLE.BIN/
+
+# Windows Installer files
+*.cab
+*.msi
+*.msm
+*.msp
+
+# Windows shortcuts
+*.lnk
+
+### Linux ###
+
+*~
+
+# KDE directory preferences
+.directory
+
+### OSX ###
+
+.DS_Store
+.AppleDouble
+.LSOverride
+
+# Icon must end with two \r
+Icon
+
+# Thumbnails
+._*
+
+# Files that might appear on external disk
+.Spotlight-V100
+.Trashes
+
+# Directories potentially created on remote AFP share
+.AppleDB
+.AppleDesktop
+Network Trash Folder
+Temporary Items
+.apdisk
+
+# vim temporary files
+[._]*.s[a-w][a-z]
+[._]s[a-w][a-z]
+*.un~
+Session.vim
+.netrwhist
+*~
+
+# Visual Studio Code
+.vscode/
+
+# Private test configuration and binaries.
+config.ps1
+**/IISApplications

external/corefx/.gitmirrorall

@@ -0,0 +1 @@
+This folder will be mirrored by the Git-TFS Mirror recursively.

external/corefx/BuildToolsVersion.txt

@@ -0,0 +1 @@
+1.0.27-prerelease-01224-01

external/corefx/CONTRIBUTING.md

@@ -0,0 +1,7 @@
+# Contributing
+
+See [Contributing](Documentation/project-docs/contributing.md) for information about coding styles, source structure, making pull requests, and more.
+
+# Developers
+
+See the [Developer Guide](Documentation/project-docs/developer-guide.md) for details about developing in this repo.

external/corefx/CodeAnalysis.ruleset

@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="utf-8"?>
+<RuleSet Name="Rules for Security Issues" Description="Code analysis rules for Security Issues." ToolsVersion="14.0">
+  <Rules AnalyzerId="Desktop.Analyzers" RuleNamespace="Desktop.Analyzers">
+    <Rule Id="CA5350" Action="Error" /> <!-- Do not use Weak/Broken cryptographic algorithms -->
+    <Rule Id="CA5351" Action="Error" />
+    <Rule Id="CA2153" Action="Error"/> <!-- Do not catch corrupted process state exceptions -->
+  </Rules>
+  <Rules AnalyzerId="Desktop.CSharp.Analyzers" RuleNamespace="Desktop.Analyzers">
+    <Rule Id="CA5350" Action="Error" /> <!-- Do not use Weak/Broken cryptographic algorithms -->
+    <Rule Id="CA5351" Action="Error" />
+    <Rule Id="CA2153" Action="Error"/> <!-- Do not catch corrupted process state exceptions -->
+  </Rules>
+  <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
+    <Rule Id="CA1001" Action="None" /> <!-- Non disposable class owns disposable fields -->
+    <Rule Id="CA1018" Action="Error" /> <!-- Specify attribute usage on attribute -->
+    <Rule Id="CA1036" Action="None" /> <!-- Overload comparison operators when implementing System.IComparable -->
+    <Rule Id="CA1715" Action="None" /> <!-- Type parameters names should be prefixed with T -->
+    <Rule Id="CA2213" Action="None" /> <!-- Disposable Fields should be disposed -->
+    <Rule Id="CA2229" Action="Error" /> <!-- Serializable type doesn't have a serialization constructor -->
+    <Rule Id="CA2235" Action="None" /> <!-- Serializable type has non serializable field -->
+    <Rule Id="CA2231" Action="None" /> <!-- Overload operator equals when overriding ValueType.Equals -->
+    <Rule Id="CA2237" Action="Error" /> <!-- Add [Serializable] to types that implement ISerializable -->
+
+    <Rule Id="CA2200" Action="None"/> <!-- Rethrowing caught exception changes stack information -->
+
+    <Rule Id="CA2101" Action="None" /> <!-- Specify marshaling for P/Invoke string arguments -->
+    <Rule Id="CA1401" Action="None" /> <!-- P/Invoke method should not be visible -->
+
+    <Rule Id="CA2214" Action="None" /> <!-- Do not call overridable methods in constructors -->
+  </Rules>
+  <Rules AnalyzerId="System.Runtime.Analyzers" RuleNamespace="System.Runtime.Analyzers">
+    <Rule Id="CA2002" Action="Error" /> <!-- Do not lock on objects with weak identity -->
+  </Rules>
+  <Rules AnalyzerId="System.Security.Cryptography.Hashing.Algorithms.Analyzers" RuleNamespace="System.Security.Cryptography.Hashing.Algorithms.Analyzers">
+    <Rule Id="CA5350" Action="Error" /> <!-- Do not use Weak/Broken cryptographic algorithms -->
+    <Rule Id="CA5351" Action="Error" />
+  </Rules>
+</RuleSet>

external/corefx/Documentation/README.md

@@ -0,0 +1,64 @@
+Documents Index
+===============
+
+Intro to .NET Core
+==================
+
+.NET Core is a self-contained .NET runtime and framework that implements ECMA 335. It can be (and has been) ported to multiple architectures and platforms. It support a variety of installation options, having no specific deployment requirements itself.
+
+Learn about .NET Core
+====================
+
+- [[WIP] Official .NET Core Docs](http://dotnet.github.io/)
+
+Get .NET Core
+=============
+
+- [Get .NET Core SDK](https://www.microsoft.com/net/core)
+
+Project Docs
+============
+
+- [Developer Guide](project-docs/developer-guide.md)
+- [Performance Testing](project-docs/performance-tests.md)
+- [Project priorities](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/project-priorities.md)
+- [Contributing to CoreFX](project-docs/contributing.md)
+- [Contributing to .NET Core](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing.md)
+- [Contributing Workflow](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md)
+- [Issue Guide](project-docs/issue-guide.md)
+- [Branching Guide](project-docs/branching-guide.md)
+- [API Review Process](project-docs/api-review-process.md)
+- [Strong Name Signing](project-docs/strong-name-signing.md)
+- [Public Signing](project-docs/public-signing.md)
+- [Repo Organization](project-docs/repo-organization.md)
+- [Project NuGet Dependencies](https://github.com/dotnet/buildtools/blob/master/Documentation/project-nuget-dependencies.md)
+
+Coding Guidelines
+=================
+
+- [C# coding style](coding-guidelines/coding-style.md)
+- [Framework Design Guidelines](coding-guidelines/framework-design-guidelines-digest.md)
+- [Cross-Platform Guidelines](coding-guidelines/cross-platform-guidelines.md)
+- [Performance Guidelines](coding-guidelines/performance-guidelines.md)
+- [Interop Guidelines](coding-guidelines/interop-guidelines.md)
+- [Breaking Changes](coding-guidelines/breaking-changes.md)
+- [Breaking Change Definitions](coding-guidelines/breaking-change-definitions.md)
+- [Breaking Change Rules](coding-guidelines/breaking-change-rules.md)
+- [Project Guidelines](coding-guidelines/project-guidelines.md)
+- [Adding APIs Guidelines](coding-guidelines/adding-api-guidelines.md)
+
+Building from Source
+====================
+
+- [Building CoreFX on FreeBSD, Linux and OS X](building/unix-instructions.md)
+- [Code Coverage](building/code-coverage.md)
+- [Package and Assembly File Versioning](building/versioning.md)
+
+Other Information
+=================
+
+- [CoreCLR Repo documentation](https://github.com/dotnet/coreclr/tree/master/Documentation)
+- [Porting to .NET Core](project-docs/support-dotnet-core-instructions.md)
+- [.NET Standards (Ecma)](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/dotnet-standards.md)
+- [MSDN Entry for the CLR](http://msdn.microsoft.com/library/8bs2ecf4.aspx)
+- [Wikipedia Entry for the CLR](http://en.wikipedia.org/wiki/Common_Language_Runtime)

external/corefx/Documentation/architecture/net-core-applications.md

@@ -0,0 +1,43 @@
+#.NET Core Applications
+
+NETCoreApp is the [target framework](https://docs.nuget.org/Create/TargetFrameworks) that represents .NET Core applications
+
+Property | Value
+---------|---------
+Target framework identifier | `.NETCoreApp`
+Target framework version | `1.0`
+Target framework moniker | `.NETCoreApp,Version=v1.0`
+Friendly name | .NET Core Application
+NuGet folder name | `netcoreapp1.0`
+NETStandard version supported | `netstandard1.6`
+
+##FAQ
+**Q: What is a .NET Core application?**  
+**A:** A .NET Core application is an application that can run on any .NET Core runtime: CoreCLR (current), .NETNative (future). It can run on one of many .NET core platforms (Windows, OSX, Linux).  It relies on the host provided by the given runtime.  It's a composable framework built from the packages on which the application depends.  Its assembly loading policy permits newer versions of dependencies without any application configuration (eg: BindingRedirects are not required).
+
+**Q: Can I share source between a .NET Core application, and other target frameworks?**  
+**A:** Yes.  Most of the API supported by .NET Core application is also part of .NET Standard.  That source could be compiled as a .NET Standard library and shared with a .NET Core application and a .NET Framework application as a binary.  Alternatively, the source could be shared and cross-compiled between a .NET Core application and a .NET Framework application.
+
+**Q: Can a .NET Core application depend on more packages than just those in the `NETStandard.Library` package?**  
+**A:** Yes.  The contents of `NETStandard.Library` represent the standard library and are guaranteed to be supported by all platforms, including .NET Core applications, that support standard library.  Packages outside of this set will be supported so long as their dependencies are provided and none are platform specific.
+
+**Q: Can a .NET Core application depend on more packages than just those in the `Microsoft.NETCore.App` package?**  
+**A:** Yes.  The contents of `Microsoft.NETCore.App` at a particular version are guaranteed to run on every platform where that version .NET Core is released.  Packages outside this set can be used but don't come with that guarantee.  For instance, if a package is not part of `Microsoft.NETCore.App` and needs to be cross-compiled specifically for a new OS, there is no guarantee that it will be re-released when .NET Core supports that new OS.
+
+**Q: Why is there only one version of `.NETCoreApp` (1.0), but there are many of `.NETStandard`?**  
+**A:** `.NETStandard` is an abstract representation of API that covers all historical platforms that have ever supported that API.  `.NETCoreApp` represents a concrete application type with a runnable implementation.  We are shipping one version of this implementation at this point and it supports `netstandard1.6`.  As we version `.NETStandard` in the future we will update the implementation of `.NETCoreApp` to support the new API and ship a new version of `.NETCoreApp`.
+
+**Q: Can a .NET Core application depend on platform specific packages like `Microsoft.Win32.Registry`?**  
+**A:** Yes, but it will only run on the platforms that support those packages.
+
+**Q: How is this different than `.NETCore`?**  
+**A:** The `.NETCore` target framework represents Windows 8, Windows 8.1, and Universal Windows Platform applications.  For compatibility purposes this moniker cannot be reused for “.NET Core applications”.  The branding overlap is unfortunate.
+
+**Q: How is this different than `DNXCore`?**  
+**A:** The `DNXCore` target framework represents ASP.NET V5 applications that run in DNX and use XProj.  As such the TFM already had more characteristics associated with it than those we associate with .NET Core application.  .NET Core applications need not be ASP.NET applications and can run on any host and runtime supported by .NET Core.
+
+**Q: How is this different than `.NETStandard`?**  
+**A:** The `NETStandard` target framework is an abstract target framework that represents API surface of many frameworks and platforms.  As such `NETStandard` assemblies can run on any platform that supports the `NETStandard` targeted by that assembly, for example: .NET Desktop, Windows Phone, Universal Windows Platform applications, .NET Core applications, etc.  `NETCoreApplication` is a concrete target framework that represents a single platform with both API surface and implementation.  .NET Core applications are runnable on their own.  .NETStandard libraries must be published-for or consumed-by a specific concrete target framework to be used in that type of application.
+
+**Q: How is this different than `.NETFramework`, AKA: Full .NET, Desktop .NET, Big .NET, old .NET?**  
+**A:** `.NETFramework` is another concrete framework like `.NETCoreApp` but has a different implementation and runtime and supports a different set of API.  Both `.NETFramework` and `.NETCoreApp` support a common version of `.NETStandard` and the API it exposes.  As such a `.NETStandard` assembly can be used by both `.NETFramework` and `.NETCoreApp`, but a `.NETCoreApp` assembly is not meant to run on `.NETFramework`, nor is a `.NETFramework` assembly meant to run on `.NETCoreApp`.

external/corefx/Documentation/architecture/net-platform-standard.md

@@ -0,0 +1,10 @@
+# .NET Platform Standard
+
+The .NET Platform Standard has been replaced by [.NET Standard][netstandard].
+
+To learn more about it, check out the [.NET Standard FAQ][netstandard-faq]. It
+provides a good first view into .NET Standard as well pointers to additional
+learning resources, such as documentation and videos.
+
+[netstandard]: https://github.com/dotnet/standard
+[netstandard-faq]: https://github.com/dotnet/standard/blob/master/docs/faq.md

external/corefx/Documentation/building/build-tests-against-packages.md

@@ -0,0 +1,52 @@
+# Building Tests Against Packages
+
+## Usage Scenarios
+
+### Build the product locally and then test what you've built
+
+In this scenario, you produce a product build, including packages, then generate test project.json's which reference the locally built package versions and finally build tests compiling against the local packages.
+
+1. Build the product and packages 
+ - ```Build.cmd -BuildTests=false```
+2. Generate Test project.json files
+ - ```sync.cmd -t -- /p:"SkipCleanPackages=true" /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/"```
+  - /p:SkipCleanPackages=true is required for release branches where the packages folder is cleaned during every build.
+3. Build Tests against packages
+ - ```build-tests.cmd -BuildTestsAgainstPackages -- /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/"```
+  - -BuildTestsAgainstPackages tells the build to use the project.json files you generated in the "Generate Test project.json files" step
+  - /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/" tells the build to use the packages from your local build drop.
+
+### Download product from an Azure blob
+
+This scenario skips the product build step, and instead downloads packages from Azure blob storage
+
+1. Sync product from Azure
+ - ```sync.cmd -ab -AzureAccount=dotnetbuildoutput -AzureToken=******** -Container=[Azure container name] -- /p:"DownloadDirectory=[ProjectDir]Packages\AzureTransfer" /p:"SkipCleanPackages=true"```
+2. Generate Test project.json files
+ - ```sync.cmd -t -- /p:"SkipCleanPackages=true" /p:"PackagesDrops=[ProjectDir]Packages/AzureTransfer/[Release|Debug]/"```
+  - /p:SkipCleanPackages=true is required for release branches where the packages folder is cleaned during every build.
+3. Build Tests against packages
+ - ```build-tests.cmd -BuildTestsAgainstPackages -- /p:"PackagesDrops=[ProjectDir]Packages/AzureTransfer/[Release|Debug]/"```
+  - -BuildTestsAgainstPackages tells the build to use the project.json files you generated in the "Generate Test project.json files" step
+  - /p:"PackagesDrops=[ProjectDir]Packages/AzureTransfer/[Release|Debug]/" tells the build to use the packages from the Azure download (DownloadDirectory).
+
+### Use a versions file for specifying package versions
+
+This scenario uses a versions file (https://github.com/dotnet/versions/blob/master/build-info/dotnet/corefx/master/Latest_Packages.txt, for example) to determine what package versions to build tests against.
+
+1. Generate Test project.json files using a 'versions' file.
+ -   ```sync.cmd -t -- /p:"SkipCleanPackages=true" /p:"VersionsFiles=[local version file path]"```
+  - /p:SkipCleanPackages=true is required for release branches where the packages folder is cleaned during every build.
+2. Build Tests against packages
+ - ```build-tests.cmd -BuildTestsAgainstPackages -- /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/"```
+  - -BuildTestsAgainstPackages tells the build to use the project.json files you generated in the "Generate Test project.json files" step
+  - /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/" tells the build to use the packages from your local build drop.
+   - If the package versions you are referencing have been published publically, you can omit the "PackagesDrops" property.
+
+## Common Questions
+
+- **How do I know it worked?**  The best way is to look in the log for the compilation line ("csc.exe") and ensure that its references now point to packages (packages\blah) where previously they pointed to build product binaries (bin\blah).
+
+- **Why are there build failures?**  Not all of our tests build nicely against package references due to differences in the public surface area (compiling against the reference assembly versus an implementation assembly).  In cases where we were unable to sync / restore (packages were unavailable or other restore problems), we've opted those projects out of this process by adding "KeepAllProjectReferences" or "KeepProjectReference" (added to a Project Reference's metadata) to the test project.
+
+- **Where are the generated project.json files?** Generated project.json files get created under "[ProjectDir]bin/obj/generated".  

external/corefx/Documentation/building/code-coverage.md

@@ -0,0 +1,84 @@
+Code Coverage
+=============
+
+"Code coverage" is a measure that indicates how much of our library code is exercised by our test suites.  We measure code coverage using the [OpenCover](https://github.com/opencover/opencover), and a report of our latest code coverage results can be seen by clicking the coverage badge on the [CoreFX home page](https://github.com/dotnet/corefx):
+
+[![Coverage status](https://img.shields.io/badge/coverage-report-blue.svg)](http://dotnet-ci.cloudapp.net/job/dotnet_corefx_coverage_windows/lastBuild/Code_Coverage_Report/)
+
+This report shows each library currently being tested with code coverage and provides statistics around the quality of the code coverage for the library.  It also provides a line-by-line breakdown of what lines are being covered and what lines are not.
+
+## Goals
+
+The code coverage report provides a percentage value per library of the number of source lines exercised by the tests.  There is no hard and fast percentage that must be obtained per library, as every library is unique and comes with its own set of intricacies and constraints.  While in some cases it's possible and reasonable to achieve 100% code coverage, this is rare.  There are many valid reasons certain pieces of code won't be exercised in tests, e.g.:
+- A code file is compiled into multiple projects, and only some of the code is used in each project.
+- Code exists to handle rare race conditions too costly to simulate in normal conditions.
+- Code exists to handle particular machine/OS configurations that are not used during code coverage runs.
+
+Etc.  What's important is that the right set of tests exist to ensure that the code is behaving properly and that regressions in functionality can be caught quickly, and code coverage metrics are a way to help guide us to that end.
+
+Our default, somewhat-arbitrary initial goal for a library is 90% code coverage.  That doesn't mean we're done with testing once a library hits 90%, nor does it mean we must keep going with a library until it hits 90%.  We use this metric and the associated coverage information to help guide us towards the ideal for a given library.
+
+(Note that we do not want to arbitrarily inflate our code coverage numbers.  Tests must provide value in and of themselves and should not simply be written in a haphazard manner meant to execute more lines of code without providing real value.)
+
+## Issues
+
+Issues are opened for a library when a cursory examination of its code coverage reveal that there are likely still some meaningful gaps that need to be addressed.  We welcome contributions to our test suites to help address these gaps and close these issues.  Many of these issues are marked as "up for grabs".
+
+An issue need not be addressed in its entirety.  We happily accept contributions that improve our tests and work towards improving code coverage numbers even if they only incrementally improve the situation.
+
+## Automated Code Coverage Runs
+
+Code coverage runs are performed by Jenkins approximately twice a day.  The results of these runs are all available from the site linked to by the code coverage badge on the home page.
+
+## Local Code Coverage Runs
+
+You can perform code coverage runs locally on your own machine.  Normally to build your entire CoreFX repo, from the root of your repo you'd run:
+
+    build
+    build-tests
+
+To include code coverage in this run, augment the `build-tests` call with the `coverage` argument:
+
+    build
+    build-tests -coverage
+
+This will do the build and testing as with the normal ```build```, but it will run the tests using the OpenCover tool.  A resulting index.htm file providing the results of the run will be available at:
+
+    bin\tests\coverage\index.htm
+
+You can also build and test with code coverage for a particular test project rather than for the whole repo.  Normally to build and test a particular test suite, from the same directory as that test suite's .csproj, you'd run:
+
+    msbuild /t:BuildAndTest
+
+To do so with code coverage, as with ```build``` append the ```/p:Coverage=true``` argument:
+
+    msbuild /t:BuildAndTest /p:Coverage=true
+
+The results for this one library will then also show up in the aforementioned index.htm file. For example, to build, test, and get code coverage results for the System.Diagnostics.Debug library, from the root of my repo I can do:
+
+    cd src\System.Diagnostics.Debug\tests\
+    msbuild /t:BuildAndTest /p:Coverage=true
+    
+And then once the run completes:
+    
+    ..\..\..\bin\tests\coverage\index.htm
+
+## Code coverage with mscorlib code
+
+Some of the libraries for which contracts and tests live in the corefx repo are actually implemented in the core runtime library in another repo, e.g. the implementation that backs the System.Runtime contract is in System.Private.Corlib.dll in either the coreclr or corert repo. To run coverage reports for these projects, you need to build mscorlib locally from the coreclr repo.
+
+The following steps can be used manually to produce a coverage report, but a customizable batch file can be found [here](facade-code-coverage.bat). Changing the parameters in the first couple of lines lets you run a coverage report easily for any facade project.
+
+1. Build the local test project (`msbuild /T:Build`)
+3. Build coreclr locally in Debug or Release (`build.cmd all Debug skiptests`)
+2. Navigate to the built test directory in the corefx bin (e.g. `bin/tests/AnyOS.AnyCPU.Debug/System.Runtime/netcoreapp1.0` for `System.Runtime`
+4. Delete `coreclr.dll`, `mscorlib.dll`, `mscorlib.ni.dll`, `System.Private.CoreLib.dll` and `System.Private.CoreLib.ni.dll` from that directory
+5. Copy all files in the coreclr `bin` directory to the test directory
+6. Copy all files in the coreclr `bin/PDB` directory to the test directory
+7. Run an OpenCover command with `xunit.console.netcore.exe`. For example:
+
+	<corefx-root>/packages/OpenCover/<opencover-version>/tools/OpenCover.Console.exe -oldStyle -filter:"+[*]* -[*.Tests]* -[xunit.*]*" -excludebyfile:"*\Common\src\System\SR.*" -nodefaultfilters -excludebyattribute:*.ExcludeFromCodeCoverage* -skipautoprops -hideskipped:All -threshold:1 -returntargetcode -register:user -targetdir:<path-to corefx-bin> -target:CoreRun.exe -output:coverage.xml -targetargs:"xunit.console.netcore.exe System.Runtime.Tests -xml testResults.xml -notrait Benchmark=true -notrait category=OuterLoop -notrait category=failing -notrait category=nonwindowstests"
+
+8. Run a ReportGenerator command with the generated `coverage.xml` file. For example:
+
+	<corefx-root>/packages/ReportGenerator/<opencover-version>/tools/ReportGenerator.exe -reporttypes:Html;Badges -reports:coverage.xml

external/corefx/Documentation/building/cross-building.md

@@ -0,0 +1,105 @@
+Cross Compilation for ARM on Linux
+==================================
+
+It is possible to build CoreFx on Linux for arm, armel, or arm64 by cross compiling.
+It is very similar to the cross compilation procedure of CoreCLR.
+
+Requirements
+------------
+
+You need a Debian based host, and the following packages need to be installed:
+
+    lgs@ubuntu ~/git/corefx/ $ sudo apt-get install qemu qemu-user-static binfmt-support debootstrap
+
+In addition, to cross compile CoreFX, the binutils for the target are required. So for arm you need:
+
+    lgs@ubuntu ~/git/corefx/ $ sudo apt-get install binutils-arm-linux-gnueabihf
+
+for armel:
+
+    lgs@ubuntu ~/git/corefx/ $ sudo apt-get install binutils-arm-linux-gnueabi
+
+and for arm64 you need:
+
+    lgs@ubuntu ~/git/corefx/ $ sudo apt-get install binutils-aarch64-linux-gnu
+
+
+Generating the rootfs
+---------------------
+The `cross\build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate an Ubuntu 14.04 rootfs as this is what CoreFX targets.
+
+    Usage: ./cross/build-rootfs.sh [BuildArch] [UbuntuCodeName]
+    BuildArch can be: arm, armel, arm64, x86
+    UbuntuCodeName - optional, Code name for Ubuntu, can be: trusty(default), vivid, wily, xenial. If BuildArch is armel, jessie(default) or tizen.
+
+The `build-rootfs.sh` script must be run as root, as it has to make some symlinks to the system. It will, by default, generate the rootfs in `cross\rootfs\<BuildArch>` however this can be changed by setting the `ROOTFS_DIR` environment variable.
+
+For example, to generate an arm rootfs:
+
+    lgs@ubuntu ~/git/corefx/ $ sudo ./cross/build-rootfs.sh arm
+
+and if you wanted to generate the rootfs elsewhere:
+
+    lgs@ubuntu ~/git/corefx/ $ sudo ROOTFS_DIR=/home/lgs/corefx-cross/arm ./build-rootfs.sh arm
+
+
+Cross compiling for native CoreFX
+---------------------------------
+Once the rootfs has been generated, it will be possible to cross compile CoreFX. If `ROOTFS_DIR` was set when generating the rootfs, then it must also be set when running `build.sh`.
+
+So, without `ROOTFS_DIR`:
+
+    lgs@ubuntu ~/git/corefx/ $ ./build-native.sh -debug -buildArch=arm -- verbose cross
+
+And with:
+
+    lgs@ubuntu ~/git/corefx/ $ ROOTFS_DIR=/home/lgs/corefx-cross/arm ./build-native.sh -debug -buildArch=arm -- verbose cross
+
+As usual the generated binaries will be found in `bin/BuildOS.BuildArch.BuildType/native` as following:
+
+    lgs@ubuntu ~/git/corefx/ ls -al ./bin/Linux.arm.Debug/native
+    total 988
+    drwxrwxr-x 2 lgs lgs   4096  3  6 18:33 .
+    drwxrwxr-x 3 lgs lgs   4096  3  6 18:33 ..
+    -rw-r--r-- 1 lgs lgs  19797  3  6 18:33 System.IO.Compression.Native.so
+    -rw-r--r-- 1 lgs lgs 428232  3  6 18:33 System.Native.a
+    -rw-r--r-- 1 lgs lgs 228279  3  6 18:33 System.Native.so
+    -rw-r--r-- 1 lgs lgs  53089  3  6 18:33 System.Net.Http.Native.so
+    -rw-r--r-- 1 lgs lgs 266720  3  6 18:33 System.Security.Cryptography.Native.so
+    lgs@ubuntu ~/git/corefx/ file ./bin/Linux.arm.Debug/native/System.Native.so
+    ./bin/Linux.arm.Debug/native/System.Native.so:
+    ELF 32-bit LSB  shared object, ARM, EABI5 version 1 (SYSV),
+    dynamically linked, BuildID[sha1]=fac50f1bd657c1759f0ad6cf5951511ddf252e67, not stripped
+
+
+Compiling for managed CoreFX
+============================
+The managed components of CoreFX are architecture-independent and thus do not require a special build for arm, armel or arm64.
+
+Many of the managed binaries are also OS-independent, e.g. System.Linq.dll, while some are OS-specific, e.g. System.IO.FileSystem.dll, with different builds for Windows and Linux.
+
+    lgs@ubuntu ~/git/corefx/ $ ./build-managed.sh -debug -verbose
+
+The output is at `bin/[BuildConfiguration]` where `BuildConfiguration` looks something like `netcoreapp-<OSGroup>-Debug-<Architecture>`. Ex: `bin/netcoreapp-Linux-Debug-x64`. For more details on the build configurations see [project-guidelines](../coding-guidelines/project-guidelines.md)
+
+Building corefx for Linux ARM Emulator
+=======================================
+
+It is possible to build corefx binaries (native and managed) for the Linux ARM Emulator (latest version provided here: [#3805](https://github.com/dotnet/coreclr/issues/3805)).
+The `scripts/arm32_ci_script.sh` script does this.
+
+The following instructions assume that:
+* You have set up the extracted emulator at `/opt/linux-arm-emulator` (such that `/opt/linux-arm-emulator/platform/rootfs-t30.ext4` exists)
+* The mount path for the emulator rootfs is `/opt/linux-arm-emulator-root` (change this path if you have a working directory at this path).
+
+All the following instructions are for the Release mode. Change the commands and files accordingly for the Debug mode.
+
+To just build the native and managed corefx binaries for the Linux ARM Emulator, run the following command:
+```
+prajwal@ubuntu ~/corefx $ ./scripts/arm32_ci_script.sh \
+    --emulatorPath=/opt/linux-arm-emulator \
+    --mountPath=/opt/linux-arm-emulator-root \
+    --buildConfig=Release
+```
+
+The Linux ARM Emulator is based on the soft floating point and thus the native binaries are generated for the armel architecture. The corefx binaries generated by the above command can be found at `~/corefx/bin/Linux.armel.Release`, `~/corefx/bin/Linux.AnyCPU.Release`, `~/corefx/bin/Unix.AnyCPU.Release`, and `~/corefx/bin/AnyOS.AnyCPU.Release`.

external/corefx/Documentation/building/cross-platform-testing.md

@@ -0,0 +1,72 @@
+# Running XUnit tests cross platform
+
+Unlike Windows, where we run tests as part of the build, we have a seperate
+explicit testing step on Linux and OSX. Over time, this special step will go
+away in favor of a similar "run tests during the build" model.
+
+`run-test.sh` is the shell script used by Jenkins in order to run all the XUnit
+tests cross platform. It combines the cross platform CoreCLR and CoreFX builds
+together into a test layout and then runs each test project from CoreFX.
+
+In order to run tests, you need to build a bunch of different projects. The
+instructions assume you are building for Linux, but are easily modifiable for OSX.
+
+1. Release or debug CoreCLR. In Jenkins we use a release CoreCLR build instead
+   of debug CoreCLR since it is much faster at actually running XUnit, but debug
+   will work if you have the time.
+
+   From the root of your CoreCLR enlistment on Linux, run `./build.sh Release` in
+   order to build.
+2. A corresponding version of mscorlib.dll. Depending on your platform, this may
+   be produced when you run  `build.sh`. Otherwise, this can be produced by
+   running `build.cmd linuxmscorlib Release` from a CoreCLR enlistment on
+   Windows. Remember that the runtime and mscorlib are tightly coupled with
+   respect to object sizes and layout so you need to ensure you have either a
+   release coreclr and release mscorlib or debug coreclr and debug mscorlib.
+3. A Linux build of CoreFX. We currently have experimental support for building
+   CoreFX on Linux via `build.sh`. 
+   The other option is:
+
+   * Build the managed parts of CoreFX on Windows. To do so run `build-managed.cmd -os=Linux`. It is okay to build a Debug version of CoreFX and run it
+   on top of a release CoreCLR (which is exactly what we do in Jenkins).
+
+   * Build the native parts of CoreFX on Linux. To do so run `./build-native.sh` from the root of your CoreFX enlistment.
+
+4. The packages folder which contains all the packages restored from NuGet and
+   MyGet when building CoreFX.
+
+
+After building all the projects, we need to copy any of the files we built on Windows
+over to our Linux machine. The easiest way to do this is to mount a windows
+share on linux. For example, I do:
+
+```
+# sudo mount.cifs "//MATELL3/D\$" ~/mnt/matell3/d -o user=matell
+```
+
+If needed, copy CoreFX:
+
+```
+# rsync -v -r ~/mnt/matell3/d/git/corefx/bin/tests ~/git/corefx/bin/tests
+```
+
+If needed, copy the packages folder:
+
+```
+# rsync -v -f ~/mnt/matell3/d/git/corefx/packages ~/git/corefx/packages
+```
+
+If needed, copy mscorlib:
+```
+# rsync -v -r  ~/mnt/matell3/d/git/coreclr/bin/Product/ ~/git/coreclr/bin/Product/
+```
+
+Then, run the tests. We need to pass an explict path to the location of CoreCLR
+and mscorlib.dll.
+
+```
+# ./run-test.sh --coreclr-bins ~/git/coreclr/bin/Product/Linux.x64.Release \
+--mscorlib-bins ~/git/coreclr/bin/Product/Linux.x64.Release \
+```
+
+run-test.sh should now invoke all the managed tests.

external/corefx/Documentation/building/facade-code-coverage.bat

@@ -0,0 +1,82 @@
+@echo off
+:: Example settings for System.Runtime
+SET project=System.Runtime
+SET msbuildargs=/T:Build
+SET testsubdir=AnyOS.AnyCPU.Debug
+SET filter="+[*]* -[*.Tests]* -[*]System.Collections.* -[*]System.Diagnostics.* -[*]System.Globalization.* -[*]System.IO.* -[*]System.Reflection.* -[*]System.Resources.* -[*]System.Runtime.* -[*]System.Security.* -[*]System.StubHelpers.* -[*]System.Threading.* -[*]Microsoft.* -[*]Windows.* -[*]System.App* -[*]System.Text.Decoder* -[*]System.Text.Encoder* -[*]System.Text.*Encoding -[*]System.Text.Internal* -[xunit.*]*"
+
+:: Update this when OpenCover or ReportGenerator are updated
+SET opencoverversion=4.6.519
+SET reportgeneratorversion=2.4.3
+
+:: Assumes that the corefx and coreclr repo folders are in the same parent folder
+SET root=C:\Users\Hugh\Documents\Github
+
+SET corefx=%root%\corefx
+SET coreclr=%root%\coreclr
+
+SET packages=%corefx%\packages
+SET opencover=%packages%\OpenCover\%opencoverversion%\tools\OpenCover.Console.exe
+SET reportgenerator=%packages%\ReportGenerator\%reportgeneratorversion%\tools\ReportGenerator.exe
+
+SET targetdir=%corefx%\bin\tests\%testsubdir%\%project%.Tests\netcoreapp1.0
+
+SET resultsfile=testresults.xml
+SET coveragefile=coverage.xml
+
+SET coveragedir=coverage
+
+SET originalfolder=%cd%
+SET sourcefolder=%corefx%\src\%project%\tests
+
+SET coreclrbuild=%coreclr%\bin\Product\Windows_NT.x64.Debug
+SET coreclrbuild=%coreclr%\bin\Product\Windows_NT.x64.Release
+
+:: Build the library
+cd %sourcefolder%
+msbuild %msbuildargs%
+cd %originalfolder%
+
+:: Delete old files (see #8381 for why)
+del %targetdir%\mscorlib.dll
+del %targetdir%\mscorlib.ni.dll
+del %targetdir%\System.Private.CoreLib.dll
+del %targetdir%\System.Private.CoreLib.ni.dll
+del %targetdir%\coreclr.dll
+del %targetdir%\CoreRun.exe
+del %targetdir%\CoreConsole.exe
+del %targetdir%\clretwrc.dll
+del %targetdir%\clrjit.dll
+del %targetdir%\dbgshim.dll
+del %targetdir%\mscordaccore.dll
+del %targetdir%\mscordbi.dll
+del %targetdir%\mscorrc.debug.dll
+del %targetdir%\mscorrc.dll
+del %targetdir%\sos.dll
+
+:: Copy over our local build files
+For %%a in (
+%coreclrbuild%\mscorlib.dll
+%coreclrbuild%\PDB\mscorlib.pdb
+%coreclrbuild%\System.Private.CoreLib.dll
+%coreclrbuild%\PDB\System.Private.CoreLib.pdb
+%coreclrbuild%\coreclr.dll
+%coreclrbuild%\PDB\coreclr.pdb
+%coreclrbuild%\CoreRun.exe
+%coreclrbuild%\CoreConsole.exe
+%coreclrbuild%\clretwrc.dll
+%coreclrbuild%\clrjit.dll
+%coreclrbuild%\dbgshim.dll
+%coreclrbuild%\mscordaccore.dll
+%coreclrbuild%\mscordbi.dll
+%coreclrbuild%\mscorrc.debug.dll
+%coreclrbuild%\mscorrc.dll
+%coreclrbuild%\sos.dll
+) do copy /b/v/y "%%~a" "%targetdir%\"
+
+:: Now, run the actual tests and generate a coverage report
+SET corerunargs=%targetdir%\xunit.console.netcore.exe %project%.Tests.dll -xml %resultsfile% -notrait category=OuterLoop -notrait category=failing -notrait category=nonwindowstests
+
+%opencover% -oldStyle -filter:%filter% -excludebyfile:"*\Common\src\System\SR.*" -nodefaultfilters -excludebyattribute:*.ExcludeFromCodeCoverage* -skipautoprops -hideskipped:All -threshold:1 -returntargetcode -register:user -targetdir:%targetdir% -target:CoreRun.exe -output:%coveragefile% -targetargs:"%corerunargs%"
+
+%reportgenerator% -targetdir:%coveragedir% -reporttypes:Html;Badges -reports:%coveragefile% -verbosity:Error

external/corefx/Documentation/building/unix-instructions.md

@@ -0,0 +1,105 @@
+Building CoreFX on FreeBSD, Linux and OS X
+==========================================
+##Building
+
+1. Install the prerequisites ([Linux](#user-content-linux), [macOS](#user-content-macos))
+2. Clone the corefx repo `git clone https://github.com/dotnet/corefx.git`
+3. Navigate to the `corefx` directory
+4. Run the build script `./build.sh`
+
+Calling the script `build.sh` builds both the native and managed code.
+Only use it when the parameters that you are passing to the script apply for both components. Otherwise, use the scripts `build-native.sh` and `build-managed.sh` respectively.
+
+For more information about the different options when building, run `build.sh -?` and look at examples in the [developer-guide](../project-docs/developer-guide.md).
+
+## Minimum Hardware Requirements
+- 2GB RAM
+
+## Prerequisites (native build)
+
+### Linux
+
+#### Native build
+
+For Ubuntu 14.04, the following packages should be installed to build the native
+components
+
+* git
+* clang-3.5
+* cmake
+* make
+* libc6-dev
+* libssl-dev
+* libkrb5-dev
+* libcurl4-openssl-dev
+* zlib1g-dev
+
+`sudo apt-get install git clang-3.5 cmake make libc6-dev libssl-dev libkrb5-dev
+libcurl4-openssl-dev zlib1g-dev`
+
+#### Managed build
+
+For Ubuntu 14.04, install the following packages:
+
+* libunwind8
+* libicu52
+* curl
+
+`sudo apt-get install libunwind8 libicu52 curl`
+
+For Ubuntu 16.04 LTS / Bash on Ubuntu on Windows you may need to replace libicu52 with libicu55. Ubuntu 16.10 will require libcu57.
+
+`sudo apt-get install libunwind8 libicu55 curl`
+
+In addition to the above packages, the runtime versions of the packages listed
+in the native section should also be installed (this happens automatically on
+most systems when you install the development packages).
+
+### macOS
+
+On macOS a few components are needed which are not provided by a default developer setup:
+* CMake
+* pkgconfig
+* OpenSSL 1.0.1 or 1.0.2
+
+One way of obtaining these components is via [Homebrew](http://brew.sh):
+```sh
+$ brew install cmake pkgconfig openssl
+```
+
+As of El Capitan (OS X 10.11), Apple still has the libraries for OpenSSL 0.9.8 in `/usr/lib`,
+but the headers are no longer available since that library version is out of support.
+Some compilers get upset over new headers being in `/usr/local/include` with the old library being present at
+`/usr/lib/libcrypto.dylib` (the tools have no issue with the versioned files, e.g. `/usr/lib/libcrypto.0.9.8.dylib`),
+and so Homebrew does not allow the OpenSSL package to be installed into system default paths. A minimal installation
+is presented here to facilitiate simplifying runtime requirements and compile-time requirements (for build systems using
+CMake's `find_package`, like ours):
+```sh
+# We need to make the runtime libraries discoverable, as well as make
+# pkg-config be able to find the headers and current ABI version.
+#
+# Ensure the paths we will need exist
+mkdir -p /usr/local/lib/pkgconfig
+
+# The rest of these instructions assume a default Homebrew path of
+# /usr/local/opt/<module>, with /usr/local being the answer to
+# `brew --prefix`.
+#
+# Runtime dependencies
+ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
+ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/
+
+# Compile-time dependencies (for pkg-config)
+ln -s /usr/local/opt/openssl/lib/pkgconfig/libcrypto.pc /usr/local/lib/pkgconfig/
+ln -s /usr/local/opt/openssl/lib/pkgconfig/libssl.pc /usr/local/lib/pkgconfig/
+ln -s /usr/local/opt/openssl/lib/pkgconfig/openssl.pc /usr/local/lib/pkgconfig/
+```
+
+### Known Issues
+If you see errors along the lines of `SendFailure (Error writing headers)` you may need to import trusted root certificates:
+
+```sh
+mozroots --import --sync
+```
+
+Bash on Ubuntu on Windows issues are tracked by: [#11057](https://github.com/dotnet/corefx/issues/11057)

external/corefx/Documentation/building/versioning.md

@@ -0,0 +1,60 @@
+Package and File Versioning
+===========================
+
+We have now added package versioning and assembly file versioning when building the repo. This versioning works in both Windows and non-Windows platforms. Also, this versioning applies for both the managed and native libraries we produce. We had a few constraints to take into account, for example:
+- Version needed to be higher than the versions that we have already shipped.
+- There needs to be an ability to have multiple versions per day.
+- Versions need to be always increasing.
+- Version needs to be lower than 65535(unsigned short int max) since the version is used as assembly file version which has that constraint.
+- Version needs to be reproducible.
+- (Nice to have) We shouldn't have the need to check in a file containing the version or revision number.
+
+Taking into account all these constraints we came up with the new versioning. The version is calculated per build by [a targets file that lives in buildtools](https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/versioning.targets), and depending on what we are building(native/managed, Windows/non-Windows) it will generate versioning assets that will be used during the build to be able to produce build output with the right versions.
+
+How is the version calculated
+=============================
+
+The version is composed by two parts; the build number major and the build number minor. An example looks something like 00001.01, where the first five digits represent the build number major, and the two last digits after the dot represent the build number minor.
+
+Calculating BuildNumberMajor
+----------------------------
+
+The BuildNumberMajor is represented by 5 digits, and is determined by calculating the time that has happened between the latest commit's date(SeedDate) and a VersionComparisonDate that gets passed in. In the case where VersionComparisonDate is not passed in, we will use April 1st 1996 as default. The reason why we use this specific date, is to ensure that the version produced by SeedDate is higher than the already shipped versions of the same library. The first portion of the BuildNumberMajor (first 3 digits) represent the number of month(s) since the VersionComparisonDate. The second portion of the BuildNumberMajor (last 2 digits) represent the day of the month of SeedDate. This part of the version is reproducible. 
+
+Calculating BuildNumberMinor
+----------------------------
+
+The BuildNumberMinor represent the build # of the day this version is. This number increases by 1, and it starts in 01. Given that there is no way for a dev machine to know how many builds have happened that day, this number is calculated by our VSO official builds and needs to be passed in. Since dev builds usually don't have a BuildNumberMinor (unless it's passed in manually), they will always have a BuildNumberMinor=0. For example, a Official build version would look something like `00001.01` while a dev build version will look like `00001.0`
+
+Packages Version
+----------------
+
+In the case of packages, there is one small difference compared to the assembly file version, which is the separator of BuildNumberMajor and BuildNumberMinor. As noted above, for assembly file version we use a dot `.` to separate these two numbers, but for packages we use a dash `-`. This is due to the different requirements that package names and file versions have. For example, the package version of file 'mylibrary.dll - version 00001.01' would be `mylibrary.1.0.0-prerelease-00001-01.nupkg`
+
+How does the Official Build workflow works
+------------------------------------------
+
+Our Official Builds are a little different than the regular dev flow, and that is because Official Builds need the ability to not only force a specific BuildNumberMinor, but also a BuildNumberMajor. The way they do it, is by passing in the parameter `OfficialBuildId` which specifies the SeedDate that should be used and the revision of the build. For example, the following invocation: `build.cmd -OfficialBuildId=20160523.99` will use May 23 2016 as the SeedDate to generate the version, and it will set '99' as the BuildNumberMinor. With this funcionality, our OfficialBuilds are able to have an orchestrator that triggers different builds and force all of them to have the same version.
+
+Getting the version of a native binary in non-Windows platforms
+========================================================
+
+When trying to get a version of a native binary in non-Windows, there are two ways to do it:
+- Using the Linux tool `sccs what(1)` by installing the tool (if it doesn't come by default with the OS) and then running something like `what myNativeNonWindowsBinary.so`. For more information on the tool, [click here](https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.cmds6/what.htm)
+- The other way to do it if you don't want to install additional tools, is by using `strings+grep`, and the way to do it is by running `strings myNativeNonWindowsBinary.so | grep "@(#)"`
+
+How to force a dev build to produce a specific version
+======================================================
+
+If you need to manually specify the version you want to produce your build output with, you can accomplish this by running the following from the root of the repo: 
+- `build-managed.cmd -BuildNumberMajor=00001 -BuildNumberMinor=01` in Windows
+- `build-managed.sh  -BuildNumberMajor=00001 -BuildNumberMinor=01` in non-Windows
+
+Where is the version being consumed
+===================================
+
+The version we produce by our calculations is mainly used in two places:
+- As the [Assembly File Version](https://msdn.microsoft.com/en-us/library/51ket42z(v=vs.110).aspx)
+- As the packages version number
+
+To get more information on where are we doing the calculations for the versioning, you can [click here](https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/versioning.targets) to find the targets file where we create the versioning assets, and [here](https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/GenerateCurrentVersion.cs) to see the code on where we calculate BuildNumberMajor and BuildNumberMinor.

external/corefx/Documentation/building/windows-instructions.md

@@ -0,0 +1,60 @@
+Building CoreFX on Windows
+==========================
+
+You can build .NET Core either via the command line or by using Visual Studio.
+
+## Required Software
+
+Visual Studio 2015 is required.
+
+The following free downloads are compatible:
+* [Visual Studio Community 2015](http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs)
+
+Note: In order to build our C++ projects be sure to select "Programming Languages | Visual C++ | Common Tools for Visual C++ 2015" while installing VS 2015 (or modify your install to include it).
+
+We also require that [Visual Studio 2015 Update 1](https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx) be installed.
+
+[CMake](https://cmake.org/) is required to build the native libraries for Windows. To build these libraries cmake must be installed from [the CMake download page](https://cmake.org/download/) and added to your path.
+
+## Building From the Command Line
+
+Open a [Visual Studio Command Prompt](http://msdn.microsoft.com/en-us/library/ms229859(v=vs.110).aspx).
+
+- `build.cmd` - Will cause basic tool initialization and build the default configuration for refs, libs, and packages.
+- `build-tests.cmd` - Will build and run tests for the default configuration.
+
+For information on different configurations see [project-guidelines](../coding-guidelines/project-guidelines.md).
+
+**Note**: Before working on individual projects or test projects you **must** run `build.cmd` from the root once before beginning that work. It is also a good idea to run `build.cmd` whenever you pull a large set of unknown changes into your branch.
+
+Visual Studio Solution (.sln) files exist for related groups of libraries. These can be loaded to build, debug and test inside
+the Visual Studio IDE.
+
+Note that when calling the script `build.cmd` attempts to build both the native and managed code.
+Only use it when the parameters that you are passing to the script apply for both components. Otherwise, use the scripts `build-native.cmd` and `build-managed.cmd` respectively.
+
+For more information about the different options when building, run `build.cmd -?` and look at examples in the [developer-guide](../project-docs/developer-guide.md).
+
+### Running tests from Visual Studio
+
+1. Open solution of interest
+2. Right click test project and select 'Set as startup project'
+3. Ctrl+F5 (Run)
+
+### Debugging tests in Visual Studio
+
+1. Install VS 2015 Preview or later including Web Developer Tools
+2. Open solution of interest in VS 2015
+3. Right click test project and select 'Set as startup project'
+4. Set breakpoint appropriately
+5. F5 (Debug)
+
+For advanced debugging using WinDBG see [Debugging CoreFX on Windows](https://github.com/dotnet/corefx/blob/master/Documentation/debugging/windows-instructions.md)
+
+### Notes
+* Running tests from using the VS test explorer does not currently work after we switched to running on CoreCLR. [We will be working on enabling full VS test integration](https://github.com/dotnet/corefx/issues/1318) but we don't have an ETA yet. In the meantime, use the steps above to launch/debug the tests using the console runner.
+
+* VS 2015 is required to debug tests running on CoreCLR as the CoreCLR
+debug engine is a VS 2015 component.
+
+* If the Xamarin PCL profiles are installed, the build will fail due to [issue #449](https://github.com/dotnet/corefx/issues/449).  A possible workaround is listed [in the issue](https://github.com/dotnet/corefx/issues/449#issuecomment-95117040) itself.

external/corefx/Documentation/coding-guidelines/adding-api-guidelines.md

@@ -0,0 +1,140 @@
+Recommended reading to better understand this document:
+[.NET Standard](https://github.com/dotnet/standard/blob/master/docs/faq.md)
+| [Project-Guidelines](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/project-guidelines.md)
+| [Package-Projects](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/package-projects.md)
+
+#Add APIs
+- [Determining versions and targets](#determining-versions-and-targets)
+- [Making the changes in repo](#making-the-changes-in-repo)
+- [FAQ](#faq)
+
+##Determining versions and targets
+
+1. [Determine what library](#determine-what-library) the API goes into.
+2. [Determine the target framework](#determine-target-framework) for the library that will contain the API.
+3. [Determine the version](#determine-library-version) for the library that will contain the API.
+
+###Determine what library
+- Propose a library for exposing it as part of the [API review process](http://aka.ms/apireview).
+- Keep in mind the API might be exposed in a reference assembly that
+doesn't match the identity of the implementation. There are many reasons for this but
+the primary reason is to abstract the runtime assembly identities across
+different platforms while sharing a common API surface and allowing us to refactor
+the implementation without compat concerns in future releases.
+
+###Determine target framework
+`<latest>` is the target framework version currently under development. Currently netcoreapp1.1 and netstandard1.7 (note netstandard1.7 is a placeholder for netstandard2.0).
+
+- If the library is [part of netstandard](#isnetstandard)
+  - Your target framework should be `netstandard<latest>`
+  - If it is a new API only available on .NET Core then it will be added to `netcoreapp<latest>`
+- If the library is not part of netstandard
+  - If package dependencies are changed then your target framework should be the minimum target framework that supports all your package dependencies.
+  - If your package depends directly on runtime changes or library changes that ship with the runtime
+    (i.e. System.Private.CoreLib) then your target framework should be `netstandard<latest>` (hint: usually indicated by needing the latest Microsoft.TargetingPack.Private.* package)
+  - If your package depends on changes in a native shim package then your target framework should be
+    `netstandard<latest>`. (ex: something under https://github.com/dotnet/corefx/tree/master/src/Native)
+  - When targeting `netstandardX` your new API must be supported by all target frameworks that
+    map to that netstandard version (see [mapping table](https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#mapping-the-net-platform-standard-to-platforms)). If not bump the version to the minimum netstandard version that supports this API on all frameworks that map to that netstandard version.
+- If the library is not part of netstandard and not building against netstandard
+  - All the rules for a library that is not part of netstandard apply but instead of having a target framework of
+    `netstandard<latest>` it will have a target framework of `<framework><latest>`. Example `net<latest>` for desktop or `netcoreapp<latest>` for .NET Core.
+- It is not uncommon for a library to target the latest versions of multipe frameworks when adding new APIs (ex: https://github.com/dotnet/corefx/blob/master/src/System.Runtime/ref/System.Runtime.builds)
+
+###Determine library version
+- If targeting netstandard
+  - Ensure minor version of the assembly is bumped since last stable package release
+- If targeting netcoreapp
+  - No assembly version bump necessary
+
+##Making the changes in repo
+
+**If changing the library version**
+  - Update the `AssemblyVersion` property in `<Library>\dir.props` (ex: [System.Runtime\dir.props](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/dir.props#L4)) to the version determined above.
+
+**Update ref**
+  - If changing target framework
+    - Update the `NugetTargetMoniker` property in `<Library>\ref\<Library>.csproj` (ex: [ref\System.Runtime.csproj](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/ref/System.Runtime.csproj#L8))
+    - Update frameworks section in `<Library>\ref\project.json` to add a new target framework or replace an existing one (ex: [System.Runtime\ref\project.json](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/ref/project.json#L4))
+  - Add your API to `<Library>\ref\<Library>.cs`. Use GenAPI to normalize the file.
+  - If adding an additional target framework for the ref (ex: adding a .NET Core specific API) you may need
+  to add a `<Library>\ref\<Library>.builds` for the new configuration (ex: [ref/System.Runtime.Extensions.builds](https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Extensions/ref/System.Runtime.Extensions.builds#L6)).
+
+**Update src**
+  - If changing target framework
+    - Update the `NugetTargetMoniker` property in `<Library>\src\<Library>.csproj` (ex: [src\System.Runtime.csproj](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/src/System.Runtime.csproj#L12))
+    - Update frameworks section in `<Library>\src\project.json` to add a new target framework or replace an existing one (ex: [System.Runtime\src\project.json](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/src/project.json#L3))
+    - Update build configurations in `<Library>\src\<Library>.builds` if necessary (see [Project configuration conventions](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/project-guidelines.md#project-configuration-conventions))
+      - The default build configuration(i.e. TargetGroup excluded) should build the latest version
+      - If you need a live build of the older versions they need to be added as a new configuration
+        - Typically only done for libraries not in netstandard that have larger amounts of code
+          that we want to update outside of servicing events. For any configurations that are removed
+          we will still harvest the old assets from the last stable package an reship them again.
+  - Make your code changes.
+
+**Update pkg**
+ - If changing the target framework
+    - Update `SupportedFramework` metadata on the ref ProjectReference to declare the set of
+      concrete of platforms you expect your library to support. (see [Specific platform mappings](https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#nuget)). Generally
+      will be a combination of netcoreapp1.x, netfx46x, uap10.x, and/or `$(AllXamarinFrameworks)`.
+    - If package is not split (i.e. only one pkgproj, ex [pkg\System.Diagnostics.Process.pkgproj](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/pkg/System.Diagnostics.Process.pkgproj)) then it should already have a `ProjectReference` the `<Library>\src\<Library>.builds` file and so there is no additional changes needed in the pkgproj.
+    - If package is RID split (i.e. has multple pkgprojs, ex: [pkg\any\System.Runtime.pkgproj](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/pkg/any/System.Runtime.pkgproj) and [pkg\aot\System.Runtime](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/pkg/aot/System.Runtime.pkgproj))
+      - Update the ProjectReferences in the respective pkgproj's to align with the build configurations in the
+      `<Library>\src\<Library>.builds` file. This may entail adding new references or removing references according to whatever changes were made to the .builds file.
+  - If assembly or package version is updated the package index needs to be updated by running
+    `msbuild <Library>/pkg/<Library>.pkgproj /t:UpdatePackageIndex`
+
+**Update tests**
+  - If changing target framework
+    - Update the `NugetTargetMoniker` property in `<Library>\tests\<Library>.csproj` (ex: [tests\System.Runtime.csproj](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/tests/System.Runtime.Tests.csproj#L13)). Add a `'$(TargetGroup)' == ''` condition if missing.
+    - Update frameworks section in `<Library>\tests\project.json` to add a new target framework or replace an existing one (ex: [System.Runtime\tests\project.json](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/tests/project.json#L30))
+    - Add new build configuration in `<Library>\tests\<Library>.builds` (ex: [tests\System.Runtime.builds](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/tests/System.Runtime.Tests.builds#L6))
+      - Set `TargetGroup` which will generally match the `TargetGroup` in the src library build configruation. (ex: [tests\System.Runtime.builds](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/tests/System.Runtime.Tests.builds#L7))
+      - Set `TestTFMs` metadata to a list of target frameworks to run on, will generally match the `SupportedFramework` metadata in the pkgproj (ex: [tests\System.Runtime.builds](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/tests/System.Runtime.Tests.builds#L8))
+      - If `TestTFMs` is empty it defaults to [netcoreapp1.0](https://github.com/dotnet/corefx/commit/57af41ef1439ad2e443e42d03d55d41613e4c02e#diff-cd0fc5e0bad8102e1a45aa7575bdd102R155)
+  - Add new test code following [conventions](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/project-guidelines.md#code-file-naming-conventions) for new files to that are specific to the new target framework.
+  - To run just the new test configuration run `msbuild <Library>.csproj /t:RebuildAndTest /p:TargetGroup=<TargetGroup>`
+
+##FAQ
+_**<a name="isnetstandard">Is your API part of netstandard?</a>**_
+
+- For netstandard2.0 refer to https://github.com/dotnet/standard/tree/master/netstandard/ref, and if any Type is included in any of the *.cs files then it is part of netstandard.
+- For earlier netstandard versions refer to list at https://github.com/dotnet/corefx/blob/master/pkg/NETStandard.Library/NETStandard.Library.packages.targets. If the assembly is part of that list then it is in netstandard.
+
+_**What is the difference between being part of netstandard and building against netstandard?**_
+
+Things that are part of netstandard can only change when we release a new version of a platform
+that supports the higher version of netstandard. Whereas things that build against netstandard and
+ship in independent packages can be changed without an update to the platform that it is running on.
+That gives more flexibility to add API to things that build against netstandard because it does not
+require a platform update to consume.
+
+_**What changes require me to update my target framework in my library package?**_
+
+*Target framework of dependencies*
+  - If any changes (ref or src) require a higher target framework of one of the dependencies then your library package target framework must be increased to match the new minimum version that supports all package dependencies.
+
+*Independently shipped dependencies*
+  - If any changes (ref or src) requires a newer runtime/platform change that ships independently(this should generally only apply to libraries that are part of netstandard). Some example dependencies include:
+    - Runtime (aka RID) split package dependencies
+      - Dependencies on runtime changes
+      - Dependencies on runtime libraries (i.e. in Microsoft.TargetingPack.Private.* packages)
+      - Dependencies on new native shim changes
+    - .NET Native Shared Library
+
+_**How do I consume APIs from another package that aren't yet published?**_
+
+If you are adding APIs across multiple packages at the same time. You can temporarily add a direct
+ProjectReference from the ref\csproj to the ref\csproj, src\csproj to the ref\csproj, and/or tests\csproj to pkg\pkgproj. Once a new set of packages have been published these ProjectReferences should be removed.
+
+_**What to do if you are moving types down into a lower contract?**_
+
+If you are moving types down you need to version both contracts at the same time and temporarily use
+project references across the projects. You also need to be sure to leave type-forwards in the places
+where you removed types in order to maintain back-compat.
+
+###Potential clean-up work that can be done
+- Remove old build configurations - The older build configurations will automatically be harvested from
+the last stable packages and thus can be removed.
+- Remove import statements - If not referencing any pre-netstandard stable packages the [imports of dotnet5.x](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/project.json#L28) are no longer needed and can be removed. We should also remove any dead target frameworks sections.
+- Remove all non-conditionsed `<AssemblyVersion>` properties from csproj's as it should be defined in library\dir.props.

external/corefx/Documentation/coding-guidelines/breaking-change-definitions.md

@@ -0,0 +1,38 @@
+Breaking Change Definitions
+===========================
+
+Behavioral Change
+-----------------
+
+A behavioral change represents changes to the behavior of a member. A behavioral change may including throwing a new exception, adding or removing internal method calls, or alternating the way in which a return value is calculated. Behavioral changes can be the hardest type of change to categorize as acceptable or not - they can be severe in impact, or relatively innocuous.
+
+Binary Compatibility  
+--------------------
+
+Refers to the ability of existing consumers of an API to be able to use a newer version without recompilation. By definition, if an assembly's public signatures have been removed, or altered so that consumers cannot no longer access the same interface exposed by the assembly, the change is said to be a _binary incompatible change_.
+
+Source Compatibility
+--------------------
+
+Refers to the ability of existing consumers of an API to recompile against a newer version without any source changes. By definition, if a consumer needs to make changes to its code in order to for it build successfully against a newer version of an API, the change is said to be a _source incompatible change_.
+
+Design-Time Compatibility  
+-------------------------
+
+_Design-time compatibility_ refers to preserving the design-time experience across versions of Visual Studio and other design-time environments. This can involve details around the UI of the designer, but by far the most interesting design-time compatibility is project compatibility. A potential project (or solution), must be able to be opened, and used on a newer version of a designer.
+
+Backwards Compatibility  
+-----------------------
+
+_Backwards compatibility_ refers to the ability of an existing consumer of an API to run against, and behave in the same way against a newer version. By definition, if a consumer is not able to run, or behaves differently against the newer version of the API, then the API is said to be _backwards incompatible_. 
+
+Changes that affect backwards compatibility are strongly discouraged. All alternates should be actively considered, since developers will, by default, expect backwards compatibility in newer versions of an API.
+
+Forwards Compatibility  
+----------------------
+
+_Forwards compatibility_ is the exact reverse of backwards compatibility; it refers to the ability of an existing consumer of an API to run against, and behave in the way against a _older_ version. By definition, if a consumer is not able to run, or behaves differently against an older version of the API, then the API is said to be _forwards incompatible_.
+
+Changes that affect forwards compatibility are generally less pervasive, and there is not as stringent a demand to ensure that such changes are not introduced. Customers accept that a consumer which relies upon a newer API, may not function correctly against the older API.
+
+This document does not attempt to detail forwards incompatibilities.