Merge commit '0ab835c0b27280b87db4385740107bf878f1c491' into release/5.0-preview5

Author: Anipik

.config/dotnet-tools.json

@@ -3,19 +3,19 @@
   "isRoot": true,
   "tools": {
     "coverlet.console": {
-      "version": "1.7.0",
+      "version": "1.7.1",
       "commands": [
         "coverlet"
       ]
     },
     "dotnet-reportgenerator-globaltool": {
-      "version": "4.5.2",
+      "version": "4.5.8",
       "commands": [
         "reportgenerator"
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "1.0.0-prerelease.20214.1",
+      "version": "1.0.0-prerelease.20254.3",
       "commands": [
         "xharness"
       ]

.editorconfig

@@ -165,6 +165,9 @@ indent_brace_style = Allman
 [*.{csproj,vbproj,vcxproj,vcxproj.filters,proj,nativeproj,locproj}]
 indent_size = 2
 
+[*.{csproj,vbproj,proj,nativeproj,locproj}]
+charset = utf-8
+
 # Xml build files
 [*.builds]
 indent_size = 2

Build.proj

@@ -29,7 +29,6 @@
   <!-- 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

Directory.Build.props

@@ -41,7 +41,6 @@
     <InstallerTasksOutputPath>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'installer.tasks'))</InstallerTasksOutputPath>
     <InstallerTasksAssemblyPath Condition="'$(MSBuildRuntimeType)' == 'Core'">$([MSBuild]::NormalizePath('$(InstallerTasksOutputPath)', 'Debug', 'netstandard2.0', 'installer.tasks.dll'))</InstallerTasksAssemblyPath>
     <InstallerTasksAssemblyPath Condition="'$(MSBuildRuntimeType)' != 'Core'">$([MSBuild]::NormalizePath('$(InstallerTasksOutputPath)', 'Debug', 'net46', 'installer.tasks.dll'))</InstallerTasksAssemblyPath>
-    <HostMachineInfoProps>$(ArtifactsObjDir)HostMachineInfo.props</HostMachineInfoProps>
 
     <DocsDir>$([MSBuild]::NormalizeDirectory('$(RepoRoot)', 'docs'))</DocsDir>
     <ManPagesDir>$([MSBuild]::NormalizeDirectory('$(DocsDir)', 'manpages'))</ManPagesDir>
@@ -76,9 +75,6 @@
   <!-- Language configuration -->
   <PropertyGroup>
     <Deterministic>true</Deterministic>
-
-    <!-- Resource naming bug: https://github.com/microsoft/msbuild/issues/4740 -->
-    <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
   </PropertyGroup>
 
   <PropertyGroup>

Directory.Build.targets

@@ -26,4 +26,5 @@
     <LangVersion>preview</LangVersion>
     <LangVersion Condition="'$(Language)' == 'VB'">latest</LangVersion>
   </PropertyGroup>
+
 </Project>

build.cmd

@@ -4,5 +4,5 @@ setlocal
 set _args=%*
 if "%~1"=="-?" set _args=-help
 
-powershell -ExecutionPolicy ByPass -NoProfile -Command "%~dp0eng\build.ps1" %_args%
+powershell -ExecutionPolicy ByPass -NoProfile -Command "& '%~dp0eng\build.ps1'" %_args%
 exit /b %ERRORLEVEL%

docs/coding-guidelines/adding-api-guidelines.md

@@ -24,8 +24,8 @@ the implementation without compat concerns in future releases.
 
 ### Determine target framework
 
-`netcoreapp5.0` is the target framework version currently under development and the new apis
-should be added to `netcoreapp5.0`. [More Information on TargetFrameworks](https://docs.microsoft.com/en-us/dotnet/standard/frameworks)
+`net5.0` is the target framework version currently under development and the new apis
+should be added to `net5.0`. [More Information on TargetFrameworks](https://docs.microsoft.com/en-us/dotnet/standard/frameworks)
 
 ## Making the changes in repo
 

docs/coding-guidelines/api-guidelines/nullability.md

@@ -94,6 +94,7 @@ The C# compiler respects a set of attributes that impact its flow analysis.  We
 - **DO** annotate `ref` arguments that guarantee the argument will be non-`null` upon exit (e.g. lazy initialization helpers) with `[NotNull]`.
 - **DO** annotate properties where a getter will never return `null` but a setter allows `null` as being non-nullable but also `[AllowNull]`.
 - **DO** annotate properties where a getter may return `null` but a setter throws for `null` as being nullable but also `[DisallowNull]`.
+- **DO** add `[NotNullWhen(true)]` to nullable arguments of `Try` methods that will definitively be non-`null` if the method returns `true`.  For example, if `Int32.TryParse(string? s)` returns `true`, `s` is known to not be `null`, and so the method should be `public static bool TryParse([NotNullWhen(true)] string? s, out int result)`.
 
 ## Code Review Guidance
 

docs/coding-guidelines/interop-guidelines.md

@@ -178,7 +178,7 @@ Guidelines for shim C++ API:
   - If an export point has a 1:1 correspondence to the platform API, then name it after the platform API in PascalCase (e.g. stat -> Stat, fstat -> FStat).
   - If an export is not 1:1, then spell things out as we typically would in dotnet/runtime code (i.e. don't use abbreviations unless they come from the underlying API.
   - At first, it seemed that we'd want to use 1:1 names throughout, but it turns out there are many cases where being strictly 1:1 isn't practical.
-  - In order to reduce the chance of collisions when linking with CoreRT, all exports should have a prefix that corresponds to the Libraries' name, e.g. "SystemNative_" or "CryptoNative_" to make the method name more unique. See https://github.com/dotnet/corefx/issues/4818.
+  - In order to reduce the chance of collisions when linking with CoreRT, all exports should have a prefix that corresponds to the Libraries' name, e.g. "SystemNative_" or "CryptoNative_" to make the method name more unique. See https://github.com/dotnet/runtime/issues/15854.
 - Stick to data types which are guaranteed not to vary in size across flavors.
   - Use int32_t, int64_t, etc. from stdint.h and not int, long, etc.
   - Use char* for ASCII or UTF-8 strings and uint8_t* for byte buffers.

docs/coding-guidelines/project-guidelines.md

@@ -28,7 +28,7 @@ Below is a list of all the various options we pivot the project builds on:
 ## Individual build properties
 The following are the properties associated with each build pivot
 
-- `$(BuildTargetFramework) -> netstandard2.1 | netcoreapp5.0 | net472`
+- `$(BuildTargetFramework) -> netstandard2.1 | net5.0 | net472`
 - `$(TargetOS) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
 - `$(Configuration) -> Release | [defaults to Debug when empty]`
 - `$(TargetArchitecture) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]`
@@ -82,7 +82,7 @@ When we have a project that has a `netstandard2.0` target framework that means t
 A full or individual project build is centered around BuildTargetFramework, TargetOS, Configuration and TargetArchitecture.
 
 1. `$(BuildTargetFramework), $(TargetOS), $(Configuration), $(TargetArchitecture)` can individually be passed in to change the default values.
-2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `netcoreapp5.0-[TargetOS Running On]-Debug-x64`.
+2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `net5.0-[TargetOS Running On]-Debug-x64`.
 3. While Building an individual project from the VS, we build the project for all latest netcoreapp target frameworks.
 
 We also have `RuntimeOS` which can be passed to customize the specific OS and version needed for native package builds as well as package restoration. If not passed it will default based on the OS you are running on.
@@ -97,6 +97,46 @@ When building an individual project the `BuildTargetFramework` and `TargetOS` wi
 - .NET Framework latest -> `$(NetFrameworkCurrent)-Windows_NT`
 
 # Library project guidelines
+
+## TargetFramework conditions
+`TargetFramework` conditions should be avoided in the first PropertyGroup as that causes DesignTimeBuild issues: https://github.com/dotnet/project-system/issues/6143
+
+1. Use an equality check if the TargetFramework isn't overloaded with the OS portion.
+Example:
+```
+<PropertyGroup>
+  <TargetFrameworks>netstandard2.0;netstandard2.1</TargetFrameworks>
+</PropertyGroup>
+<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">...</ItemGroup>
+```
+2. Use a StartsWith when you want to test for multiple .NETStandard or .NETFramework versions.
+Example:
+```
+<PropertyGroup>
+  <TargetFrameworks>netstandard2.0;netstandard2.1</TargetFrameworks>
+</PropertyGroup>
+<ItemGroup Condition="$(TargetFramework.StartsWith('netstandard'))>...</ItemGroup>
+```
+3. Use a StartsWith if the TargetFramework is overloaded with the OS portion.
+Example:
+```
+<PropertyGroup>
+  <TargetFrameworks>netstandard2.0-Windows_NT;netstandard2.0-Unix</TargetFrameworks>
+</PropertyGroup>
+<ItemGroup Condition="$(TargetFramework.StartsWith('netstandard2.0'))>...</ItemGroup>
+```
+4. Use negations if that makes the conditions easier.
+Example:
+```
+<PropertyGroup>
+  <TargetFrameworks>netstandard2.0;net461;net472;net5.0</TargetFrameworks>
+</PropertyGroup>
+<ItemGroup Condition="!$(TargetFramework.StartsWith('net4'))>...</ItemGroup>
+<ItemGroup Condition="'$(TargetFramework)' != 'netstandard2.0'">...</ItemGroup>
+```
+
+## Directory layout
+
 Library projects should use the following directory layout.
 
 ```
@@ -121,7 +161,7 @@ The output for the ref project build will be a flat targeting pack folder in the
 ## src
 In the src directory for a library there should be only **one** `.csproj` file that contains any information necessary to build the library in various target frameworks. All supported target frameworks should be listed in the `TargetFrameworks` property.
 
-All libraries should use `<Reference Include="..." />` for all their project references. That will cause them to be resolved against a targeting pack (i.e. `bin\ref\netcoreapp5.0` or `\bin\ref\netstanard2.0`) based on the project target framework. There should not be any direct project references to other libraries. The only exception to that rule right now is for partial facades which directly reference System.Private.CoreLib and thus need to directly reference other partial facades to avoid type conflicts.
+All libraries should use `<Reference Include="..." />` for all their project references. That will cause them to be resolved against a targeting pack (i.e. `bin\ref\net5.0` or `\bin\ref\netstanard2.0`) based on the project target framework. There should not be any direct project references to other libraries. The only exception to that rule right now is for partial facades which directly reference System.Private.CoreLib and thus need to directly reference other partial facades to avoid type conflicts.
 <BR>//**CONSIDER**: just using Reference and use a reference to System.Private.CoreLib as a trigger to turn the other References into a ProjectReference automatically. That will allow us to have consistency where all projects just use Reference.
 
 ### src output