ProjectReference doesn't behave the same as PackageReference for contentFiles

[ocean-orrick]

Hi, I have a library project which builds a Package with a config file which is placed in contentFiles\any\any with PackageCopyToOutput set to true. When installing this as a PackageReference, the config file is copied to the output directory of the consuming project as expected. However, when referencing it as a ProjectReference in a Tester app in the same solution, the config file is not copied to output.

Is there some way to achieve the same behavior between the ProjectReference and PackageReference that I'm missing here? If not, this seems like a deficiency of the current system. It seems very odd to me that ProjectReference functions equivalently as PackageReference in terms of defining transitive dependencies (even supports PrivateAssets, IncludeAssets, etc.), but does not behave the same for copying contentFiles.

[nguerrera]

It would be nice in theory if a project reference behaved exactly like packing and then using package reference, but that is not the case for a number of behaviors. In practice, it would be extremely hard to implement.

If you have CopyToOutputDirectory="PreserveNewest" metadata on Content items, they will be copied to consuming projects' output directories.

[ryantrem]

It would be great if a ProjectReference to a project that generates a NuGet package basically became a PackageReference under the hood (e.g. the referenced project's NuGet package is built locally, and consumed as a package by the referencing project). This would take care of all the other NuGet behaviors, such as custom props/targets being packaged, and of course general content as well. It would also make it trivial to test changes being made to a NuGet package in the context of the consumer (just change the PackageReference to a ProjectReference). This would be incredibly helpful to the developer workflow when you are both a contributor and a consumer to a library being distributed via NuGet.

[nguerrera]

As I said, this would be extremely difficult to implement. There are all sorts of behaviors in the larger system that depend on project references not working that way. Literally implementing it by packing, and rerunning some kind of restore to generate appropriate assets file would be prohibitively expensive in terms of build perf. And a bunch of things in the IDE would break.

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.