Specify which target framework you want to use from a dependency

[davkean]

From @JamesNK on September 14, 2016 0:32

With project.json there is no way to specify the target framework you want to use from a dependency. It is automatically chosen for you. I would like a way to specify this manually.

For example I have MyLibrary that has netstandard1.0 and netstandard1.1 frameworks.

I want to be able to explicitly say which framework I use from MyLibrary in another project that will run unit tests. That way I can run tests against the netstandard1.0 assembly and netstandard1.1 assembly.

Copied from original issue: dotnet/project-system#477

[davkean]

Great suggestion. @nguerrera Can we put some metadata on the reference to influence this?

[davkean]

From @nguerrera on September 14, 2016 16:20

Sure! With dotnet/msbuild#1018, we ask the dependency's project for the properties that configure it to best match. We can change this to honor SetTargetFramework metadata that you already set on the reference. So it's trivial for project-to-project refs. Do we need parity for package refs?

[davkean]

From @benaadams on May 23, 2018 8:52

This is also useful; for example currently a net452 package will always take prescience over a netstandard2.0 for net471. However may want to force the netstandard2.0 package as it uses newer apis etc

[rainersigwald]

You can do this today for p2ps with

    <ProjectReference Include="..\multitargeted_lib\multitargeted_lib.csproj">
      <SetTargetFramework>TargetFramework=netstandard2.0</SetTargetFramework>
    </ProjectReference>

I agree with @nguerrera that we should imply SkipGetTargetFrameworkProperties from the presence of a SetTargetFramework: dotnet/msbuild#3356

Overriding the TF of a NuGet package is a request for NuGet which I vaguely recall has gotten some pushback from the NuGet team, but I couldn't find a NuGet bug for it.

Edit: removed reference to SkipGetTargetFrameworkProperties to avoid confusing folks in the future.

[nguerrera]

Note that dotnet/msbuild#3356 is closed and it is already redundant to specify SkipGetTargetFrameworkProperties=true if you've specified SetTargetFramework.

[benaadams]

Have this issue with corert dotnet/corert#5720 using a netcorapp2.1 package that uses Reflection.Emit will cause it to choke (in native compilation); whereas forcing that package onto netstandard2.0 that doesn't use Emit will work - however the csproj/sdk doesn't allow you to override the framework for an individual package so it will always choke.