Publish: PrivateAssets=All not honored on ProjectReference items

[Brice Lambson]

Steps

1. Create a new .NET Core Console App
2. Add a new .NET Standard Class Library
3. Reference the class library from the console app:

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

4. Run dotnet publish on the console app.

Unexpected Results

• ClassLibrary1.dll is copied to the the 'publish' directory.

[Martin Andreas Ullrich]

It does work with ReferenceOutputAssembly="false" as metadata.

[Livar]

@bricelam Did you mean ProjectReference in the title?

@nguerrera @dsplaisted Is there a reason for having a separate metadata to convey what seems like the same intention between packagereference and projectreference?

[Brice Lambson]

Doh, yes.

[Brice Lambson]

Also, IncludeAssets, ExcludeAssets & PrivateAssets are documented as supported by NuGet on ProjectReference items.

[Brice Lambson]

ReferenceOutputAssembly has slightly different semantics too. PrivateAssets would still let you compile against it.

[Nick Guerrera]

They are supported in so far as they alter the assets json produced by restore. In this case though that isn't sufficient to impact the copy local semantics of project refs. In other words, we're missing some extra code to handle that part in that case.

I remain confused by the fact that PrivateAssets=All has special meaning to also imply not publishing. This seems orthogonal to 'consume but do not flow'. I wonder if publish filtering on package and project refs should use something else.

[Nick Guerrera]

Using Private=false metadata instead of ReferenceOutputAssembly=false should work for the compile against but do not copy semantic. (This is another data point that the term private is a poor choice for impacting copying. Classic reference metadata and nuget metadata are overloading it with opposite meaning. :()

[Brice Lambson]

I just hit another case like this. This time I was expecting that Publish="false" would prevent the <ProjectReference> from being published.

[Petr Onderka]

I think NuGet/Home#6098 looks like a duplicate of this issue.

[Michael W Powell]

Has there been a sufficient workaround for this yet? I've got some internal assets which I think this pattern might be the right approach, but I am not aware of how to make that private assets for a ProjectReference.

[Nirmal Guru]

How one could exclude the framework-like references that we know will exisit in the deplyment but still keep other the references from other p2p and package refs, bacially a plugin like dev model.

My Solution File:

MyProject.Web
  -- MyProject.Api
  -- MyProject.Core
  -- MyProject.Misc
  -- System.* NuGets *
  -- 3rd Party NuGets *

*Note: They also refers other System.* libs, that are also in the framework packages.

Same with other Projects like Api, Core, Misc...!

I refer in my plugin project to Web, one with Api, one with Core and Misc, along with NuGet and 3rd party packages that itself have references to packages that will already be present in Web project.

So, My questions are

1. How to get only the references that are not in Web project including any and all transitive references?

   With IncludeAssets="Compile" and Private="False" I get the first one barely working but with some references still being published like Newtonsoft.Json and others (those referenced by Web project).

2. How to keep all (or except one) Satellite Assemblies (aka *.resources.dll) from publishing?

   With CopyLocalSatelliteAssemblies="False" on PackageReference, this doesn't seem to work at all.

[Michael W Powell]

Worst case, we isolate these things in a separate solution, or, minimally, separate build configuration, for internal publication, and subscribe to them via conventional package channels that way. In the worst case. I'm just trying to figure on a way to leverage the internal bits without that level of isolation, if possible.

[James Turner]

I found a blog post which does go into a workaround for this with a custom target though it would be great if this worked out-of-the-box.