Merge and fix bug inside of workload command parser from another pr that allowed null ref exception

Author: nagilson

CODEOWNERS

@@ -66,10 +66,10 @@
 /src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ClickOnce.targets @sujitnayak
 
 # Area-Watch
-/src/Assets/TestProjects/Watch*/     @tmat @arkalyanms
-/src/Tests/dotnet-watch.Tests/       @tmat @arkalyanms
+/src/Assets/TestProjects/Watch*/     @tmat @arkalyanms @dotnet/roslyn-ide
+/src/Tests/dotnet-watch.Tests/       @tmat @arkalyanms @dotnet/roslyn-ide
 /src/Tests/Microsoft.AspNetCore.Watch.BrowserRefresh.Tests/       @dotnet/aspnet-blazor-eng
-/src/BuiltInTools/*   @tmat @arkalyanms
+/src/BuiltInTools/*   @tmat @arkalyanms @dotnet/roslyn-ide
 /src/BuiltInTools/BrowserRefresh   @dotnet/aspnet-blazor-eng
 
 # ApiCompat tools owned by runtime team

README.md

@@ -47,6 +47,10 @@ Please see the [Pull Request Timeline Guide](documentation/project-docs/SDK-PR-g
 
 With the SDK repository being the home for many different areas, we've started trying to label incoming issues for the area they are related to using `Area-` labels.  Then we rely on the [codeowners](https://github.com/dotnet/sdk/blob/main/CODEOWNERS) to manage and triages issues in their areas. Feel free to contact the owners listed in that file if you're not getting a response on a particular issue or PR. Please try to label new issues as that'll help us route them faster.
 
+For issues related to the central SDK team, typically they are assigned out to a team member in the first half of each week. Then each member is asked to review and mark those needing further discussion as "needs team triage" and otherwise setting a milestone for the issue. Backlog means we will consider it in the future if there is more feedback. Discussion means we have asked for more information from the filer. All other milestones indicate our best estimate for when a fix will be targeted for noting that not all issues will get fixed. If you are not getting a quick response on an issue assigned to a team member, please ping them.
+
+The example query used for triage of .NET SDK issues can be viewed [here](https://github.com/dotnet/sdk/issues?q=is%3Aissue+is%3Aopen+-label%3AArea-NuGet+-label%3AArea-format+-label%3AArea-implicitusings+-label%3AArea-SourceBuild+-label%3AArea-Host+-label%3AArea-NativeAOT+-label%3AArea-readytorun+-label%3AArea-websdk+-label%3AArea-watch+-label%3AArea-illink+-label%3AArea-aspnetcore+-label%3AArea-compatibility+-label%3A%22Area-dotnet+test%22+-label%3AArea-FSharp+-label%3AArea-GenAPI+-label%3AArea-ApiCompat+label%3Auntriaged+no%3Amilestone+no%3Aassignee+)
+
 For PRs, we assign a reviewer once a week on Wednesday, looking only at PRs that are green in the build.  If you are contributing:
 
 * Get the PR green.

build/RunTestsOnHelix.cmd

@@ -30,6 +30,7 @@ dotnet new --debug:ephemeral-hive
 
 REM We downloaded a special zip of files to the .nuget folder so add that as a source
 dotnet nuget list source --configfile %TestExecutionDirectory%\nuget.config
+PowerShell -ExecutionPolicy ByPass "dotnet nuget locals all -l | ForEach-Object { $_.Split(' ')[1]} | Where-Object{$_ -like '*cache'} | Get-ChildItem -Recurse -File -Filter '*.dat' | Measure"
 dotnet nuget add source %DOTNET_ROOT%\.nuget --configfile %TestExecutionDirectory%\nuget.config
 
 dotnet nuget remove source dotnet6-transport --configfile %TestExecutionDirectory%\nuget.config

documentation/specs/runtime-configuration-file.md

@@ -127,11 +127,11 @@ The files are both JSON files stored in UTF-8 encoding. Below are sample files.
 
 This section is created when building a project. Settings include:
 * `configProperties` - Indicates configuration properties to configure the runtime and the framework
-  * Examples:    
-    * Full list of [configuration properties](https://github.com/dotnet/docs/blob/main/docs/core/run-time-config/index.md) for CoreCLR. 
+  * Examples:
+    * Full list of [configuration properties](https://github.com/dotnet/docs/blob/main/docs/core/runtime-config/index.md) for CoreCLR.
     * `System.GC.Server` (old: `gcServer`) - Boolean indicating if the server GC should be used (Default: `true`).
     * `System.GC.Concurrent` (old: `gcConcurrent`) - Boolean indicating if background garbage collection should be used.
-* `framework` - Indicates the `name`, `version`, and other properties of the shared framework to use when activating the application including `applyPathes` and `rollForwardOnNoCandidateFx`. The presence of this section (or another framework in the new `frameworks` section) indicates that the application is a framework-dependent app.
+* `framework` - Indicates the `name`, `version`, and other properties of the shared framework to use when activating the application including `applyPatches` and `rollForwardOnNoCandidateFx`. The presence of this section (or another framework in the new `frameworks` section) indicates that the application is a framework-dependent app.
 * `applyPatches` - When `false`, the most compatible framework version previously found is used. When `applyPatches` is unspecified or `true`, the framework from either the same or a higher version that differs only by the patch field will be used. See [roll-forward-on-no-candidate documentation](https://github.com/dotnet/core-setup/blob/main/Documentation/design-docs/roll-forward-on-no-candidate-fx.md) for more information.
 * `rollForwardOnNoCandidateFx` - Determines roll-forward behavior. Only applies to `production` releases. Values: 0(Off), 1 (roll forward on [minor] or [patch]), 2 (Roll forward on [major], [minor] or [patch])
  See [roll-forward-on-no-candidate documentation](https://github.com/dotnet/core-setup/blob/main/Documentation/design-docs/roll-forward-on-no-candidate-fx.md) for more information.
@@ -143,7 +143,7 @@ These settings are read by host (apphost or dotnet executable) to determine how
 
 ### `compilationOptions` Section (`.deps.json`)
 
-This section is created during build from the project's settings. The exact settings found here are specific to the compiler that produced the original application binary. Some example settings include: `defines`, `languageVersion` (e.g. the version of C# or VB), `allowUnsafe` (a C# option), etc.  
+This section is created during build from the project's settings. The exact settings found here are specific to the compiler that produced the original application binary. Some example settings include: `defines`, `languageVersion` (e.g. the version of C# or VB), `allowUnsafe` (a C# option), etc.
 This section is ignored by the runtime host. It is only potentially used by the application itself.
 
 ### `runtimeTarget` Section (`.deps.json`)
@@ -152,8 +152,8 @@ This property contains the name of the target from `targets` that should be used
 
 ### `targets` Section (`.deps.json`)
 
-Each property under `targets` describes a "target", which is a collection of libraries required by the application when run or compiled in a certain framework and platform context. A target **must** specify a Framework name, and **may** specify a Runtime Identifier. Targets without Runtime Identifiers represent the dependencies and assets which are platform agnostic. These targets can also represent dependencies and assets which are used for compiling the application for a particular framework. Targets with Runtime Identifiers represent the dependencies and assets used for running the application under a particular framework and on the platform defined by the Runtime Identifier.  
-In the example above, the `.NETCoreApp,Version=v2.1` target lists the dependencies and assets used to run and compile the application for `netcoreapp2.1`.  
+Each property under `targets` describes a "target", which is a collection of libraries required by the application when run or compiled in a certain framework and platform context. A target **must** specify a Framework name, and **may** specify a Runtime Identifier. Targets without Runtime Identifiers represent the dependencies and assets which are platform agnostic. These targets can also represent dependencies and assets which are used for compiling the application for a particular framework. Targets with Runtime Identifiers represent the dependencies and assets used for running the application under a particular framework and on the platform defined by the Runtime Identifier.
+In the example above, the `.NETCoreApp,Version=v2.1` target lists the dependencies and assets used to run and compile the application for `netcoreapp2.1`.
 If the app was published specifically for 64-bit Mac OS X 10.10 machine, it would also contain a target `.NETCoreApp,Version=v2.1/osx.10.10-x64` which would list the dependencies and assets used to run the application on that specific platform.
 
 There will always at least one target in the `[appname].deps.json` file: the platform neutral list of runtime and compilation dependencies. In cases of a platform specific application there would be two targets: a compilation target, and a runtime target. The compilation target will be named with the framework name used for the compilation (`.NETCoreApp,Version=v2.1` in the example above). The runtime target will be named with the framework name and runtime identifier used to execute the application (`.NETCoreApp,Version=v2.5/osx.10.10-x64` in the example above). However, the runtime target will also be identified by name in the `runtimeOptions` section, so that the host does not need to parse and understand target names.
@@ -205,20 +205,20 @@ This section is only present in the root framework's (so `Microsoft.NETCore.App`
 
 The file is read by two different components:
 
-* The host uses it to determine what to place on the TPA and Native Library Search Path lists, as well as what runtime settings to apply (GC type, etc.). 
+* The host uses it to determine what to place on the TPA and Native Library Search Path lists, as well as what runtime settings to apply (GC type, etc.).
 * `Microsoft.Extensions.DependencyModel` uses it to allow a running managed application to query various data about it's dependencies. For example:
   * To find all dependencies that depend on a particular package (used by ASP.NET MVC and other plugin-based systems to identify assemblies that should be searched for possible plugin implementations)
   * To determine the reference assemblies used by the application when it was compiled in order to allow runtime compilation to use the same reference assemblies (used by ASP.NET Razor to compile views)
   * To determine the compilation settings used by the application in order to allow runtime compilation to use the same settings (also used by ASP.NET Razor views).
 
 ## Opt-In Compilation Data
 
-Some of the sections in the `.deps.json` file contain data used for runtime compilation. This data is not provided in the file by default. Instead, an MSBuild property `PreserveCompilationContext` must be set to `true` (typically in the project file) in order to ensure this data is added. Without this setting, the `compilationOptions` will not be present in the file, and the `targets` section will contain only the runtime dependencies.  
+Some of the sections in the `.deps.json` file contain data used for runtime compilation. This data is not provided in the file by default. Instead, an MSBuild property `PreserveCompilationContext` must be set to `true` (typically in the project file) in order to ensure this data is added. Without this setting, the `compilationOptions` will not be present in the file, and the `targets` section will contain only the runtime dependencies.
 Note that ASP.NET projects (those using `Microsoft.NET.Sdk.Web` SDK) has this property set to `true` by default.
 
 ## Framework-dependent Deployment Model
 
-An application can be deployed in a "framework-dependent" deployment model. In this case, the RID-specific assets of packages are published within a folder structure that preserves the RID metadata. However the host does not use this folder structure, rather it reads data from the `.deps.json` file. 
+An application can be deployed in a "framework-dependent" deployment model. In this case, the RID-specific assets of packages are published within a folder structure that preserves the RID metadata. However the host does not use this folder structure, rather it reads data from the `.deps.json` file.
 
 In the framework-dependent deployment model, the `*.runtimeConfig.json` file will contain the `runtimeOptions.framework` section:
 
@@ -356,46 +356,46 @@ In addition to specifying a dependency on more than one framework, the `framewor
 
 Overriding a value is always "most restrictive". This means if `applyPatches` is already `false` in a lower-level framework, then it cannot be changed to `true`. For `rollForwardOnNoCandidateFx` the value 0=off is the most restrictive, then 1=minor\patch, then 2=major\minor\patch. For `version`, the highest version requested will be used.
 
-As an example of overriding settings, assume the following framework layering: 
-- Application 
-- Microsoft.AspNetCore.All 
-- Microsoft.AspNetCore.App 
-- Microsoft.NetCore.App 
+As an example of overriding settings, assume the following framework layering:
+- Application
+- Microsoft.AspNetCore.All
+- Microsoft.AspNetCore.App
+- Microsoft.NetCore.App
 
-Except for Microsoft.NetCore.App (since it does not have a lower-level framework), each layer has a runtimeconfig.json setting specifying a single lower-layer framework's `name`, `version` and optional `rollForwardOnNoCandidateFx` and `applyPatches`. 
+Except for Microsoft.NetCore.App (since it does not have a lower-level framework), each layer has a runtimeconfig.json setting specifying a single lower-layer framework's `name`, `version` and optional `rollForwardOnNoCandidateFx` and `applyPatches`.
 
-The normal hierarchy processing for most knobs, such as `rollForwardOnNoCandidateFx`: 
- - a) Default value determined by the framework (e.g. roll-forward on [Minor]) 
- - b) Environment variable override (e.g. `DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX`) 
- - c) Each layer's `runtimeOptions` override setting in its runtimeconfig.json, starting with app (e.g. `rollForwardOnNoCandidateFx`). Lower layers can override this. 
+The normal hierarchy processing for most knobs, such as `rollForwardOnNoCandidateFx`:
+ - a) Default value determined by the framework (e.g. roll-forward on [Minor])
+ - b) Environment variable override (e.g. `DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX`)
+ - c) Each layer's `runtimeOptions` override setting in its runtimeconfig.json, starting with app (e.g. `rollForwardOnNoCandidateFx`). Lower layers can override this.
  - d) The app's `frameworks` section in `[appname].runtimeconfig.json` which allows knobs per-framework.
- - e) A `--` command line value such as `--roll-forward-on-no-candidate-fx` 
-
-In a hypothetical example, `Microsoft.AspNetCore.App` references version `2.2.0` of `Microsoft.NetCore.App` in `Microsoft.AspNetCore.App.runtimeconfig.json`: 
-```json 
-{ 
-    "runtimeOptions": { 
-        "framework": { 
-            "name": "Microsoft.NetCore.App", 
-            "version": "2.2.0" 
-        }, 
-     } 
-} 
+ - e) A `--` command line value such as `--roll-forward-on-no-candidate-fx`
+
+In a hypothetical example, `Microsoft.AspNetCore.App` references version `2.2.0` of `Microsoft.NetCore.App` in `Microsoft.AspNetCore.App.runtimeconfig.json`:
+```json
+{
+    "runtimeOptions": {
+        "framework": {
+            "name": "Microsoft.NetCore.App",
+            "version": "2.2.0"
+        },
+     }
+}
 ```
-However, if the app requires the newer version `2.2.1` of `Microsoft.NetCore.App`, then mechanism `d` is used. An example of the `frameworks` section for mechanism `d` in the app's `runtimeconfig.json`: 
-```json 
-{ 
-    "runtimeOptions": { 
-        "framework": { 
-            "name": "Microsoft.AspNetCore.All", 
-            "version": "1.0.1" 
-        }, 
-        "frameworks": [ 
-            { 
-                "name": "Microsoft.AspNetCore.App", 
+However, if the app requires the newer version `2.2.1` of `Microsoft.NetCore.App`, then mechanism `d` is used. An example of the `frameworks` section for mechanism `d` in the app's `runtimeconfig.json`:
+```json
+{
+    "runtimeOptions": {
+        "framework": {
+            "name": "Microsoft.AspNetCore.All",
+            "version": "1.0.1"
+        },
+        "frameworks": [
+            {
+                "name": "Microsoft.AspNetCore.App",
                 "version": "2.2.1",
-            } 
-        ] 
-    } 
-} 
+            }
+        ]
+    }
+}
 ```

eng/SourceBuild.props

@@ -3,7 +3,9 @@
   <PropertyGroup>
     <GitHubRepositoryName>sdk</GitHubRepositoryName>
     <SourceBuildManagedOnly>true</SourceBuildManagedOnly>
+    <SourceBuildTrimNetFrameworkTargets>true</SourceBuildTrimNetFrameworkTargets>
   </PropertyGroup>
+
   <Target Name="ConfigureInnerBuildArg" BeforeTargets="GetSourceBuildCommandConfiguration">
     <PropertyGroup>
       <InnerBuildArgs>$(InnerBuildArgs) /p:Projects="$(InnerSourceBuildRepoRoot)\source-build.slnf"</InnerBuildArgs>