Show assemblies within shared framework targeting packs

[dsplaisted]

For .NET Core 3.0, we will be using targeting packs to deliver references for shared frameworks.

We've discussed that we would like these to be displayed in the solution explorer dependencies tree, something like this:

Dependencies
    Frameworks
        Microsoft.NETCore.App
            System.Runtime.dll
            System.Collections.Generic.dll
            ...
        Microsoft.WindowsDesktop.App
            System.Windows.Forms.dll
            ...

We'll need to decide what metadata should be set on these references to indicate which shared framework they are a part of, add that metadata in the SDK, and modify the project system to populate the dependencies tree based on that data.

[dsplaisted]

FYI @davidwengier @Pilchie

[drewnoakes]

Has some overlap with #4362.

[cartermp]

This should be mostly covered by #4362 but it's good to have this be a distinct issue. We currently went with "references" as the name, but that's definitely up for discussion. As far as how they're displayed, the tree view that we have today for packages-that-are-really-shared-framework-references looks like it already has the desired structure.

[jjmew]

Tracked by AB#827445

[drewnoakes]

@dsplaisted how do you envisage this working in the case that two FrameworkReferences bring in the same reference?

[dsplaisted]

Conflict resolution should choose the reference that's used, and that reference should have metadata on it that indicates which shared framework it came from.

Another case is when there are multiple framework references referring to different profiles of the same shared framework. I'd suggest displaying that like this:

• Microsoft.WindowsDesktop.App
  • WindowsForms
    • System.Windows.Forms.dll
    • ...
  • WPF
    • System.PresentationFramework
    • ...
  • Microsoft.Win32.Registry.dll
  • ...

[drewnoakes]

This is very similar to #1413. I commented there:

Another approach to achieve the same result would be to visit the targeting pack on disk and discover the assemblies there directly and add them as graph nodes.

This data could be cached across all projects in the solution, allowing graph node reuse.

This might potentially provide less metadata on those referenced assemblies.

[dsplaisted]

Another approach to achieve the same result would be to visit the targeting pack on disk and discover the assemblies there directly and add them as graph nodes.

This would mean re-implementing the logic to understand targeting packs, which currently lives in the ResolveTargetingPackAssets task in the SDK.

A possibility would be to move the logic to understand targeting packs into MSBuild itself, as APIs that the project system could call. It does something similar with the reference assemblies in Program Files for .NET Framework, and we will probably be adding some understanding of the new targeting packs to MSBuild as part of dotnet/designs#81

[vritant24]

This addition to the project system would help improve the experience for fro Fakes in .NET Core. In .NET Framework, a user can right click on an assembly reference like System.Core or System.Net.HTTP to generate a fakes assembly, but this isn't possible in a .NET Core project. Without this, currently there isn't a good experience in generating a fakes assembly for the assemblies that are shipped with the SDK.
Would this be slated for 16.7, it would be the best way to move to supporting Fakes in .NET Core as it keeps the experience the same.
tagging @AbhitejJohn