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.

My Analyzer Shipped Without Checking Its Own Source

NetEvolve.Analyzer enforces null-check idioms and file organization on other people’s code, but had never run against its own. Fixing that surfaced 39 warnings, a silent Visual Studio MEF failure, and a follow-up NE0008 bug where DateOnly and TimeOnly got flagged blind to which target framework actually has them, the same multi-targeting blindness in a different corner of the codebase.

Cyber Resilience Act for .NET Library Authors: Read the Fine Print

The EU Cyber Resilience Act’s headline deadline is December 2027, but the reporting clock starts more than a year earlier. Article 14 vulnerability reporting applies from September 2026. Here is the engineering map I built for my own NuGet release pipeline: what the CRA regulates, the 24/72-hour cadence, SBOM tooling for .NET, and where the open-source carve-out holds.

Incremental Source Generators Done Right: Ship It Without Breaking Consumers

Packaging Generators

Parts 1 through 3 of this series made the generator correct, incremental, and proven by tests. None of it reaches a single consumer if the NuGet package is laid out wrong — and the failure modes are silent: a DLL in lib/ instead of analyzers/dotnet/cs simply never loads, a missing dependency throws only inside the compiler, and a marker attribute delivered carelessly breaks InternalsVisibleTo in ways users cannot diagnose. This final part covers the packaging contract: the netstandard2.0 rule, the package layout, dependency bundling, attribute delivery, debugging the shipped bits, and the analyzer hygiene rules that keep you honest.

Standardize or Drift: One Defaults Package for All Your Solutions

Directory.Build.props drift is the quiet tax every multi-repo .NET org pays. NetEvolve.Defaults ships MSBuild properties, .editorconfig, NuGet Audit, and ten Roslyn diagnostics as a private-asset NuGet package. Bump the version once, every repo gets the upgrade.

NuGet Packages: Suppliers You Forgot to Audit

Every NuGet package is a supplier relationship under ISO 27001. Learn how to implement Central Package Management, automated vulnerability scanning, and package signature verification to transform your .NET dependency management from security liability into auditable compliance control.