2.1.302 SDK, but AspNetCore.App only downloads 2.1.1 instead of 2.1.2

[scottsauber]

Hello, not really sure where to put this so I'm starting here.

On two different machines, I'm unable to get the AspNetCore.App package with no explicit version number to download 2.1.1 instead of 2.1.2.

This is on a dotnet new and is happening on two different machines. On one of them, I even uninstalled all older SDK's other than 2.1.302.

Am I doing something wrong?

Screenshots:

[davidfowl]

What does dotnet —info show?

[scottsauber]

@davidfowl - on this machine it's

.NET Core SDK (reflecting any global.json):
Version: 2.1.302
Commit: 9048955601

Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.302\

Host (useful for support):
Version: 2.1.2
Commit: 811c3ce6c0

.NET Core SDKs installed:
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.300 [C:\Program Files\dotnet\sdk]
2.1.301 [C:\Program Files\dotnet\sdk]
2.1.302 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[davidfowl]

Believe it or not, this is working as expected. At runtime, you'll be running on 2.1.2 but the compile time version is set to 2.1.1.

[natemcmaster]

This is a great question and one of the user experience problems we are trying to address. The root of the problem is that Microsoft.AspNetCore.App does not follow normal PackageReference behavior, but that is not obvious from the reading the project file.

FWIW - one idea we have to resolve this is to remove this PackageReference altogether (see #3307). It's my hunch that by removing the PackageReference altogether, we can help reset expectations about what this package actually does.

[scottsauber]

Believe it or not, this is working as expected. At runtime, you'll be running on 2.1.2 but the compile time version is set to 2.1.1.

@davidfowl - My mind is a little blown reading this. So if there was a new class/method/property/something introduced in 2.1.2, would I even be able to access that at design time? Seems like that would be no?

FWIW - one idea we have to resolve this is to remove this PackageReference altogether (see #3307).

@natemcmaster - Yeah that would be really good actually. Things are just a little goofy with the Runtime Store now where things can blow up at run time if the destination server has a lower version than your NuGet package.

My knee jerk reaction to having the Package Ref version be implicit was the fact that in full framework, I only had to worry about the framework version being not in my complete control, and now I have to worry about the framework + the NuGet packages and figuring out what version is running what might be a little tricky. But, really, it's been that way anyways since 2.1 (with the version number being omitted) and after thinking about it, it seems best if everything just becomes an implicit version all together like Change 1 has. Just sharing my knee jerk reaction in case others hit the same initial hurdle.

Change 2 is a little confusing though, because by looking at your library's csproj or your consuming app's dependency graph in VS, it's not super obvious that 2.1.0 will auto-roll forward to 2.1.2 or whatever. Wish we could do something like MinimumVersion="2.1.0" or npm's ~ or something.

You just want us all on Docker, huh? 😄

[rockerinthelocker]

@scottsauber , Because framework-dependent deployment and its implicit versioning (including roll forwarding) may cause quite a few issues (see https://docs.microsoft.com/en-us/dotnet/core/versions/selection#framework-dependent-apps-roll-forward for some examples) if you have no control over runtime versions installed on the production server (i.e. shared hosting), consider self-contained deployment instead. Sure, it is not pretty to have all DLLs in the Web root folder, but it is the only option available to ensure that the application works as expected no matter what runtime versions are installed on the production server. In the worst case, framework-dependent deployment may expose your application to security vulnerabilities -- even if compiled with the latest SDK addressing such vulnerabilities --, if not the patch version addressing the vulnerabilities is installed on the production server (your application will happily run with previous vulnerable patch versions)! Unfortunately, you may not notice until it is too late.

[davidfowl]

@davidfowl - My mind is a little blown reading this. So if there was a new class/method/property/something introduced in 2.1.2, would I even be able to access that at design time? Seems like that would be no?

We don't add public APIs in patches.

[scottsauber]

In the worst case, framework-dependent deployment may expose your application to security vulnerabilities

Sure, it's possible your server has a lower patch than your intended one, but to me, one of the biggest wins with framework-dependent deployments is the security patch model. If you have 10 apps on a single server and they all share the same framework, one install gets all the security patches with no re-deploys of the existing apps.

Whereas with self-contained deployments, you have to touch and re-deploy all 10 apps to get all the latest security fixes.

Seems like it's way easier to have the latest patches with the framework-dependent model vs. the self-contained model.

[scottsauber]

I'm going to close this, since this appears to be working as intended, @natemcmaster and @davidfowl.