Transitive package reference from project reference ignores Copy Local/Private setting for .Net Framework projects.

[General-Fault]

Transitive package reference from project reference ignores Copy Local/Private setting for .Net Framework projects.

[KalleOlaviNiemitalo]

One workaround is to let ProjectB copy the assemblies to the output directory, but then copy the assemblies from there to a separate directory and exclude the indirect references from that copy. Microsoft.Build.Artifacts can be used for that.

[JanKrivanek]

@General-Fault No - you are right, this is a known bug in MSBuild/sdk/nuget: dotnet/sdk#1366
Closing this as duplicate now

[JanKrivanek]

Is this a correct problem statement?: You want to influence copying of PackageReference items from the referenced project (through ProjectReference) within the referencing project. E.g. you want PackageReference items from ProjectA not to be copied to output of referencing ProjectB, but to be copied to output of referencing ProjectC.

If that's correct - I do not believe it's supported today (but I'll dig further) - but can you workaround by specifying PrivateAssets on the PackageReference items in ProjectA (so that they are excluded by referencing projects) and explicitly adding those to ProjectC (so that they are copied there)?

[General-Fault]

Is this a correct problem statement?: You want to influence copying of PackageReference items from the referenced project (through ProjectReference) within the referencing project. E.g. you want PackageReference items from ProjectA not to be copied to output of referencing ProjectB, but to be copied to output of referencing ProjectC.

If that's correct - I do not believe it's supported today (but I'll dig further) - but can you workaround by specifying PrivateAssets on the PackageReference items in ProjectA (so that they are excluded by referencing projects) and explicitly adding those to ProjectC (so that they are copied there)?

Not quite... ProjectC in this case also has a reference to ProjectA and the necessary packages. In my use-case, ProjectA is a "common" assembly that includes shared interfaces. ProjectB is a runtime discoverable plugin. By the time the plugin is loaded by the ProjectC executable, the shared ProjectA.dll its dependencies have already been loaded. By this token, the PrivateAssets approach is not usable here.

What I'm trying to do here is have the output directory for ProjectB (and installer generated from those outputs) only contain assemblies that are specific to that plugin and not the "common" assemblies also used by Project A and ProjectC.

For what it's worth, I think I may have solved my own problem using <IncludeAssets>compile</IncludeAssets> in the ProjectReference tag in ProjectB. So, is the "bug" here only in my head where I simply didn't understand the intention of the MSBuild developers? Or should <Private>False</Private> imply that the dependencies of the referenced project also not be included in the output as I had expected?

[General-Fault]

@KalleOlaviNiemitalo Thank you for pointing me toward Microsoft.Build.Artifacts! This probably isn't the ideal solution for the project that led to me filing this issue. However, this may solve another related challenge I'm facing.