Is there a way to control Nuget's over-eager references? - nuget

Question

I'm just getting started with Nuget, and moving much of my team's intra-team and interdepartmental references into packages on a private nuget feed. The thing I'm observing though is that when my packages have their own dependencies, those secondary dependencies get added to my projects as references as though the projects are using them directly.
This works from a build & release perspective since the dependencies get packaged up correctly, but for larger projects the references list gets rather bloated compared to the assemblies actually referenced in code. In a hypothetical cleanup exercise, it seems like it would be difficult to determine which assemblies were this type of secondary dependency and which were simply no longer used.
Is this just an unfortunate consequence of Nuget works? Is there a different way to use Nuget that doesn't result in these noisy references?
For example: I have project MyProject, which uses assembly DependencyA directly. DependencyA references assembly LibraryX and as such LibraryX is required at runtime for MyProject, even though MyProject doesn't use it directly. For the sake of the example let's say LibraryX is distinct enough for it to be its own package.
In this scenario, prior to Nuget, the assemblies would live in source control, and could be packaged up during build/publish/deploy without needing an assembly reference in MSBuild. In this case MyProject has an MSBuild assembly reference to DependencyA, but not to LibraryX.
However, upon migrating to Nuget and consuming these dependencies via packages, the nuspec for DependencyA expresses a dependeny on LibraryX:
<package >
<metadata>
<id>DependencyA</id>
<version>1.0.0</version>
<authors>Initech</authors>
<owners>Initech</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<license type="expression">MIT</license>
<description>A Dependency</description>
<tags>Dependency A</tags>
<dependencies>
<group targetFramework="net40" >
<dependency id="LibraryX" version="1.0.0" />
</group>
</dependencies>
</metadata>
</package>
When installing the DependencyA package on MyPrject, Nuget adds an MSBuild assembly reference for LibraryX to MyProject even though MyProject doesn't actually directly reference LibraryX.

Answer 1

You can control which assets are allowed to flow up the dependency chain using PrivateAssets, which I think is what you mean.
By default everything flows up though, so you can use packages you only depend on transitively in your code - in other words, the distinction between compile and runtime dependencies you mentioned in your comment doesn't exist by default.