ToolLocationHelper.GetSupportedTargetFrameworks/GetPathToReferenceAssemblies are not aware of .NET Core

[debonte]

Issue Description

ToolLocationHelper.GetSupportedTargetFrameworks and ToolLocationHelper.GetPathToReferenceAssemblies provide information about installed .NET Framework, UWP, and Silverlight frameworks, but not installed .NET Core frameworks.

Steps to Reproduce

On machine with .NET Core 3.1 installed, call:

• ToolLocationHelper.GetSupportedTargetFrameworks();
• ToolLocationHelper.GetPathToReferenceAssemblies(new FrameworkName(".NETCoreApp", new Version(3, 1)));

Expected Behavior

GetSupportedTargetFrameworks() returns a collection that includes .NETCoreApp,Version=v3.1.
GetPathToReferenceAssemblies returns a collection of paths to directories containing ,NET Core 3.1 reference assemblies.

Actual Behavior

GetSupportedTargetFrameworks() returns a collection that does not include any .NETCoreApp framework names.
GetPathToReferenceAssemblies returns an empty collection.

Versions & Configurations

Visual Studio 16.8.0 Preview 4.0 (main 30515.42)

[debonte]

@davkean

[rainersigwald]

What's the use case here? There are a bunch of differences in the build process between .NET (Core) and .NET Framework, and I don't think these APIs make sense in the new world. In particular, there's not really a single "reference assemblies" concept any more--things are resolved from targeting packs but also from NuGet packages, and having just "what's known to the current .NET Core SDK" returned here is likely insufficient.

[debonte]

I'm looking at updating Visual Studio's Choose Toolbox Items dialog to support WPF and WinForms .NET Core controls. At a high-level, the way it works today is:

1. Enumerate installed frameworks
2. Enumerate reference assemblies for each framework supported by Choose Toolbox Items (ex. Silverlight is ignored)
3. Enumerate control types in those reference assemblies

@davkean knows of other scenarios where this type of info is needed. I believe dotnet/project-system#4873 covers some of them.

[davkean]

We can't even ask a very basic question of "can I use type X if I target Y?" where Y is a possible target. Regardless of whether these types come from packages/references/whatever there should a central place that can answer that question. It shouldn't up to each individual feature to hard code what is, what isn't available in .NET Core and how to add the right reference to add said type.

I see this no different to UWP where types come from a location different to the reference assemblies, and ToolLocationHelper has full support for it for extension and platform sdks.

[dreddy-work]

Trying to get traction on this. We are seeing increasing customer reports seeking Visual Studio's Choose Toolbox Items dialog support for Winforms (and I assume WPF too) .NET projects.

@rainersigwald / @benvillalobos , any updates to this request?