Remove EnsureNETCoreAppRuntime target from future Microsoft.NETCore.App releases

[nguerrera]

Follow up bug based on discussion with @ericstj yesterday:

Wtih dotnet/sdk#1857, this target will not run because (as a perf optimization) RunResolvePackageDependencies is skipped most of the time.

The PR moves the spirit of the check in to the SDK. The heuristic there is that least one package in the RID graph that is not in the RID-agnostic graph. It can be enabled via a property $(EnsureRuntimePackageDependencies). For backwards compitibility, we turn it on for .NETCoreApp TFMs (as long as the existing escape hatch, $(EnsureNETCoreAppRuntime) from target above is not false. If there are new TFMs that want to enable the same check, they can set EnsureRuntimePackageDependencies=true in their meta-package.

@ericstj @eerhardt

[ericstj]

This is tracking removing our target and just setting a property that tells the SDK to do the check.

[livarcocc]

@ericstj and @nguerrera is core-setup the right repo for this issue?

[nguerrera]

Yes, because the source is in this repo:

https://github.com/dotnet/core-setup/blob/a0b82c4ec4a5186d1ecf611503bd075a308be7c6/src/pkg/projects/Microsoft.NETCore.App/Microsoft.NETCore.App.targets

It is not an urgent issue, though.

[livarcocc]

This target is actually not owned by the CLI/SDK team and is owned I believe by the corefx team. I will remove the area-SDK tag and let that team triage it appropriately.

[nguerrera]

There's no need for this to be in 2.1. The target is benign when left behind. Removing milestone.

[karelz]

@nguerrera please set milestone to Future in such cases. Thanks!

@livarcocc @nguerrera @steveharter can you please work out the new area path? Who owns the target file? (https://github.com/dotnet/core-setup/blob/master/Documentation/project-docs/issue-guide.md#areas)

[eerhardt]

I added to this area-Infrastructure, since it is part of building the Microsoft.NETCore.App package, and that's where the other issues for the Microsoft.NETCore.App package live.

[dagood]

Closing: since there's no need for this change in 2.1 and in 3.0+ we don't use nuget packages to acquire the framework, this doesn't seem necessary anymore.