Transitive dependency items not attached for all target frameworks when multi-targeting

[drewnoakes]

Following the merge of PR #6712 (which fixed several bugs) we see some package and project reference nodes not having their children populated for multi-targeting projects. That PR changed the representation of the target we store on these items, which is now no longer understood by the code that attaches these children.

We are no longer parsing the TargetFramework dimension to produce a sanitised version for external consumption. Internally this works well enough as an opaque identifier, however it breaks when we communicate that information externally, in this case to the code in NuGet.Client that populates descendents of package and project references.

The fix is likely to capture whatever property values we need information from the ConfiguredProject and pass that throughout the system in our TargetFramework class. There are some rough edges here that will make this challenging and require careful thought.

[drewnoakes]

The fix may also address these issues:

• Dependency node doesn't handle Multi-targeting with a multi portable frameworks  #2524
• Remove all concepts of "target framework" and that configurations are driven from them #2525
• Dependencies node fails to handle custom target frameworks #2618
• Remove concept of "short name" in TargetFramework #2795
• Dependency node does not handle configuration switches #3642

[drewnoakes]

When a project is multi-targeting, the code in NuGet.Client that attaches transitive dependency information to dependency nodes must determine which target each item belongs to.

This doesn't work correctly for certain target framework kinds today.

Given:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>net472;net481;netcoreapp3.1;netstandard2.1;net5.0;net6.0;net7.0</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MetadataExtractor" Version="2.8.0" />
  </ItemGroup>

</Project>

We see:

Only net5.0, net6.0 and net7.0 have children attached. The others are not expandable, indicating attachments failed.

The reason for this is inconsistent treatment of the target identifier in the project.assets.json file:

These are two different kinds of values, which makes this mapping difficult. Perhaps we need to store both the alias and the TFM on the target node, so the NuGet code can try and find either. Or NuGet could settle on a single identifier in this file. Or something else.

The JSON file does have, under project.restore:

So perhaps it could map these back, however they appear in a different order, and I can't see any other way in the data model to do that mapping such that we have only a single kind of identifier.

[drewnoakes]

TODO investigate any relationship to NuGetTargetMoniker.

[drewnoakes]

Another scenario to test:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>net35;net35-client</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup Condition="'$(TargetFramework)' == 'net35-client'">
    <TargetFrameworkIdentifier>.NETFramework</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
    <TargetFrameworkProfile>Client</TargetFrameworkProfile>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MetadataExtractor" Version="2.8.0" Condition="'$(TargetFramework)' == 'net35-client'" />
  </ItemGroup>

</Project>

[drewnoakes]

Another case of this is specifying net6.0-windows in the project file, and the assets file using net6.0-windows7.0 instead.

[zivkan]

@drewnoakes assuming the assets file was parsed with NuGet.ProjectModel (and therfore LockFileFormat.Read), you can find the TFM "alias" under assetsFile.PackageSpec.TargetFrameworks[]. This list contains objects of type TargetFrameworkInformation where you can use string TargetAlias to match the TargetFramework from the project, then use NuGetFramework FrameworkName to get the parsed framework object. Then, you use that to match == assetsFile.Targets[x].TargetFramework (and you might also want to check string.IsNullOrEmpty(target.RuntimeIdentifier), but I think the no RID target should always be first.

Note that API might change when NuGet/Home#5154 is implemented

If you're not parsing with NuGet.ProjectModel, look at json path $/project/frameworks[]/targetAlias. This will definitely change when the feature is implemented

[drewnoakes]

Thanks @zivkan. That was really helpful. I filed NuGet/NuGet.Client#5507 which fixes this issue.

Note that API might change when NuGet/Home#5154 is implemented

That's fine, as the code is in the NuGet.Client solution so will be included in any refactoring there.