Add Support: Enable installing Full .Net Framework from within netstandad 2 ,netcore 2 library project by option

[moh-hassan]

Scenario:
With the release of netcore2, netstandard2, we can reference from within these projects any full framework package in disk (dll) and gain of the 70% of available nuget package which is net45 ready.

As an example, for a nuget package named "nuget_package" having net40, net45 and netstandard1.3, the net45 is a full feature package and netstandard1.3 is a less feature one and we want to add net45 (the full feature) to our netstandard2/netcore2 library project.

when we run the command:

	install-package nuget_package 

nuget install the nearest compatible library which is netstandard1.3 and add the following xml entry to the csproj:

	  <ItemGroup>
		  <PackageReference Include="nuget_package" Version="x.y.z" />
	  </ItemGroup>

To get all feature of net45 package which isn't in netstandard1.3, We have to uninstall the package and reference manually the net45 by browsing to the dll location of net45 package in disk.

My Suggestion:

Add an option in the PackageReference, e.g. TFM which enable installing the net45 with its dependency in these projects
something like:

    <ItemGroup>
        <PackageReference Include="full_net_framework" Version="x.y.z" TFM="net45" />
    </ItemGroup>

Modify the command by adding TFM option:

      install-package nuget_package  -TFM=net45

TFM values: net45, net46 , net461 (which cover API surface of netstandard2/netcore2)

In this way:

-Gain from 70% of the available nuget package which cover same API of netstandard2 but not migrated yet.
-Avoid manual installation of the package.

Insure the transitive dependency in deps.json file.
You can provide the warning "This package may not be fully compatible with your project"

Why we need this scenario
Quote from Announcing .NET Core 2.0

You can now reference .NET Framework libraries from .NET Standard libraries using Visual Studio 2017 15.3. This feature helps you migrate .NET Framework code to .NET Standard or .NET Core over time (start with binaries and then move to source). It is also useful in the case that the source code is no longer accessible or is lost for a .NET Framework library, enabling it to be still be used in new scenarios.

We expect that this feature will be used most commonly from .NET Standard libraries. It also works for .NET Core apps and libraries. They can depend on .NET Framework libraries, too.

The supported scenario is referencing a .NET Framework library that happens to only use types within the .NET Standard API set. Also, it is only supported for libraries that target .NET Framework 4.6.1 or earlier (even .NET Framework 1.0 is fine).

[emgarten]

This is an interesting scenario. If the project is netstandard2.0 then netstandard1.3 is the best match. Overriding the TFM selected from the package causes all sorts of complications when a different set of dependencies is needed.

To fix this the package should be updated to support netstandard2.0 and ideally that would contain the APIs you are expecting from net45 in the updated API surface area.

The fallback to desktop framework is intended for allowing legacy packages to work which will never be updated to support netstandard. For packages which do support netstandard1.x it is expected that they will be updated to support netstandard2.x.

[moh-hassan]

Sure, updating TFM to netstandard2.0 is the ideal solution. But updates depends on the owner of the packages and may take a time to be netstandard2 ready.
Currently, in sdk project:
enable references to any assembly on disk is supported in vs2017.3
dll reference support in .NET Core projects

Announcing .NET Core 2.0 open the door for referencing .NET Framework libraries (even .NET Framework 1.0 is fine)

Most of these TFM packages are 95+% ready for netstandard2 by .NET Portability Analyzer

[rrelyea]

@emgarten is right...we need to push package authors to get all the way to netstandard 2.0.
we'll keep this idea in mind, but right now it doesn't seem like something we can/should do.
Thanks for the feedback/idea.