DOCSEARCHbyAlgolia
Submit Docs

NuGet Documentation

repository·dev·Indexed 23 days ago

https://github.com/nuget/home

The package manager for the Microsoft development platform, including .NET. This documentation covers the NuGet proposal lifecycle, Central Package Version Management (CPVM), and the NuGet MCP Server—a Model Context Protocol server for AI agents providing real-time package info, vulnerability remediation, and automated updates. It also provides guidance on contributing to NuGet projects and managing the ecosystem across repositories like nuget.client and NuGetGallery.

Tokens
68.9K
Snippets
114
Records
331
Agent score
80%

What's inside NuGet

  1. Getting started with NuGet

    dev

    NuGet is the package manager for the Microsoft development platform, including .NET. To use NuGet in your development workflow, you can follow these primary paths:

    • Consume NuGet packages: Learn how to add and manage packages within your existing projects.
    • Create NuGet packages: Learn how to package your own code and publish it to a repository.
    • Use Client Tools: Use the NuGet client tools to produce and consume packages. These tools include:
      • The NuGet command-line tool (version 4.0 and higher).
      • The Visual Studio Extension (for Visual Studio 2017 and later).
      • PowerShell CmdLets.

    For detailed guides, visit the NuGet Docs.

  2. What is the NuGet MCP Server and its capabilities

    dev

    The NuGet MCP Server is a Model Context Protocol (MCP) server that enables advanced tooling and automation for NuGet package management via AI agents.

    Key Capabilities:

    • Real-time Package Info: Uses your configured NuGet feeds to retrieve up-to-date package information.
    • Vulnerability Remediation: Provides the ability to update packages with known vulnerabilities, including transitive dependencies.
    • Advanced Updates: Offers intelligent package updates based on a project's unique package graph and target frameworks.

    Supported Tools:

    • get-nuget-solver: Fixes vulnerable package versions by updating direct and transitive dependencies to the best compatible non-vulnerable version.
    • get-nuget-solver-latest-versions: Fixes vulnerable versions by updating to the latest compatible non-vulnerable version.
    • get-latest-package-version: Retrieves the latest version of a specific NuGet package.
    • get-package-readme: Fetches a NuGet package's README as markdown.
    • update-package: Updates installed packages to a specified version (if compatible) and handles necessary dependency updates.

  3. NuGet package management in VS Code & C# Dev Kit

    dev

    NuGet package management is integrated into Visual Studio Code via the C# Dev Kit extension. This experience provides two primary ways to interact with NuGet packages:

    1. Command Palette Flows: For developers who prefer keyboard-driven workflows and command-based interactions.
    2. C# Dev Kit Solution Explorer: A visual integration within the Solution Explorer that allows for intuitive package management similar to the full Visual Studio experience.

    The core operations supported in the initial experience include adding (browsing and installing), removing, and updating NuGet packages, as well as authentication to private feeds.

  4. Understand C++/CLI PackageReference support

    dev

    NuGet supports PackageReference for .NET Core C++/CLI projects. This allows C++/CLI projects—which produce managed binaries—to consume both managed and native NuGet packages.

    Key Capabilities:

    • Managed Package Consumption: .NET Core C++/CLI projects can install managed packages compatible with their target framework (e.g., .NET 5.0).
    • Native Package Consumption: C++/CLI projects can consume native packages.
    • Transitivity: If a C# project references a C++/CLI project, and that C++/CLI project references a managed package, the managed package is restored transitively into the C# project.

    Important Limitations:

    • No .NET Framework Support: This implementation does not cover .NET Framework-based C++/CLI projects (which still use packages.config).
    • No Native C++ Support: Native C++ projects (.vcxproj) are not supported via PackageReference in this context.
    • No Executables: .NET Core C++/CLI projects can only build libraries, not executables (exes).
    • Not Packable: .NET Core C++/CLI projects cannot be redistributed using the standard pack target.

  5. Overview of the dotnet package update command proposal

    dev
    The dotnet package update feature is a proposed enhancement to the .NET CLI designed to help developers manage NuGet dependencies more efficiently. It aims to provide a single command to address security vulnerabilities, deprecated packages, and outdated versions. This feature is intended to build upon the existing NuGet Audit functionality to improve the security and reliability of .NET applications by closing the functional gap between the CLI and Visual Studio's package management capabilities.

  6. Understand AssetTargetFallback and dependency resolution issues

    dev

    Overview

    AssetTargetFallback is a mechanism that allows .NET (Core) projects to reference packages or projects originally authored for .NET Framework. This is useful when a package written for .NET Framework can be safely used in a .NET (Core) environment.

    The Dependency Bug

    Historically, a bug existed where packages resolved via AssetTargetFallback did not have their transitive dependencies correctly included. For example, if Project A references Package B using AssetTargetFallback, and Package B depends on Package C, Package C might not be pulled into the dependency graph. This mismatch can lead to runtime failures because the required dependencies for the fallback package are missing.

    Resolution

    This issue was addressed to ensure that when a package is selected via AssetTargetFallback, its dependencies are resolved and included in the project's dependency graph, maintaining consistency between the selected package and its requirements.

  7. How NuGet.org validates GitHub OIDC tokens

    dev

    When using Trusted Publishers, NuGet.org validates GitHub Actions OIDC tokens using standard JWT rules and specific claim checks to ensure the workload is authorized.

    General JWT Validation:

    • Valid signature via JWKS.
    • Valid duration (nbf and exp claims).
    • Uniqueness via jti (only used once).
    • Valid aud claim, which must be nuget.

    GitHub-Specific Claim Validation: To prevent resurrection attacks and ensure correct scoping, NuGet.org verifies:

    • sub: Must have a repo:{repo owner}/{repo name}: prefix (case insensitive).
    • repository_owner: Must match the owner name (case insensitive).
    • repository_owner_id: Must match the numeric ID recorded during trust policy creation.
    • repository: Must match the repository name (case insensitive).
    • repository_id: Must match the numeric ID recorded during trust policy creation.

    Filter-Specific Validation:

    • Branch Filter: ref_type must be branch and ref must match refs/head/{branch} (case sensitive, supports wildcards).
    • Environment Filter: environment must match the specified environment (case insensitive).
    • Workflow Path Filter: job_workflow_ref must match {repo owner}/{repo name}/{workflow path}@.* (case insensitive).
    • Tag Filter: ref_type must be tag and ref must match refs/tags/{tag-pattern} (case sensitive, supports wildcards).

  8. How Epics are tracked and managed

    dev

    The Client Team uses Epics (GitHub issues tagged as Epic) to track high-level work verticals, large disparate subtasks, or specific public Key Results (KRs).

    Lifecycle and Rules:

    1. In Progress Syncing: If any issue under an Epic is moved to In Progress, the parent Epic must also be moved to the In Progress pipeline.
    2. Completion: Epics should remain in In Review or Validating until the related change is actually available to customers. They should not be closed until released.
    3. Visibility: Customers can view fine-grained status by filtering the ZenHub board by Epics and hiding subtasks.

  10. How Sprint and Release tracking works

    dev

    The Client Team uses a combination of GitHub Milestones and ZenHub features to manage timelines:

    • Sprints: Managed via GitHub Milestones. During Sprint Planning, items from the Backlog are assigned to a Sprint Milestone and an owner. To maintain accurate velocity data, partially completed issues should be re-estimated at the start of a new sprint to reflect the work left to be done.
    • Releases: Managed via the ZenHub Release feature. When issues are scheduled, they are assigned both a Sprint and an appropriate Release.
    • Velocity/Burndown: Using GitHub Milestones for sprints enables the use of ZenHub's Velocity Tracking and Burndown reports.

  11. Pruning behavior by .NET version and NuGetAuditMode

    dev

    The rollout strategy for PrunePackageReference depends on the target framework and the NuGetAuditMode setting.

    • Targeting .NET 10: If a project targets .NET 10, pruning is enabled for all frameworks in that project (including multi-targeted projects like net8.0;net10.0). This matches the behavior of NuGetAuditMode=all.
    • NuGetAuditMode=all: If NuGetAuditMode is set to all, pruning is enabled for the entire project if at least one framework targets .NET 10 or above. Note that NuGetAuditMode cannot be partially enabled per framework.
    FrameworksNuGetAuditModePruning Status
    net10.0allEnabled
    net9.0directNot Enabled
    net9.0;net10.0allEnabled (for all frameworks)

  12. How transitive dependencies are resolved and displayed

    dev

    The Package Manager UI (PMUI) determines transitive dependencies by reading the project.assets.json file.

    Technical Logic:

    • Source: Information is extracted from the project.assets.json file on disk.
    • Dependency Walking: To show which top-level package brought in a transitive dependency, the system walks the dependency graph from the top-level packages down to the target transitive package.
    • Caching: To maintain UI responsiveness, the transitive dependency information is cached and only re-read if the project.assets.json file changes.
    • Limitations:
      • Transitive dependencies from referenced projects are not shown in the initial implementation.
      • If the project.assets.json file is missing (e.g., before a restore), transitive dependencies may not be visible until a restore is completed.