Do not negotiate TargetFramework for ProjectReferences when explicit override is specified

[rainersigwald]

Today, if you want to explicitly pick the TargetFramework of a ProjectReference, you must specify two metadata values:

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

But SkipGetTargetFrameworkProperties is redundant: if SetTargetFramework is set, we can assume that we shouldn't do the negotiation.

See dotnet/project-system#477 (comment) (cc @nguerrera)

[dasMulli]

Btw I've been telling ppl to set AdditionalProperties="TargetFramework=..." (Slack / StackOverflow) - how bad is/was that?
That way the targets that the negotiation calls into always returned the proper values since they considered the project to be single-TFM anyway.

[rainersigwald]

It's slightly less specific than SetTargetFramework, and harder to detect for a case like this, but otherwise works the same, I think. The side effect of forcing the reference into its inner build and sidestepping the outer-build negotiation is interesting. It might even be better that way, though right now I think I prefer the explicit approach.

[nguerrera]

I think this used to work and is what these lines are trying to do:

https://github.com/Microsoft/msbuild/blob/05151780901c38b4613b2f236ab8b091349dbe94/src/Tasks/Microsoft.Common.CurrentVersion.targets#L1619-L1623

[rainersigwald]

Yes, you're totally right. How can it have been a long week like 2 hours into the first day?