Restore should support SetTargetFramework on ProjectReference

[JanKrivanek]

NuGet Product Used

dotnet.exe

Product Version

7.0.200-preview.22628.1

Worked before?

N/A

Impact

It's more difficult to complete my work

Repro Steps & Context

When running restore for a project referencing a multitargeted project with conditioned package dependencies:

<ItemGroup Condition="'$(TargetFramework)' == 'net462'">
    <PackageReference Include="System.Text.Json" Version="*" />
</ItemGroup>

<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
    <PackageReference Include="Newtonsoft.Json" Version="*" />
</ItemGroup>

And restricting the framework via SetTargetFramework="TargetFramework=netstandard2.0" in referencing project, the resulting project.assets.json looks like if conditions were evaluated inversely (it contains only System.Text.Json). In fact the restore leads to same result regardles of the SetTargetFramework presence and it's value.

The full sample is located here sanmuru/MSBuild-bug - taken from dotnet/msbuild#8405

Verbose Logs

No response

[nkolev92]

Hey @JanKrivanek

There are quite a few issues linked and I want to make sure I'm understanding the report.

The referencing projects wants to restrict the target framework for the project selected, but its most compatible framework is something else?

I'm guessing the reference project is .NET Framework based?

SetTargetFramework is not something that's ever been supported by NuGet. The framework chosen is always going to be the best compatible one.

[JanKrivanek]

Thank you @nkolev92 yes - that's correct.

While most compatible framework is different from the choice expressed via SetTargetFramework, not honoring this during restore, but honoring it during the build leads to a discrepancy leading to nonrunnable outputs. So I'd see it as a bug (and possibly have this open for doc purposes, unless/untill it's documented elsewhere)

On the other hand it sounds like it would express itself only in scenarios where user is enforcing TFM choice, that is not optimal and hence it should have easy workaround (by adjusting their SetTargetFramework choice, or removing it alltogether). For this reason I'd see this as a low priority.

[nkolev92]

Hey @JanKrivanek
Do you mind if we repurpose this issue as a feature ask for NuGet to potentially respect SetTargetFramework?

I'd say that the behavior today is what we'd expect it to be as maintainers, so this would have to be a new feature.
Doesn't mean we would do, but that we need an issue tracking that ask.

[JanKrivanek]

@nkolev92 - This is fair from my point of view (especially as there seems to be workaround).
Please review scenario dotnet/msbuild#8405 (comment) (by @sanmuru) which shows possible case where user TFM choice might be relevant - just in case it would alter the decision process about type of the ask.