[DCR]: Dependent project does not generate nuget package when multiple TFMs

NuGet Product(s) Affected

dotnet.exe

Current Behavior

Note that I first raised this issue in the msbuild repository but it was suggested to me this should rather belong here. So Here it goes.

Consider this scenario:

Lib1.csproj multi-targets net48 and net6.0 and has GeneratePackageOnBuild set to true
Lib2.csproj does the same
Lib1.csproj references Lib2.csproj (both are part of the same solution)

Now, let's dotnet build Lib1.csproj:

It generates Lib2 assemblies (one for each target),
It genrates Lib1 assemblies (one for each target)
It generates Lib1 nupkg
It does not generate Lib2 nupkg though

NB: this does not happen when building the solution in VS

Desired Behavior

Lib2.nupkg should be generated

I understand it is probably not straightforward, but according to the least surprise principle, I think it'd be desirable.

Additional Context

Steps to Reproduce

See attached solution: MultipleTfmsNugetRepro.zip
Then:
```
cd .....\Lib1
dotnet build
```
Lib1.nupkg is created in Lib1\bin\Debug
Lib2.nupkg is not Lib2\bin\Debug

I also attached the corresponding binlog (build in release configuration this time): binlog.zip

Analysis

I've skimmed through the binlog and I think it boils down to IsInnerBuild = truepreventing Lib2's nuget package from being generated. Here is what I guess happens:

Because Lib1 is a multi-targeting project, it is split into 2 pseudo-projects: one for each TFM
Thanks to the project reference, each one of these pseudo-projects transitively builds Lib2 (only for the TFM it is compatible with) in IsInnerBuild = true mode.
- This gives us Lib2 assemblies both for net48 and net6.0 targets
- And obviously Lib1 assemblies as well for both targets
Back to Lib1, the root project goes on with building the nuget package and it is generated (and as expected references Lib1.nupkg)
However, because Lib2 is never built with IsInnerBuild = false, its package is never generated.

Versions & Configurations

Visual Studio v17.2.2
dotnet --version: 6.0.303

We're not convinced this should be changed at this time. The .NET SDK is currently in charge of dispatching builds for projects and currently it calls the "outer" build of Lib1 which dispatches two "inner" builds for Lib1, one for each target framework. Each inner build of Lib1 then dispatches an inner build to Lib2 for that specific target framework to fulfill the project reference. Once the outer build of Lib1 is complete, NuGet then calls pack on the entry project since GeneratePackageOnBuild is set to true. NuGet would need to then dispatch outer builds on all dependent projects so they could be packed.

However, we see dotnet build with GeneratePackageOnBuild to be the same as running dotnet pack. The pack gesture in our opinion means an operation that should be run on the entry project only. I'm not convinced that packing the project in the current directory and all transitive dependencies is what people expect to happen.

This works already when you pack a Visual Studio solution file because the .NET SDK dispatches all of the outer builds since that is what a solution file is for, indicating all of the projects to build as a unit. In this case, it makes sense that pack would run for each project.

We'll leave this issue open for now so the community can comment. Please leave feedback or upvote if you feel the design should change. One way I envision this working is a new property like PackTransitive would be added and NuGet would then dispatch Pack target builds to all of the project references first. But this might have some side effects that cause other issues since its a behavior change.

NuGet / Home