Implicit Package Reference to NetCoreApp 1.0.4, 1.1.1

[TheRealPiotrP]

In PR dotnet/cli#5673 we will be moving the in-box frameworks in CLI to 1.0.4 and 1.1.1. We should update the implicit package reference in the SDK to reference the same. I wonder if we should make these versions externally configurable so that the invoking IDE can force the SDK to match what is available.

/cc @dsplaisted @srivatsn

[eerhardt]

In general, I'm not sure this is the correct approach to continue with. See

http://stackoverflow.com/questions/42726198/dotnet-build-to-specific-framework-version/
http://stackoverflow.com/questions/42736264/build-asp-net-core-application-to-target-dot-net-core-framework-1-1-0/

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.

Instead, if we left the implicit package reference to 1.0.0 and 1.1.0, the app will run on any machine that has those frameworks. And when the patch version is applied to the host machine, the latest patch will automatically get picked up. Even if the runtimeconfig.json says 1.1.0, if 1.1.1 is installed, 1.1.1 will be used.

[dasMulli]

The nice thing about the automatic upgrade is that self contained apps will use the latest framework that is available. However, this also means shipping a new SDK for each patch version..

It would be nice if there was a way to reference the 1.1.1 NuGet but generate a runtimeconfig for 1.1.0. This of course then interferes with manually adding package references to M.N.App and specifying floating or specific preview versions.

Maybe something radically different could be done here - ship a msbuid props file in the Microsoft.NETCore.App package that sets the RuntimeFramework property (or sth else) and have the SDK always emit a 1.1.* reference? That way the knowledge about the host policy and probably also support policy can be moved from the SDK to the actual framework. And new patch versions would become available for self-contained apps quickly.

[normj]

The implicit package reference is very problematic for hosting providers and the customers that use them. For example at AWS we have support for .NET Core as a deployment target but when new versions of .NET Core come out it takes time to test and verify it before we can make it available for customers. This new implicit behavior breaks any customer that updates to Visual Studio 2017 unless they know to edit the csproj file to set the RuntimeFrameworkVersion.

For this cycle to happen for each new release of .NET Core gives a poor experience for .NET Core developers. To me it also breaks the idea that installing a new version of .NET Core should not break any existing applications which I believed was one of the goals of .NET Core - this potentially breaks build machines when a new version comes out.

[dsplaisted]

Discussions on closed pull requests are likely to fall off the radar, so I've filed #983 for further discussion.

[eerhardt]

This isn't a PR - it is an issue asking for this behavior....

But we can continue the discussion on #983.

[dsplaisted]

@eerhardt Oops, you're right, the PR was #878.