Reconsider implicitly using the latest patch version of the targeted version of .NET Core in the SDK

[dsplaisted]

From @eerhardt:

The issue is someone upgrades their SDK on their developer machine, which brings in the latest patch version (1.1.1 in this case) and then publishes their app to their host machine. The host machines aren't updated to 1.1.1, because it just got released and these things take time. Now the app breaks on a host machine because 1.1.1 isn't installed.

See more comments/discussion on #860.

UPDATE: The current plan of record is now:

• The implicit framework version is not updated with each new SDK (even if it includes newer runtimes (patch version)). This makes apps with newer SDKs compatible to a larger set of environments. The implicit framework version always stays as at the “.0” patch
• Self-contained apps are published with the latest patch version (same as “run” case) unless specifically configured.

More details and discussion can be found here: https://github.com/dotnet/designs/issues/3

When targeting .NET Core 1.x, the 2.0 SDK should continue to roll forward to at least the latest patch that the 1.x SDK rolls forward to, in order to have consistent behavior between the two SDKs.

This means that there's not any concrete work needed to support the new policy until a patch version of 2.0 ships.

[dsplaisted]

My suggestion would be that instead of using RuntimeFrameworkVersion to specify a patch version of the runtime to use, we just use the TargetFramework. IE, to target 1.1.1:

<TargetFramework>netcoreapp1.1.1</TargetFramework>

Then if we wanted to target 1.1.1 by default, we could just do that in the default template, and it's a lot more obvious to simply retarget to 1.1 than to have to set the RuntimeFrameworkVersion property.

[normj]

Alternatively if the patch version is going to implicit to the latest whether the user is ready for it or not should the dotnet execution of the application be more lenient and look for the closet matching runtime and not just fail if the exact version isn't found?

[normj]

Pinging on this. I see more work going on for the implicit versioning but I don't understand how this is sustainable. Unless every .NET Core hosting environment, whether on premise or in a Cloud provider, can instantly update as soon as a new patch version is release this will continue to cause deployment pain.

Are there plans to make the implicit versioning to latest patch version for netcoreapp frameworks and latest major/patch version for netstandard libraries more discover-able?

[dsplaisted]

@normj I think the work you're probably seeing for implicit versioning is what we're doing for preview versions of the .NET Core Shared Framework. Would you expect hosting environments to provide a preview version of the shared framework?

The reason for the work we're doing for the preview versions of the shared framework is so that you don't have to hard code something like <RuntimeFrameworkVersion>2.0.0-beta-001507</RuntimeFrameworkVersion> in your project.

As for the non-preview policy of rolling forward to the latest patch version in the SDK, I don't have any update yet.

[Petermarcu]

FWIW, I hope to not overload the TFM to include patch versions. I think apps running on a shared framework should only declare the major.minor and have a more advanced knob if they for some reason depend on a patch version.

For apps that pull the runtime app local, they should probably get the latest that came with the SDK they are using. @eerhardt is going to provide more input but it is definitely a scenario we need to cover. Devs should be able to get the latest SDK and still, by default, be able to publish apps and run against a major.minor.

[eerhardt]

I think the high-level strategy I am landing on here is:

1. For applications running on the shared framework, I express my dependency on the platform through a TFM (netcoreapp1.1). By default, unless I specify otherwise, I should run on whichever patch version of that framework someone has installed. Ex. My app will run on any 1.1.x that is installed on the machine.
   1. The host will automatically roll-forward to the latest installed patch version, as it does today.
2. For self-contained apps where the platform is with my app, by default I will get the latest runtime patch version that comes with the SDK I used to publish my app. This keeps my application up to date and secure when I use the latest SDK.

From an implementation perspective, what this means to me is:

• The implicit PackageReference to Microsoft.NETCore.App uses the latest patch version that comes with the SDK. <PackageReference Include=”Microsoft.NETCore.App” Version="1.1.1" />
• For self-contained apps, it will use the runtime assemblies from the referenced version (i.e. 1.1.1).
• For shared framework apps, we will generate a runtimeconfig.json to say version=1.1.0 by default.

This means is we will use the latest NuGet package to build the app in all cases. But shared fx apps can run on any runtime that supports the specified TFM (netcoreapp1.1 in this case).

A place where this gets tricky is "How do we give the dev all the right knobs, but still keep it simple?"

I could see having 2 separate .csproj properties:

1. Which version of Microsoft.NETCore.App do you want to reference?
2. What is the minimum patch version of the shared fx do you want your app to run on?
   a. In the case where we ship a behavior change from 1.1.0 to 1.1.1, and the dev wants to say “this app cannot run on 1.1.0 because of the behavior change”

Or we could continue using the 1 property we have today: <RuntimeFrameworkVersion>. If the project explicitly has it set, use that version for both the PackageReference and to put in the runtimeconfig.json. Otherwise, use the defaults as outlined above.

[dsplaisted]

Having a different version in the runtimeconfig.json for shared framework apps than for the NuGet package or for the runtimeconfig.json for a self-contained app worries me a bit. However, it does seem like it might be the best trade-off.

As far as having the right knobs, I really hope that a developer having to think about which version of the Microsoft.NETCore.App package should be referenced would be an extremely rare occurrence. I'm also not really happy with the way the RuntimeFrameworkVersion property works today. Someone may set it to 1.1.0 today so that their app will run on AWS, for example, and then when 2.0 is released they could retarget to netcoreapp2.0, but if they don't delete the RuntimeFrameworkVersion property then they will end up with a broken app that doesn't run. That's why I suggested just using the TargetFramework property to specify the patch version. Another option could be to have a property that only specifies the patch version, and is appended to the version which comes from the TargetFramework. So to target 1.1.0 instead of 1.1.1, you would set the TargetFramework to netcoreapp1.0, and the new property (RuntimeFrameworkPatchVersion or something) to just 0.

[eerhardt]

or for the runtimeconfig.json for a self-contained app

There is no version in the runtimeconfig.json for self-contained apps. The presence of a name and version in this file is what tells the host if the app is self-contained or not.

So to target 1.1.0 instead of 1.1.1, you would set the TargetFramework to netcoreapp1.0, and the new property (RuntimeFrameworkPatchVersion or something) to just 0.

This doesn't solve the same problem you list for RuntimeFrameworkVersion. If I'm on netcoreapp1.0, and I want to target 1.0.3, I would set RuntimeFrameworkPatchVersion = 3. Then when I moved to netcoreapp1.1 and didn't delete this property, my app breaks.

[dsplaisted]

This doesn't solve the same problem you list for RuntimeFrameworkVersion. If I'm on netcoreapp1.0, and I want to target 1.0.3, I would set RuntimeFrameworkPatchVersion = 3. Then when I moved to netcoreapp1.1 and didn't delete this property, my app breaks.

Yes, but my thought is that it probably breaks with a better error experience where you can understand what's happening and fix it.

[richlander]

Here's an idea:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework targetRuntime="2.0.3" minRuntime="2.0.0">netcoreapp2.0</TargetFramework>
  </PropertyGroup>

</Project>

There are a few ideas here:

• Carry these extra declarations with the target framework since they are coupled, as suggested.
• The declarations don't have to be pretty since they are intended to be atypical.
• targetRuntime is the runtime you are targeting that satisfies the target framework. By default, this is the runtime that the SDK implicitly specifies but can be overridden, as we see above.
• minRuntime is the minimum runtime that the app will accept on the production machine. By default this is the .0 patch. We would only update this to >0 if we find something bad in .0 (or higher).

[Petermarcu]

I like the coupling with the TargetFramework. I have a few suggestions/comments:

• targetRuntime would need to be able to be resolved to a full package including prerelease versions of packages. So it can't be just a normal version string. It needs to support the 2.0.0-preview2-004353.00 type strings.
• I'm not sure about minRuntime. The first two parts need to match. We don't roll forward across major or minor. I think only overriding the 3rd part here is interesting and should probably just be called minPatchVersion or something like that.
• This should only be done for 2.0+

[richlander]

On targetRuntime, yes. The value should just be a string. That doesn't preclude your scenario..

On minRuntime, I'm less sure. What's the "third part" in your preview2 example? I think that fully-qualified version numbers are easier to understand. You are correct that there is an inherent relationship between the two. That said, one could argue that there is a similar relationship with the TFM.

There is a question of what should happen if targetRuntime is missing. Is this also a min version?