Set the runtime framework version based on the target framework version

[dsplaisted]

...instead of defaulting to the version of the Microsoft.NETCore.App package reference

Some of the changes in #450 were based on the belief that a PackageReference could be set as ReadOnly to prevent the UI from offering updates to it. I am not sure how I got the impression that this had been finished, as right now it is still only a feature proposal: NuGet/Home#4044

This means that currently updates for the Microsoft.NETCore.App package reference will be offered in the package manager UI, and if an app targets netcoreapp1.0 but updates to use version 1.1.0 of the package, that the app will compile against .NET Core 1.0 but declare a dependency on .NET Core 1.1 in its runtimeconfig.json file. This PR:

• Sets the runtime framework version based on the target framework version instead of the version of the Microsoft.NETCore.App package that is referenced
• References version 1.1.0 of the Microsoft.NETCore.App package by default for all projects. This means that updates won't be offered for new projects, hopefully reducing confusion about the difference between the target framework version and the version of the package referenced.

[dsplaisted]

Tagging @ericstj, @weshaggard, @nguerrera, @srivatsn, @natidea

[nguerrera]

I recall @ericstj hitting more than incorrect runtime version in json with the TFM and package mismatch, but can't find the details right now.

Has corefx made a deliberate call that the path forward is to support old TFM in new packages or (as I was getting the impression) to disable that moving forward?

Does the version of the package you reference at compilation time have any impact on LTS support level or is it purely a function of the bits you use at runtime?

Do we have adequate test coverage for both standalone and portable apps for this?

[dsplaisted]

I recall @ericstj hitting more than incorrect runtime version in json with the TFM and package mismatch, but can't find the details right now.

I think this is what you're referring to: https://github.com/dotnet/corefx/issues/14696#issuecomment-269707955. I believe this will also fix that type of issue.

[ericstj]

Just to be clear, I don't think CoreFx is the owner of POR here. I think we need some PMs to sign off on what we want the behavior to be when you use an old TFM with a newer NETCore.App package. As has been shown current SDK behavior of assuming sharedFramework == package version and allowing the old TFM assets to go app-local is broken. One fix is to derive shared framework version from TFM and allow the user or some package to override it: that's what this change does. /cc @terrajobst @blackdwarf @piotrpMSFT

[dsplaisted]

I've incorporated these changes (slightly modified based on discussion) into #633