Represent FrameworkReference of transitive projects and packages in the deps.json file.

[NTaylorMullen]

Today transitive project/package references aren't properly represented in a deps.json. For instance given this project (Bug4332 is a web app, Bug4332RCL is a Razor class library, both targeting netcoreapp3.0):

Today you get the following Bug4332.deps.json entry for Bug4332RCL:

      "Bug4332RCL/1.0.0": {
        "runtime": {
          "Bug4332RCL.dll": {}
        },
        "compile": {
          "Bug4332RCL.dll": {}
        }
      },

The min-bar expectation would be for the deps.json to look something like:

      "Bug4332RCL/1.0.0": {
        "dependencies": {
          "Microsoft.AspNetCore.App": "3.0.0-preview-18579-0056"
        },
        "runtime": {
          "Bug4332RCL.dll": {}
        },
        "compile": {
          "Bug4332RCL.dll": {}
        }
      },

This is blocking a core scenario in ASP.NET Core MVC 3.0 of having Razor views in a class library.

Lastly, I imagine this issue depends on the completion of the following (please correct me if i'm wrong):

• Referencing a shared framework does not flow across ProjectReference Referencing a shared framework does not flow across ProjectReference #2420
• Represent FrameworkReferences in NuGet packages and assets files Represent FrameworkReferences in NuGet - pack & restore support NuGet/Home#7342

@livarcocc @dsplaisted @natemcmaster @mkArtakMSFT @rynowak

[livarcocc]

@dsplaisted @nguerrera want to make sure that framework composition accounts for this.

[nguerrera]

Of course this has to be handled in the changes we have planned, but it's strange that it's already broken because today a FrameworkReference still becomes a standard package reference. It's unclear to me what is different enough from 2.x to cause this. We should make sure we understand that and not just tie this to composition.

[dsplaisted]

ASP.NET switched to discovering which assemblies should be scanned at build time, and encoding that information in assembly attributes, and as such no longer need the FrameworkReferences to be encoded in the deps.json. So we are going to close this, and can revisit it if we encounter another scenario where this would be needed.