additionalDeps downgrades shared runtime library

[pakrym]

Steps to reproduce

1. dotnet new web
2. mkdir deps
3. set yourdir\deps\shared\Microsoft.NETCore.App\2.1.0-preview2-26308-01\a.deps.json (modify runtime framework version to be the one referenced in .dotnet\x64\shared\Microsoft.AspNetCore.App\2.1.0-preview2-xxxxx\Microsoft.AspNetCore.App.runtimeconfig.json app references)

{
  "runtimeTarget": {
    "name": ".NETCoreApp,Version=v2.1.0",
    "signature": "5e814c43a4bb318be73c818ca300cacedf418e91"
  },
  "compilationOptions": {},
  "targets": {
    ".NETCoreApp,Version=v2.1.0": {
      "Microsoft.AspNetCore.Hosting.Abstractions/2.0.0": {
        "dependencies": {
          "Microsoft.AspNetCore.Hosting.Server.Abstractions": "2.0.0",
          "Microsoft.AspNetCore.Http.Abstractions": "2.0.0",
          "Microsoft.Extensions.Configuration.Abstractions": "2.0.0",
          "Microsoft.Extensions.DependencyInjection.Abstractions": "2.0.0",
          "Microsoft.Extensions.FileProviders.Abstractions": "2.0.0",
          "Microsoft.Extensions.Hosting.Abstractions": "2.0.0",
          "Microsoft.Extensions.Logging.Abstractions": "2.0.0"
        },
        "runtime": {
          "lib/netstandard2.0/Microsoft.AspNetCore.Hosting.Abstractions.dll": {}
        }
      }
    }
  },
  "libraries": {
    "Microsoft.AspNetCore.Hosting.Abstractions/2.0.0": {
      "type": "package",
      "serviceable": true,
      "sha512": "sha512-836NSTzCM1r1tgCRw92y2/TOKVI8HC0ahh+SDer4oMNwuk7LYgSayjQ3rYHDpQDAaGCMF8vFjFphhRECc9Xtog==",
      "path": "microsoft.aspnetcore.hosting.abstractions/2.0.0",
      "hashPath": "microsoft.aspnetcore.hosting.abstractions.2.0.0.nupkg.sha512"
    }
  }
}

4. Set $env:DOTNET_ADDITIONAL_DEPS="yourdir\deps"
5. dotnet run

Expected behavior

App runs fine because deps file does not override app

Actual behavior

App crashes with

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.AspNetCore.Hosting.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at depsydeps.Program.Main(String[] args)

Because library got resolved to C:\Program Files\dotnet\store\x64\netcoreapp2.1\microsoft.aspnetcore.hosting.abstractions\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Abstractions.dll

Environment data

Confirmed on hostxr built from latest preview/2.1 source and 2.1.0-preview2-26314-02

@steveharter
/cc @glennc @muratg

[steveharter]

Note that https://github.com/dotnet/core-setup/issues/3546 may help with this feature, as it will pick the "highest" version of each assembly based on new assemblyVersion and fileVersion metadata in the deps.json files. This new feature is supported by the host, but the metadata is not yet being written by the SDK.

[steveharter]

If the additional deps.json do not want to "upgrade" the app or framework versions of the same assemblies, then either they don't add the assemblyVersion\fileVersion metadata to the deps.json, or we change the host to treat additional deps file differently.

[steveharter]

Closing this as addressed by #2994 which is expected to be in by 2.1 release.

[pakrym]

But is it addressed? As you said there Yes framework wins will occur only during roll-forward of minor. it's not what's happening here.
Additional deps should never be able to downgrade dependencies, no matter app-fx relationship.

[steveharter]

The PR has not yet been pushed: dotnet/sdk#2118

When this is in, and the framework deps.json file is generated with version numbers, I will verify the behavior. The fx will "win" over any app or additional deps.json file that doesn't have version numbers, or have older version numbers.

[pakrym]

What about only during roll-forward of minor part?

[steveharter]

I see. I was thinking this was a minor roll-forward. Re-opening.

If we change this behavior for additional-deps (assuming for both folder-version and individual deps modes), wouldn't that be considered a breaking change? Would additional-deps ever want to override (either upgrade or downgrade) the framework's versions?

[pakrym]

Upgrades are semi-fine, but having additional deps downgrade anything at all is a recipe for disaster.

[steveharter]

@pakrym shouldn't the versions in the additional-deps (in the folder hierarchy with a "2.1.x" folder) be the same (or newer) than the framework version they targeted?

Is the desire to ship the same additional deps for both 2.0.x and 2.1.x?

[steveharter]

Or could the example above target AspNetAll\AspNetApp instead of NetCoreApp (for 2.1 anyway)?

[steveharter]

I understand that the additional-deps may be older than the "found" version of the framework (whether or not it rolled forward on major\minor\patch) because of the proposed roll-backwards functionality, but in this particular example the major.minor of the additional deps is the same as the framework, correct?

[pakrym]

This sample is just a sample, in the real life, it can happen because of 2.0->2.1 roll forward.

[karelz]

Fixed in release/2.1 in PR dotnet/core-setup#4094.