dotnet · ivdiazsa · Mar 27, 2020 · Mar 4, 2020 · Mar 6, 2020 · Mar 10, 2020
diff --git a/.config/CredScanSuppressions.json b/.config/CredScanSuppressions.json
@@ -15,6 +15,7 @@
       "/src/libraries/Common/tests/System/Net/Http/PostScenarioTest.cs",
       "/src/libraries/Common/tests/System/Net/Prerequisites/Deployment/setup_certificates.ps1",
       "/src/libraries/Common/tests/System/Security/Cryptography/AlgorithmImplementations/EC/ECKeyFileTests.cs",
+      "/src/libraries/Common/tests/System/Security/Cryptography/AlgorithmImplementations/EC/ECKeyFileTests.LimitedPrivate.cs",
       "/src/libraries/Common/tests/System/Security/Cryptography/AlgorithmImplementations/RSA/RSAKeyFileTests.cs",
       "/src/libraries/System.Data.Common/tests/System/Data/Common/DbConnectionStringBuilderTest.cs",
       "/src/libraries/System.Diagnostics.Process/tests/ProcessStartInfoTests.cs",

diff --git a/.config/dotnet-tools.json b/.config/dotnet-tools.json
@@ -9,7 +9,7 @@
       ]
     },
     "dotnet-reportgenerator-globaltool": {
-      "version": "4.5.0",
+      "version": "4.5.2",
       "commands": [
         "reportgenerator"
       ]

diff --git a/.gitignore b/.gitignore
@@ -27,7 +27,7 @@ bld/
 msbuild.log
 msbuild.err
 msbuild.wrn
-msbuild.binlog
+*.binlog
 .deps/
 .dirstamp
 .libs/

diff --git a/Build.proj b/Build.proj
@@ -0,0 +1,80 @@
+<Project Sdk="Microsoft.Build.Traversal">
+
+  <!--
+    Subsets are already imported by Directory.Build.props.
+    Reference the projects for traversal build. Ordering matters here.
+  -->
+  <ItemGroup>
+    <ProjectReference Include="@(CoreClrProject)" />
+    <ProjectReference Include="@(MonoProject)" />
+    <ProjectReference Include="@(LibrariesProject)" />
+    <ProjectReference Include="@(InstallerProject)" />
+  </ItemGroup>
+
+  <!--
+    Exclude installer depproj and pkgproj from static graph restore. We restore them below.
+    Remove when https://github.com/NuGet/Home/issues/9398 is fixed.
+  -->
+  <ItemGroup Condition="'$(MSBuildRestoreSessionId)' != ''">
+    <ProjectReference Remove="@(DepprojProjectToBuild)"  />
+    <ProjectReference Remove="@(PkgprojProjectToBuild)" />
+    <ProjectReference Remove="@(BundleProjectToBuild)" />
+  </ItemGroup>
+
+  <!-- Custom arcade target which isn't available in Microsoft.Build.Traversal. -->
+  <Target Name="Rebuild" DependsOnTargets="Clean;Build" />
+
+  <Import Project="$(RepositoryEngineeringDir)SubsetValidation.targets" />
+
+  <!-- Upfront restore hooks -->
+  <Import Project="$(RepositoryEngineeringDir)restore\docs.targets" Condition="'$(DotNetBuildFromSource)' != 'true'" />
+  <Import Project="$(RepositoryEngineeringDir)restore\optimizationData.targets" Condition="'$(DotNetBuildFromSource)' != 'true' and '$(EnableNgenOptimization)' == 'true'" />
+  <Import Project="$(RepositoryEngineeringDir)restore\runtimeprops.targets" />
+
+  <!--
+    Use synthetic inputs/outputs to avoid building it all the time. This should let devs build with
+    MSBuild node reuse enabled (the Arcade default). If it were built every time, it would hit file
+    locking issues vs. the persistent nodes that loaded the task DLL for the previous build. It
+    isn't particularly accurate, but better than nothing.
+  -->
+  <Target Name="BuildRepoTasks"
+          DependsOnTargets="GetRepoTasksSrc"
+          BeforeTargets="Restore"
+          Inputs="@(RepoTasksSrc)"
+          Outputs="$(RepoTasksOutputFile)">
+    <ItemGroup>
+      <RepoTaskProjects Include="$(RepoTasksDir)**\*.csproj" />
+    </ItemGroup>
+
+    <MSBuild Projects="@(RepoTaskProjects)"
+             Properties="MSBuildRestoreSessionId=$([System.Guid]::NewGuid());Configuration=Debug;Platform=AnyCPU"
+             Targets="Restore"/>
+
+    <MSBuild Projects="@(RepoTaskProjects)"
+             Properties="Configuration=Debug;Platform=AnyCPU"
+             Targets="Build"/>
+
+    <WriteLinesToFile File="$(RepoTasksOutputFile)"
+                      Lines="$(RepoTasksOutputFile)"
+                      Overwrite="true" />
+  </Target>
+
+  <Target Name="GetRepoTasksSrc">
+    <PropertyGroup>
+      <RepoTasksDir>$(RepoTasksDir)</RepoTasksDir>
+      <RepoTasksOutputFile>$(ArtifactsObjDir)runtime.tasks\Debug\build-semaphore.txt</RepoTasksOutputFile>
+    </PropertyGroup>
+
+    <ItemGroup>
+      <RepoTasksSrc Include="$(RepoTasksDir)**\*.cs*" />
+    </ItemGroup>
+  </Target>
+
+  <Target Name="RestoreWithoutStaticGraph"
+          BeforeTargets="Restore">
+    <MSBuild Projects="@(LibrariesRestoreProject);@(DepprojProjectToBuild);@(PkgprojProjectToBuild);@(BundleProjectToBuild)"
+             Properties="MSBuildRestoreSessionId=$([System.Guid]::NewGuid());RestoreUseStaticGraphEvaluation=false"
+             Targets="Restore" />
+  </Target>
+
+</Project>
diff --git a/Directory.Build.props b/Directory.Build.props
@@ -27,14 +27,7 @@
     <ArtifactsObjDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsDir)', 'obj'))</ArtifactsObjDir>
   </PropertyGroup>
 
-  <!-- The TFMs to build and test against. -->
-  <PropertyGroup>
-    <NETCoreAppCurrentVersion>5.0</NETCoreAppCurrentVersion>
-    <NetCoreAppCurrentTargetFrameworkMoniker>.NETCoreApp,Version=v$(NETCoreAppCurrentVersion)</NetCoreAppCurrentTargetFrameworkMoniker>
-    <NetCoreAppCurrent>netcoreapp$(NETCoreAppCurrentVersion)</NetCoreAppCurrent>
-    <NetFrameworkCurrent>net472</NetFrameworkCurrent>
-  </PropertyGroup>
-
+  <!-- Configuration properties which are needed in both the (isolated) restore and build phases. -->
   <Import Project="$(RepositoryEngineeringDir)Configurations.props" />
 
   <!--

diff --git a/NuGet.config b/NuGet.config
@@ -12,11 +12,10 @@
     -->
     <!-- TEST_RESTORE_SOURCES_INSERTION_LINE -->
     <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
-    <add key="dotnet-tools" value="https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet-tools/nuget/v3/index.json" />
+    <add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
     <add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
+    <add key="dotnet5" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json" />
     <add key="dotnet5-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5-transport/nuget/v3/index.json" />
-    <add key="dotnet-core" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" />
-    <add key="dotnet-coreclr" value="https://dotnetfeed.blob.core.windows.net/dotnet-coreclr/index.json" />
   </packageSources>
   <disabledPackageSources>
     <clear />

diff --git a/README.md b/README.md
@@ -3,10 +3,10 @@
 [![Build Status](https://dnceng.visualstudio.com/public/_apis/build/status/dotnet/runtime/runtime?branchName=master)](https://dnceng.visualstudio.com/public/_build/latest?definitionId=686&branchName=master)
 [![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/runtime)
 
-This repo contains the code to build the .NET Core runtime, libraries and shared host (`dotnet`) installers for
-all supported platforms, as well as the sources to .NET Core runtime and libraries.
+This repo contains the code to build the .NET runtime, libraries and shared host (`dotnet`) installers for
+all supported platforms, as well as the sources to .NET runtime and libraries.
 
-## What is .NET Core?
+## What is .NET?
 
 Official Starting Page: https://dotnet.microsoft.com/
 
@@ -24,6 +24,7 @@ We welcome contributions! Many people all over the world have helped make this p
 
 * [Contributing](CONTRIBUTING.md) explains what kinds of changes we welcome
 - [Workflow Instructions](docs/workflow/README.md) explains how to build and test
+* [Get Up and Running on .NET Core](docs/project/dogfooding.md) explains how to get nightly builds of the runtime and its libraries to test them in your own projects.
 
 ## Reporting security issues and security bugs
 
@@ -33,11 +34,11 @@ Also see info about related [Microsoft .NET Core and ASP.NET Core Bug Bounty Pro
 
 ## Filing issues
 
-This repo should contain issues that are tied to the runtime, the class libraries and frameworks, the installation of the `dotnet` binary (sometimes known as the `muxer`) and installation of the .NET Core runtime and libraries.
+This repo should contain issues that are tied to the runtime, the class libraries and frameworks, the installation of the `dotnet` binary (sometimes known as the `muxer`) and installation of the .NET runtime and libraries.
 
 For other issues, please use the following repos:
 
-- For overall .NET Core SDK issues, file in the [dotnet/sdk](https://github.com/dotnet/sdk) repo
+- For overall .NET SDK issues, file in the [dotnet/sdk](https://github.com/dotnet/sdk) repo
 - For ASP.NET issues, file in the [dotnet/aspnetcore](https://github.com/dotnet/aspnetcore) repo.
 
 ## Useful Links
@@ -49,7 +50,7 @@ For other issues, please use the following repos:
 
 ## .NET Foundation
 
-.NET Core is a [.NET Foundation](https://www.dotnetfoundation.org/projects) project.
+.NET Runtime is a [.NET Foundation](https://www.dotnetfoundation.org/projects) project.
 
 There are many .NET related projects on GitHub.
 

diff --git a/THIRD-PARTY-NOTICES.TXT b/THIRD-PARTY-NOTICES.TXT
@@ -1,5 +1,5 @@
-.NET Core uses third-party libraries or other resources that may be
-distributed under licenses different than the .NET Core software.
+.NET Runtime uses third-party libraries or other resources that may be
+distributed under licenses different than the .NET Runtime software.
 
 In the event that we accidentally failed to list a required notice, please
 bring it to our attention. Post an issue or email us:

diff --git a/coreclr.cmd b/coreclr.cmd
diff --git a/coreclr.sh b/coreclr.sh
diff --git a/docs/area-owners.md b/docs/area-owners.md
@@ -48,10 +48,10 @@ Below table shows the combined area owners on this repository:
 | area-Tracing-mono | @lambdageek | |
 | area-Performance-mono | @SamMonoRT | |
 | **System namespaces** | | |
-| area-System.Buffers | @tannergooding @JeremyKuhne | |
+| area-System.Buffers | @tannergooding | |
 | area-System.CodeDom | @buyaa-n @krwq | |
 | area-System.Collections | @eiriktsarpalis @layomia | </ul>Excluded:<ul><li>System.Array -> System.Runtime</li></ul> |
-| area-System.ComponentModel | @JeremyKuhne @safern | |
+| area-System.ComponentModel | @safern | |
 | area-System.ComponentModel.Composition | @maryamariyan @ViktorHofer | |
 | area-System.ComponentModel.DataAnnotations | @lajones @ajcvickers | |
 | area-System.Composition | @maryamariyan @ViktorHofer | |
@@ -63,10 +63,10 @@ Below table shows the combined area owners on this repository:
 | area-System.Diagnostics.Process | @adamsitnik @eiriktsarpalis | |
 | area-System.Diagnostics.Tracing | @noahfalk @tommcdon @tarekgh @Anipik | Packages:<ul><li>System.Diagnostics.DiagnosticSource</li><li>System.Diagnostics.PerformanceCounter - [@Anipik](https://github.com/Anipik)</li><li>System.Diagnostics.Tracing</li><li>System.Diagnostics.TraceSource - [@Anipik](https://github.com/Anipik)</li></ul><br/> |
 | area-System.DirectoryServices | @tquerec @josephisenhour | |
-| area-System.Drawing | @JeremyKuhne @safern | |
+| area-System.Drawing | @safern | |
 | area-System.Dynamic.Runtime | @cston @333fred | Archived component - limited churn/contributions (see [#33170](https://github.com/dotnet/corefx/issues/33170)) |
 | area-System.Globalization | @safern @tarekgh @krwq | |
-| area-System.IO | @JeremyKuhne @carlossanlop @jozkee | |
+| area-System.IO | @carlossanlop @jozkee | |
 | area-System.IO.Compression | @carlossanlop @ericstj | <ul><li>Also includes System.IO.Packaging</li></ul> |
 | area-System.IO.Pipelines | @davidfowl @halter73 @jkotalik @anurse | |
 | area-System.Linq | @eiriktsarpalis @adamsitnik | |
@@ -90,7 +90,7 @@ Below table shows the combined area owners on this repository:
 | area-System.Runtime.InteropServices | @AaronRobinsonMSFT @jkoritzinsky | Excluded:<ul><li>System.Runtime.InteropServices.RuntimeInfo</li></ul> |
 | area-System.Runtime.Intrinsics | @tannergooding @CarolEidt @echesakovMSFT | |
 | area-System.Security | @bartonjs @GrabYourPitchforks @krwq | |
-| area-System.ServiceModel | @StephenBonikowsky @HongGit @mconnew | Repo: https://github.com/dotnet/WCF<br>Packages:<ul><li>System.ServiceModel.Primitives</li><li>System.ServiceModel.Http</li><li>System.ServiceModel.NetTcp</li><li>System.ServiceModel.Duplex</li><li>System.ServiceModel.Security</li></ul> |
+| area-System.ServiceModel | @HongGit @mconnew | Repo: https://github.com/dotnet/WCF<br>Packages:<ul><li>System.ServiceModel.Primitives</li><li>System.ServiceModel.Http</li><li>System.ServiceModel.NetTcp</li><li>System.ServiceModel.Duplex</li><li>System.ServiceModel.Security</li></ul> |
 | area-System.ServiceModel.Syndication | @StephenMolloy @HongGit | |
 | area-System.ServiceProcess | @Anipik | |
 | area-System.Text.Encoding | @layomia @krwq @tarekgh | |

diff --git a/docs/coding-guidelines/api-guidelines/nullability.md b/docs/coding-guidelines/api-guidelines/nullability.md
@@ -1,10 +1,10 @@
 # Nullability annotations
 
-C# 8 provides an opt-in feature that allows for the compiler to  track reference type nullability in order to catch potential null dereferences.  We are adopting that feature across .NET Core's libraries, working up from the bottom of the stack.  We're doing this for three primary reasons, in order of importance:
+C# 8 provides an opt-in feature that allows for the compiler to  track reference type nullability in order to catch potential null dereferences.  We are adopting that feature across .NET's libraries, working up from the bottom of the stack.  We're doing this for three primary reasons, in order of importance:
 
-- **To annotate the .NET Core surface area with appropriate nullability annotations.**  While this could be done solely in the reference assemblies, we're doing it first in the implementation to help validate the selected annotations.
+- **To annotate the .NET surface area with appropriate nullability annotations.**  While this could be done solely in the reference assemblies, we're doing it first in the implementation to help validate the selected annotations.
 - **To help validate the nullability feature itself.**  With millions of lines of C# code, we have a very large and robust codebase with which to try out the feature and find areas in which it shines and areas in which we can improve it.  The work to annotate System.Private.CoreLib in .NET Core 3.0 helped to improve the feature as shipped in C# 8, and annotating the rest of the libraries will continue to be helpful in this regard.
-- **To find null-related bugs in .NET Core itself.** We expect to find relatively few meaningful bugs, due to how relatively well-tested the codebases are and how long they've been around.
+- **To find null-related bugs in .NET Runtime itself.** We expect to find relatively few meaningful bugs, due to how relatively well-tested the codebases are and how long they've been around.
 
 ## Breaking Change Guidance
 

diff --git a/docs/coding-guidelines/breaking-change-rules.md b/docs/coding-guidelines/breaking-change-rules.md
@@ -135,6 +135,7 @@ Breaking Change Rules
     So long as it does not introduce any new abstract members or change the semantics or behavior of existing members, a type can be introduced into a hierarchy between two existing types. For example, between .NET Framework 1.1 and .NET Framework 2.0, we introduced `DbConnection` as a new base class for `SqlConnection` which previously derived from `Component`.
 
 * Adding an interface implementation to a type
+
     This is acceptable because it will not adversely affect existing clients. Any changes which could be made to the type being changed in this situation, will have to work within the boundaries of acceptable changes defined here, in order for the new implementation to remain acceptable.
     Extreme caution is urged when adding interfaces that directly affect the ability of the designer or serializer to generate code or data, that cannot be consumed down-level. An example is the `ISerializable` interface.
     Care should be taken when the interface (or one of the interfaces that this interface requires) has default interface implementations for other interface methods. The default implementation could conflict with other default implementations in a derived class.

diff --git a/docs/coding-guidelines/coding-style.md b/docs/coding-guidelines/coding-style.md
@@ -3,16 +3,16 @@ C# Coding Style
 
 For C++ files (*.cpp and *.h), we use clang-format (version 3.6+) to ensure code styling. After changing any Cpp or H file and before merging, src/Native/format-code.sh must be run. This script will ensure that all native code files adhere to the coding style guidelines.
 
-For non code files (xml, etc), our current best guidance is consistency. When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. If there is a completely new component, anything that is reasonably broadly accepted is fine.
+For other types of files (xml, bat, sh, etc), our current best guidance is consistency. When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. If there is a completely new component, anything that is reasonably broadly accepted is fine. For script files, please refer to the scripting blog for [tips](https://devblogs.microsoft.com/scripting/tag/powertip) and [best practices](https://devblogs.microsoft.com/scripting/tag/best-practices).
 
 The general rule we follow is "use Visual Studio defaults".
 
 1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces (See rule 17 for more details). One exception is that a `using` statement is permitted to be nested within another `using` statement by starting on the following line at the same indentation level, even if the nested `using` contains a controlled block.
 2. We use four spaces of indentation (no tabs).
 3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix internal and private instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`).  Public fields should be used sparingly and should use PascalCasing with no prefix when used.
-4. We avoid `this.` unless absolutely necessary. 
+4. We avoid `this.` unless absolutely necessary.
 5. We always specify the visibility, even if it's the default (e.g.
-   `private string _foo` not `string _foo`). Visibility should be the first modifier (e.g. 
+   `private string _foo` not `string _foo`). Visibility should be the first modifier (e.g.
    `public abstract` not `abstract public`).
 6. Namespace imports should be specified at the top of the file, *outside* of
    `namespace` declarations, and should be sorted alphabetically, with the exception of `System.*` namespaces, which are to be placed on top of all others.
@@ -77,7 +77,7 @@ namespace System.Collections.Generic
             get { return _count; }
         }
 
-        public ObservableLinkedListNode AddLast(T value) 
+        public ObservableLinkedListNode AddLast(T value)
         {
             var newNode = new LinkedListNode<T>(this, value);
 
@@ -97,7 +97,7 @@ namespace System.Collections.Generic
         {
             ...
         }
-        
+
         ...
     }
 }

diff --git a/docs/coding-guidelines/cross-platform-performance-and-eventing.md b/docs/coding-guidelines/cross-platform-performance-and-eventing.md
@@ -252,7 +252,7 @@ Given the significant work required to bring all of this infrastructure up, this
 
 We’ll use the following scenarios when defining priorities:
 
-- P1: Performance analysis in support of bring-up of the .NET Core runtime and framework on Linux and OS X.
+- P1: Performance analysis in support of bring-up of the .NET runtime and framework on Linux and OS X.
 - P2: Performance analysis of ASP.NET running on .NET Core on Linux and OS X.
 
 To support these scenarios, we need the following capabilities: