Resolved project and package references in some cases are faulty

[sanmuru]

Issue Description

Suppose there is a Main project reference a multi-targeting Lib project, and to every Lib project's target framework, there are other different projects and packages referenced by Lib. The result is build success but run fail.
The dependencies that copy to local are faulty.

Steps to Reproduce

I put a similar sample in sanmuru/MSBuild-bug.

• Console(Main) project reference CoreLib(Lib) project with SetTargetFramework="TargetFramework=netstandard2.0".
• CoreLib(Lib) project reference Net462UtilLib project and System.Text.Json package when targeting net462.
• CoreLib(Lib) project reference NetStandard20UtilLib project and Newtonsoft.Json package when targeting netstandard2.0.
• Build result shows Console(Main) project do reference the correct output assembly (and its dependencies) which from NetStandard20UtilLib project, but as well copy output assembly from Net462UtilLib project and System.Text.Json package instead of Newtonsoft.Json package to local.

Expected Behavior

No idea whether it is a feature or a bug, if it is a bug then fix it, or crash build process if it is a feature.

Versions & Configurations

.NET Runtime: 7.0.200-preview.22628.1

[sanmuru]

May related:

It looks like this SetTargetFramework ignored if project references a multitarget project via another project.
Originally posted by @AndirNotes in dotnet/sdk#2280

PackageReference with condition not being referenced by child project when multi-targeting
Opened by @yiwwan in dotnet/sdk#16611

It is confusing to remain this bug/feature unsolved for years.

[JanKrivanek]

@sanmuru - Adding

<PropertyGroup>
  <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>
</PropertyGroup>

Into your Console project should help workaround the issue with the unwanted build of leaf projects (and placing of their outputs to the referencing project output).

Issue here is that ResolveProjectReferences is trying to process all dependencies - including the transitive ones, one doesn't properly honor the SetTargetFramework in the process. Disabling the transitive processing should help here.

As for the nuget resolution issue - this falls into scope of nuget - I'm filing issue with them: NuGet/Home#12436.
I currently do not have better workaround for this other then adding the conditioned package references to the Console project as well.

[JanKrivanek]

@sanmuru - is there a specific reason why you force the netstandard2.0 lib reference instead of the net462?

By removing the SetTargetFramework altogether, the project and package reference will be properly resolved on copied (net462 will be chosen in this case as better match).

You just need to adjust your implicit usings in this case (as the feature was tailored for net6 and onwards - see dotnet/sdk#24146). So the root Console project would look like:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net481;net462</TargetFrameworks>
    <ImplicitUsings>enable</ImplicitUsings>
    <LangVersion>latest</LangVersion>
  </PropertyGroup>
  
  <ItemGroup>
	<Using Remove="System.Net.Http" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\CoreLib\CoreLib.csproj" />
  </ItemGroup>
</Project>

[sanmuru]

Well, in actual case, my CoreLib target net35 and netstandard2.0 (and more TFM but it does not matter here) and my Console target net35 and net462. What I want is net35->net35 and net462->netstandard2.0.

I want to use asynchronous programming in CoreLib but as you know there is no TAP in net35, so I install TaskParallelLibrary (official package provided by Microsoft, achived by community). Soon I find it difficult to use that there are no essential types which support async/await features for compiler. So I create a new TFM netstandard2.0 and force all Console's TFMs other than net35 to reference netstandard2.0.

The IDE I use is Visual Studio latest preview. During code typing in Console, Version=net462, there are diagnostics show missing reference (System.Threading.dll, Version=1.0.2856.102) which is exactly the one in TaskParallelLibrary package. Then they disappear after I SetTargetFramework=netstandard2.0. So I believe that at lease Roslyn works correct.

Then I find this issue: build success but run fail with a System.IO.FileNotFoundException: Could not load file or assembly 'X' or one of its dependencies.

Actualy I can do things in a better way, but the bug is still there right?

[JanKrivanek]

@sanmuru Yes - issue is still present - more precisely 2 issues (project references resolution and packages references resolution).
Timing of fixing of those is subject to prioritization, right now I'm trying to propose viable workaround(s):

The MSBuild bug (transitive project reference resolution issue when restricting multitargeted references) has a workaround with setting DisableTransitiveProjectReferences which forces proper project references resolution in this case

The Nuget dependecies resolution behavior cannot be currently tweaked (as per NuGet/Home#12436) - so the best option is to add the needed references (conditioned) to the root project as well.

Would those options help mitigate the problem in your case?

[AR-May]

Team triage: msbuild and sdk are pulling the relevant information from NuGet, so NuGet/Home#12436 is the correct issue to pursue for a fix.