Asset Flow & References
You add one `<PackageReference>` line and a package's whole `lib/`, `build/`, and `analyzers/` folder wires itself into your project. Some of that should reach whoever consumes your library later, most of it should not.
- ▸One
<PackageReference>line pulls from up to eight folders at once; it was never a single dependency. - ▸Two separate gates decide what your build sees and, apart from that, what your package's consumers ever inherit.
- ▸Every build-only package, protoc tools, analyzers, source generators, hides behind the same one-line switch.
Crack open a NuGet package on disk and it is a tree of folders: lib/, runtimes/, build/, buildTransitive/, buildMultitargeting/, analyzers/, native/, and contentFiles/. Each folder carries a different payload. lib/ holds the .dll your code calls. build/ holds .props and .targets that hook into your compile, buildTransitive/ the ones meant to cross project boundaries, buildMultitargeting/ the ones for a multi-targeted project's outer build. analyzers/ holds compile-time code checkers. native/ holds platform-specific binaries.
Write a single <PackageReference Include="SkiaSharp" Version="2.88.8" /> and that one line reaches into every folder the package ships. It is not one dependency. It is up to eight separate streams of content, each arriving on its own track.
That split is the whole topic. Because the folders are separate, .NET lets you switch each stream on or off, both for your own build and for whoever depends on you later. The viz lays the eight streams side by side, so you can see what a bare <PackageReference> really pulls in before you touch a single knob.