NuGet Package Management for .NET

NuGet has been the spine of .NET dependency management for more than a decade, and most teams still treat it as a search box in their IDE. dotnet add package, accept the latest version, commit. That habit is how production ends up shipping with twelve copies of Newtonsoft.Json across pinned, floating, and transitive references — and how a critical CVE in a package nobody remembers adding lives in your binaries for two years.

The articles in this collection treat NuGet as the supply-chain surface it actually is. Central Package Management is the headline feature: one Directory.Packages.props file that declares every version once, propagates the versions across all projects in the solution, and lets Dependabot or Renovate update them in a single pull request rather than per-csproj. It took NuGet twelve years to get this right, and most enterprise solutions still have not adopted it. The cost of migrating is hours; the cost of not migrating is paid every sprint in merge conflicts and version drift.

Package signing and source trust are the next layer. NuGet signature verification, the nuget.config packageSourceMapping element that pins which packages may resolve from which feeds, and signed-only consumption policies turn “the feed I happened to be configured against” into “an approved supplier”. The same machinery underpins ISO/IEC 27001 supplier control: every package reference is a vendor relationship, and pretending otherwise is what gets you audited.

The collection also covers the less obvious corners: PackageDownload for grabbing build-time artefacts without polluting the dependency graph, symbol package publishing for libraries you actually want others to debug, internal feed strategies on Azure Artifacts, and the version-range syntax everyone uses incorrectly until it breaks a downstream consumer. Reliable .NET projects depend on getting these right; flaky ones depend on luck.