PackageReference for NetStandard projects

[b-anand]

Today when authoring csproj files which depend on different set of packages we have the option of adding the TargetFramework condition as mentioned here: https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#adding-a-packagereference-condition

This means that when user targets multiple frameworks in their csproj with PackageReferences which differ across the TargetFrameworks then the final nuget package will contain binaries which were compiled with different set of dependencies.

This leads to problems when we mix .NetStandard packages in the mix. For example let's take the below scenario.

ClientSdk project: is compiled for .net46 and .netstandard. The nuget dependencies across the different framework version of the ClientSdk.dll is different. They could even be same nuget package with different version numbers (with breaking changes). ClientSdk nuget is an external nuget which we need to pull from nuget.org.

Util project: is compiled for .netstandard since we want to share it with both .net core and .net fx scenarios. This is local project which consumes the ClientSdk nuget from nuget.org. It will compile with the .netstandard version of ClientSdk.dll

NetFx exe project: is compiled for framework >= .net46. This is local project and it references the Util project and by transitive closure the build of this project will pull in the ClientSdk nuget but will choose the .net46 version of ClientSdk.dll.
This will cause issues in runtime since the Util project tries to load different version of ClientSdk.dll with different dependency versions.

Proposal:
One of the following options can be implemented:

1. Allow PackageReference element to choose the target framework version as proposed here: How do I force myProject Choose .NetStandard assembly instead of TargetFramework dotnet/sdk#1791
2. Treat NetStandard projects as special when doing the dependency graph analysis for PackageReferences i.e. during the dependency graph check, if we find one of the versions of external nuget has to be .net standard (since current project is .netstandard like the Util project above) then we choose .netstandard version for the final resolution.

[leecow]

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275