Aspnetcore: .NET Core 2.1.1 SDK 2.1.301 Implicitly References Microsoft.NETCore.App 2.1.0

[rockerinthelocker]

@coolcsh , In order to work around, add

<PackageReference Include="Microsoft.NETCore.App" Version="2.1.1" />

to the project file like so:

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.NETCore.App" Version="2.1.1" />
</ItemGroup>

[natemcmaster]

This behavior is intentional. Your application will still run in .NET Core 2.1.1 if it is installed on your machine, without you needing to adjust your PackageReference.

See https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#implicit-package-references for more details.

[rockerinthelocker]

@natemcmaster , @coolcsh , Thanks, but that won't work. The problem is that without explicitly referencing 2.1.1, 2.1.0 is implicitly referenced (see below) when publishing the app. Of course, the production server does not have the 2.1.0 packages... Beside that, related 2.1.0 packages are downloaded to the developer box if only the 2.1.1 SDK is installed. Well! If the 2.1.0 SDK is not installed, it's certainly for a reason...

webapp.deps.json snippet without explicitly referencing 2.1.1.

  "targets": {
    ".NETCoreApp,Version=v2.1": {
      "WebApplication1/1.0.0": {
        "dependencies": {
          "Microsoft.AspNetCore.App": "2.1.1",
          "Microsoft.NETCore.App": "2.1.0"
        },
        "runtime": {
          "WebApplication1.dll": {}
        },
        "compile": {
          "WebApplication1.dll": {}
        }
      },
      "Microsoft.NETCore.App/2.1.0": {
        "dependencies": {
          "Microsoft.NETCore.DotNetHostPolicy": "2.1.0",
          "Microsoft.NETCore.Platforms": "2.1.0",
          "Microsoft.NETCore.Targets": "2.1.0",
          "NETStandard.Library": "2.0.3"
        },

webapp.deps.json snippet with explicitly referencing 2.1.1.

  "targets": {
    ".NETCoreApp,Version=v2.1": {
      "WebApplication1/1.0.0": {
        "dependencies": {
          "Microsoft.AspNetCore.App": "2.1.1",
          "Microsoft.NETCore.App": "2.1.1"
        },
        "runtime": {
          "WebApplication1.dll": {}
        },
        "compile": {
          "WebApplication1.dll": {}
        }
      },
      "Microsoft.NETCore.App/2.1.1": {
        "dependencies": {
          "Microsoft.NETCore.DotNetHostPolicy": "2.1.1",
          "Microsoft.NETCore.Platforms": "2.1.0",
          "Microsoft.NETCore.Targets": "2.0.0",
          "NETStandard.Library": "2.0.3"
        },

Obviously, this is not the desired and expected behavior.

[rockerinthelocker]

Also, as shown above, Microsoft.NETCore.App/2.1.1 has a dependency on Microsoft.NETCore.Targets 2.0.0 while Microsoft.NETCore.App/2.1.0 takes Microsoft.NETCore.Targets 2.1.0.

[dsplaisted]

It's still not clear to me what the problem is here. A framework-dependent app targeting .NET Core 2.1 is supposed to depend on Microsoft.NETCore.App 2.1.0. If it's published as a self-contained app, then it is supposed to depend on the latest patch (ie 2.1.1). This is described here: https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection

[rockerinthelocker]

@dsplaisted , If the 2.1.1 SDK depends on Microsoft.NETCore.App 2.1.0, for what is Microsoft.NETCore.App 2.1.1 showing up in Nuget Package Manager good for? One might expect that the 2.1.1 SDK references Microsoft.NETCore.App 2.1.1 instead of downloading and referencing Microsoft.NETCore.App 2.1.0. No?

[dsplaisted]

@rockerinthelocker Normally NuGet package manager won't show an update available to this package. In the Installed packages list, it looks like this:

If you have explicitly added a PackageReference to your project for this package, then you will get an upgrade offered, but it is not recommended to have that PackageReference, and indeed you will get a warning suggesting you remove it:

NETSDK1023: A PackageReference for 'Microsoft.NETCore.App' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see https://aka.ms/sdkimplicitrefs

[rockerinthelocker]

Thanks for taking the time, but this is going nowhere. If the 2.1.1 SDK depends on the 2.1.0 version of Microsoft.NETCore.App, and blocks installation of the current 2.1.1 version, you tell developers there's nothing wrong with? @coolcsh , Do you get it?

[dsplaisted]

By default, we decided that Framework-dependent deployments would not depend on the latest patch. This is because they will roll forward to the latest patch available on the machine, so when the machine running the app is updated to the latest patch, the app will run with that patch. However, if we made them depend on the latest patch, then the app would fail to run on machines that hadn't been updated with the latest patch.

In the 1.x timeframe, we did depend on the latest patch, and that broke apps that deployed to cloud hosting providers that had not yet updated the version of .NET Core on their platforms when folks updated to the newer tools. That's why we changed how it works.

If you really do want your Framework-dependent deployment to depend on the latest patch, you can do so by setting the TargetLatestRuntimePatch property to true.

In addition to the Self-contained deployment roll-forward document I already linked, see this design doc for more background and details about how and why this works.

[rockerinthelocker]

@dsplaisted , As long as the latest patch version installed on the production server is used, all should be fine with framework-dependent deployments, but this whole thing is confusing developers because

1) Nuget Package Manager shows there's a newer patch version, but blocked by the project even if the related SDK is installed, and
2) the webapp.deps.json shows a dependency on the replaced version of Microsoft.NETCore.App; and as per https://docs.microsoft.com/en-us/dotnet/core/deploying/#framework-dependent-deployments-fdd, one would assume it would take Microsoft.NETCore.App 2.1.0 (if installed) instead of 2.1.1 on the production server. Of course, that would be an issue.

At least, the documentation and Nuget Package Manager should properly reflect how things will work in the end, which is not the case at the moment.

Thanks again for taking the time to shed some light on this! Much appreciated!