Packages of ProjectReference with PrivateAssets="all" are not listed as NuGet dependencies

[learneryog]

ProjectA ----ProjectReference(PrivateAssets=All)---> ProjectB ----PackageReference---> PackageX.2.0.0

dotnet pack ProjectA.csproj

ProjectB.dll will in the package, but the dependency PackageX is missed.

How to make PackageX in the nuspec?

Thanks.

[teneko]

Hey @learneryog. Thanks for the feedback. This is intended. To make them reappear I only ask you to read the FAQ. 🙂

[learneryog]

Thank you very much. I see it, but one thing I still don't understand is why SomePackage cannot be automatically added as a dependency to PackageB. Is it technically unachievable, or is there some other reason?

[teneko]

It is technically possible. Never throught about it to explictly support it. It is a feature that is, but must not apply to everyone. What I mean is, it would be a very risky assumption, just because you intend to make project reference's output being part of the package, that also their transitive packages references are intended to be part of the package's dependencies. I already get "a headache", thinking about what happens when you switch my package along the chain of project references, and how that behaves regarding flowing transitive packages. I mean technically you trying to propose the following feature:

• do not let a child project any longer participate into the package graph. Instead pretend to NuGet pack process that the child project output IS semantically the output of the project having this child project as ProjectReference.
• those direct and transitive NuGet packages that would have been listed as NuGet dependencies of child project, if that child project would have been listed as NuGet dependency of the parent project, must now be listed as NuGet dependencies of the parent project.

Am I correct, @learneryog?

[learneryog]

Thanks for your reply!

I admit this is indeed quite complex, as our team is currently facing exactly this issue.
I think what you said is probably correct. Let me describe the scenario in more detail, still using Project A referencing Project B as an example.

Thought: Why should we set Project B as a private reference (PrivateAssets=All)?

The reason is unquestionably this:
Project A uses the code from Project B, but does not want to expose the existence of Project B to upper-level consumers.
In other words, A.dll contains method calls to B.dll — let’s say this method is functionA().

If functionA() internally uses functionality from a third‑party NuGet package (SomePackage.nupkg),
then when packaging Project A:

If we only include B.dll as a file asset in Package A, without declaring SomePackage as a dependency of Package A, users who consume Package A will hit an AssemblyNotFoundException when calling functionA(), unless they manually install SomePackage on their side — is that correct?

Declaring SomePackage as a dependency directly on Package A can avoid this issue, and it is also the responsible behavior to ensure B.dll runs properly.

I noticed that the solution you provided in the FAQ is to add all dependencies from Project B into Project A and keep their versions consistent.

This undoubtedly increases the maintenance burden for developers: when upgrading package dependency versions for Project B, they must also remember to upgrade the corresponding dependencies on Project A in sync.

In addition, it is worth noting that Project B may itself have a complex dependency tree, including both project references and package references. It is extremely difficult to maintain consistent dependencies manually.

So why can’t this be handled automatically?

I hope I’ve explained this clearly. Looking forward to your reply, thank you. @teneko

[teneko]

Your observations and conclusions are correct. This is a paintpoint! And yes the solution itself, can get complicated. I will sketch out a solution and will come back to you. But this won't happen in the next days. Expect it to take weeks. I also need to refactor the repository and get rid of some legacy test patterns, this would have to happen first. Thanks for bringing this to the surface.

Options in the meantime:

1) Central Package Managment

Maybe one relief can be using Central Package Managment if you decide to maintain the PackageReference duplication.

2) PackageReference Collector and Re-Register

Write a target that collects and re-registers the packages of project references:

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

  <!-- Custom metadata on ProjectReference.
       ExportPackageReferences is NOT an SDK-defined attribute; this is your own flag. -->
  <ItemGroup>
    <ProjectReference Include="..\B\B.csproj"
                      ExportPackageReferences="true" />
  </ItemGroup>

  <!-- Hook into A's build graph right before NuGet reads A's PackageReference items.
       Anything added to @(PackageReference) here is visible to A's restore/build. -->
  <Target Name="ImportPackageReferencesFromProjectReferences"
          BeforeTargets="CollectPackageReferences">

    <!-- Filter ProjectReference items to only flagged ones.
         Metadata lookup syntax %(ProjectReference.X) is per-item.
         If metadata is missing, it is empty string -> condition is false. -->
    <ItemGroup>
      <_PackageRefSourceProject Include="@(ProjectReference)"
                                Condition="'%(ProjectReference.ExportPackageReferences)' == 'true'" />
    </ItemGroup>

    <!-- Call CollectPackageReferences in each selected referenced project (e.g., B).
         NuGet's CollectPackageReferences target returns @(PackageReference).
         MSBuild task exposes target returns through TargetOutputs. -->
    <MSBuild Projects="@(_PackageRefSourceProject)"
             Targets="CollectPackageReferences"
             BuildInParallel="true"
             SkipNonexistentTargets="true">
      <Output TaskParameter="TargetOutputs" ItemName="_PackageRefsFromProjectRef" />
    </MSBuild>

    <ItemGroup>
      <!-- Remove incoming package refs whose package ID already exists in A.
           MatchOnMetadata=Identity compares item identity (for PackageReference: package ID). -->
      <_PackageRefsFromProjectRef Remove="@(PackageReference)"
                                  MatchOnMetadata="Identity" />

      <!-- Re-register collected items as PackageReference in A.
           KeepMetadata is a whitelist to avoid copying unrelated metadata from source items. -->
      <PackageReference Include="@(_PackageRefsFromProjectRef)"
                        KeepMetadata="Version;IncludeAssets;ExcludeAssets;PrivateAssets;NoWarn;GeneratePathProperty;Aliases" />
    </ItemGroup>
  </Target>
</Project>

Assumptions made: Project A is not multi-targeting frameworks. Project B PackageReference's are not TargetFramework conditional. The former is only relevant if target framework conditional PackageReferences of Project A would be collected and re-registered in Project 0.

If multi-targeting frameworks and working with conditional packages, that you should consider to use <MSBuild ... Properties="TargetFramework=$(TargetFramework)">.

Keep in mind that CollectPackageReferences is run per target framework (inner-build), e.g. net10.0, netstandard2.0 and so on, and with TargetFramework='' (outer-build).

To prevent the ImportPackageReferencesFromProjectReferences from running in outer-build, you must use something like

<Target Name="ImportPackageReferencesFromProjectReferences"
          BeforeTargets="CollectPackageReferences"
          Condition="'$(TargetFramework)' != '' or '$(TargetFrameworks)' == ''">

Fun facts

1. Instead of ExportPackageReferences="true" and Condition="'%(ProjectReference.ExportPackageReferences)' == 'true'", you also could use PrivateAssets="all" and Condition="'%(ProjectReference.PrivateAssets)' == 'all'"
2. You can put this in a Directory.Build.props or Directory.Build.targets to make it globally/apply to all projects.

[learneryog]

Thank you very much.
I tried the Target you provided, but the result did not meet expectations:
My project dependencies:

sdk01.csproj:

<ItemGroup>
    <ProjectReference Include="..\sdk02\sdk02.csproj" PrivateAssets="All">
    </ProjectReference>
</ItemGroup>

sdk02.csproj:

<ItemGroup>
    <PackageReference Include="log4net" Version="3.2.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\sdk03\sdk03.csproj" />
  </ItemGroup>

And a Directory.Build.targets file was set up, which contains the ImportPackageReferencesFromProjectReferences Target. I am sure that the Target definition is correct and that it has been executed.

When I run: dotnet pack .\sdk01.csproj -p:Configuration=Release -bl, the corresponding nupkg package is generated.
The lib directory contains sdk01.dll and sdk02.dll, which is fine (but I have a question that I will mention below).
However, the expected log4net does not appear in the nuspec file.

After checking the msbuild.binlog file, I found that the ImportPackageReferencesFromProjectReferences Target did collect the reference relationship of log4net, but PrivateAssets = All. I'm not sure if this property caused the final dependency not to be maintained in the nuspec:

Finally: To raise my question, if sdk02.csproj references the project sdk03.csproj, then in theory, does sdk03.dll also need to be copied to the lib directory of sdk01.nupkg, and is it unrelated to the PrivateAssets property?

[teneko]

Hey @learneryog. I have tested your setup now and my guess was correct.

PrivateAssets="all" on the ProjectReference propagates to the items returned by <MSBuild ... /> when calling CollectPackageReferences per referenced project. That corresponds exactly to your
observation from the binlog: log4net gets collected, but it arrives with PrivateAssets=all, and therefore NuGet does not emit it into the .nuspec.

What I mean is, the missing change is not the overall idea of the target, but the shape of the item that is passed into <MSBuild ... />.

Right now it is effectively this:

<ItemGroup>
  <_PackageRefSourceProject Include="@(ProjectReference)"
                            Condition="'%(ProjectReference.PrivateAssets)' == 'all'" />
</ItemGroup>

<MSBuild Projects="@(_PackageRefSourceProject)"
         Targets="CollectPackageReferences">
  <Output TaskParameter="TargetOutputs" ItemName="_PackageRefsFromProjectRef" />
</MSBuild>

The problem is: @(...) expands item-by-item, and each expanded item keeps its metadata. So the ProjectReference item for sdk02.csproj still carries PrivateAssets="all" when passed to the MSBuild task. Then
the returned PackageReference items inherit that metadata as well.

Therefore you must change it so that PrivateAssets is removed before invoking <MSBuild ... />. The better way is using RemoveMetadata:

<ItemGroup>
  <_PackageRefSourceProject Include="@(ProjectReference)"
                            Condition="'%(ProjectReference.PrivateAssets)' == 'all'"
                            RemoveMetadata="PrivateAssets" />
</ItemGroup>

<MSBuild Projects="@(_PackageRefSourceProject)"
         Targets="CollectPackageReferences"
         BuildInParallel="true"
         SkipNonexistentTargets="true">
  <Output TaskParameter="TargetOutputs" ItemName="_PackageRefsFromProjectRef" />
</MSBuild>

Additionally you can omit PrivateAssets from KeepMetadata when re-registering the collected package references:

<PackageReference Include="@(_PackageRefsFromProjectRef)"
                  KeepMetadata="Version;IncludeAssets;ExcludeAssets;NoWarn;GeneratePathProperty;Aliases" />

But this introduces new problems, because intentional PrivateAssets="all" packages are now not PrivateAssets="all" anymore...

I hope you see now the problems that can surface by introducing such feature you proposed. It can get complex.

To your another unrelated question: this is something I did not thought about. But let me try to think about:

My guess is, that because we use the "native NuGet" way to collect the project reference related output files, that the native NuGet process takes care of the project reference graph and the collection of there individual output, but.. if sdk02 would again define the project reference of sdk03 with PrivateAssets="all" then my guess is, that

1. the package references of sdk03 would not have been collectedl or collected but with PrivateAssets="all" in the metadata and
2. the build output would be collected because PrivateAssets just affects the package references and my guess is: it would look different if you would make use of IncludeBuildOutput="false" on level of the ProjectReference.

[ymstar]

Hey @teneko . This is my other account, and I will use this account for communication.

I tested the two methods you mentioned to remove the PrivateAssets attribute, and both worked. That's great; this solved the problem with the PackageReference part.

Regarding the issue with ProjectReference, by checking the binlog file, I found:
Under the ResolveProjectReferences Target of sdk01.csproj, sdk03.csproj does not have the metadata PrivateAssets=All, which means that sdk03 does not inherit PrivateAssets=All from sdk02.

Under the ResolveProjectReferences Target of sdk02.csproj, sdk03.csproj also does not have the metadata PrivateAssets=All. This is normal because in the declaration of sdk02.csproj, the reference to sdk03 is not set with PrivateAssets=All.

Therefore, I still hope that sdk01.nupkg can include both sdk02.dll and sdk03.dll. Additionally, if sdk03 has other project references, I also hope all of them can be included in the package, as these may be the guarantees for the stable operation of sdk02.dll.

I understand this can be very complicated, and our team has been troubled by this for a long time.

If you won't provide these functions in your nuget package, please tell me how to do it. It will be very helpful to me.

This is my test project, in the SDK directory: https://github.com/ymstar/NuGetPackTest

[teneko]

By reading your last message I got confused. Is ResolveProjectReferences == ImportPackageReferencesFromProjectReferences? Because there exists actually a well-known ResolveProjectReferences.

You say you "I still hope ..". May I ask you what you want to know? And how to do what?

[ymstar]

Sorry, let me re-summarize the functions I expect, taking my test project as an example.：https://github.com/ymstar/NuGetPackTest/tree/master/SDK

sdk01.csproj:

sdk02.csproj:
Note: For the project reference to sdk03, PrivateAssets=All is not set

sdk03.csproj:

Based on the above scenario, I hope to get the following results when packaging sdk01:

1. In the lib/net45 directory within sdk01.nupkg:

• sdk01.dll (The default behavior of dotnet pack)
• sdk02.dll （Thanks to theTenekon.MSBuild.Packaging.ProjectBuildInPackage and PrivateAssets=All）
• sdk03.dll (My expectation is because sdk02 references it)

2. In the sdk01.nuspec file within sdk01.nupkg:

• <dependency id="Newtonsoft.Json" version="13.0.3" /> (The default behavior of dotnet pack)
• <dependency id="log4net" version="3.2.0" /> (Thanks to the ImportPackageReferencesFromProjectReferences Target you provided)
• <dependency id="MySql.Data" version="6.9.12" /> (My expectation comes from the reference of sdk03)

I think I've made myself clear this time, and I look forward to your reply.