RuntimeFrameworkVersion for 3.0 apps

[natemcmaster]

Filing on behalf of @DamianEdwards @davidfowl

It appears the RuntimeFrameworkVersion property is no longer honored in netcoreapp3.0 projects. If our recollection is correct, the plan was to use this property so customers could define the versions used by FrameworkReference.

Open question: how to handle the difference between shared framework versions. After RTM, we should (in theory) always patch all in-box shared frameworks. But during per-release, however, these versions will rarely align.

[nguerrera]

@dsplaisted

[nguerrera]

I think we should consider honoring metadata on FrameworkReference of some kind. You could then use Update in msbuild to set it. I think this mostly comes up internally where we want to mix different daily builds vs official releases where the defaults are what you want. We should look at usage of RuntimeFrameworkVersion to validate that. If so, I don't think this needs to be any friendlier than that.

You also probably want control over the targeting pack version and the runtime pack version independently too. For example, there won't necessarily be a 3.0.n targeting pack, but you might want to force 3.0.n runtime pack if 3.0.(n+1) accidentally broke you. But in prerelease the api changes all the time so you want control over the targeting pack too.

[dsplaisted]

Sounds good. Note that ASP.NET shouldn't be blocked today, you should be able to do something like the following to select a specific version of the runtime and targeting packs:

<ItemGroup>
    <KnownFrameworkReference Update="Microsoft.AspNetCore.App">
        <TargetingPackVersion Condition="'%(TargetFramework)' == 'netcoreapp3.0'">3.0.0-preview-myversion</TargetingPackVersion>
        <DefaultRuntimeFrameworkVersion Condition="'%(TargetFramework)' == 'netcoreapp3.0'">3.0.0-preview-myversion</DefaultRuntimeFrameworkVersion>
        <LatestRuntimeFrameworkVersion Condition="'%(TargetFramework)' == 'netcoreapp3.0'">3.0.0-preview-myversion</LatestRuntimeFrameworkVersion>
    </KnownFrameworkReference>
</ItemGroup>

[davidfowl]

@dsplaisted Yes, it's horrific

[dsplaisted]

@davidfowl What scenarios is this necessary in? Does the ugliness need to go in normal customer projects, or is it mainly just for ASP.NET Core internal repos?

[davidfowl]

For us wanting to use CI builds. So we can test the product before ask mode 😬

[dsplaisted]

@natemcmaster @davidfowl This is fixed in #2887.

You can set the RuntimeFrameworkVersion metadata on a FrameworkReference and it will apply to only that shared framework, or you can use the property and it will apply to all shared frameworks (that don't have the metadata on the FrameworkReference).

If neither of those are set, then you can set TargetLatestRuntimePatch, either as metadata on a given FrameworkReference, or as a property to apply to all shared frameworks, to control whether the shared frameworks roll forward to the latest patch.