'Private' metadata is not propagated to transitive dependencies

[jaredpar]

This was discovered moving Roslyn's VSIX projects to the new SDK.

Roslyn builds a number of VSIX projects and is very particular about which projects end up embedded in which VSIX. There are a number of patterns employed to accomplish this including

<ProjectReference Include="..\..\VisualStudio\Core\Impl\ServicesVisualStudioImpl.csproj">
  <Project>{c0e80510-4fbe-4b0c-af2c-4f473787722c}</Project>
  <Name>ServicesVisualStudioImpl</Name>
  <Private>false</Private>
</ProjectReference>

The intent here is to reference the project but not include its contents in the resulting VSIX by means of <Private>false</Private>. This continues to work in the new SDK.

However implicit transitive references ends up pulling in all of the projects that ServicesVisualStudioImpl.csproj. None of those projects are marked as <Private>false</Private> and as a result end up included in the VSIX. This both bloats (in some cases 100 fold) and functionally breaks our VSIX (some cases 100 fold).

[jaredpar]

Note: this is not a partner blocking issue. @nguerrera helped me out with a work around here. For the VSIX projects we can just override the IncludeTransitiveProjectReferences target to do nothing. Still would be nice to have this fixed at some point.

CC @jasonmalinowski

[nguerrera]

So private assets on the project reference did not work?

[nguerrera]

I mean PrivateAssets=All

[jaredpar]

@nguerrera I tried that but looking back at your message I worry I may have done it incorrectly. What I tried was adding the following to the ProjectReference node:

<PrivateAssets>All</PrivateAssets>

Your message suggested the following

<ItemDefinitionGroup>
   <ProjectReference>
     <PrivateAssets>All</PrivateAssets>
  </ProjectReference>
</ItemDefinitionGroup>

Not sure if that makes a difference or not.

[nguerrera]

I expected either to work. The definition group was just a way to apply it to all project references.

[rainersigwald]

The IDG would apply it to all ProjectReference items, even those dynamically created by NuGet. My guess is that NuGet isn't propagating that metadata from the reference to its transitive closure when it dynamically discovers/inserts the closure (based only on this issue, opinion unsullied by looking at any code).

[jaredpar]

Here is the work around we employed

jaredpar/roslyn@eb66259

[nguerrera]

Note there are two pieces of metadata with similar names and different meanings. Private and PrivateAssets. My expectation was that PrivateAssets (read by NuGet not build) would impact the assets file such that transitive project references would be suppressed coming through that reference. But I realize now that private assets decides whether a reference flows to your consumers, not that you want to consume something but not its dependencies.

IDG for Private=false might work, but it's not the semantic we're after. We're trying to prevent extra project references from being raised, not to raise them with Private=false.

[nguerrera]

@natidea @emgarten Is there a better way to prevent transitive project refs than overriding the target?

[natidea]

@nguerrera from within the SDK, overriding the target seems like the best way. The only other way would be to take a direct dependency on each offending implicit project reference, and set them all to private.