dependency-management

A set of rules for managing NuGet packages in .NET projects. NuGet is the package system that supplies reusable libraries to .NET applications.

In plain words
What is it for?
Use it when adding or updating packages with the dotnet command-line tool, checking licenses and authenticity, reviewing security risks, and choosing a versioning approach.
Why use it?
It helps avoid unsafe, incompatible, or poorly maintained dependencies. It also keeps package installation and version choices consistent.

Cursor rule

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/aaronontheweb/dotnet-cursor-rules/dependency-management
Clone the repo
git clone --depth 1 https://github.com/Aaronontheweb/dotnet-cursor-rules
Per session 0 Nothing until a file matches its globs; then the whole rule loads.
When invoked 1,298 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.01298
Opus 5 $0.00000 $0.00649
Sonnet 5 $0.00000 $0.00260
Haiku 4.5 $0.00000 $0.00130

Measured 2d ago against content hash 22e2a1ace8a3, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

dependency-management scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

dotnet-sdk/dependency-management.mdc · 193 lines

How it starts

The opening of the file, as written. The whole thing — 193 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Cursor Rules File: Best Practices for .NET Dependency Management

Role Definition:

  • Package Management Expert
  • Security Analyst
  • License Compliance Specialist

General: Description: > .NET projects must manage their dependencies using secure and consistent practices, with attention to security vulnerabilities, license compliance, and proper version management through the dotnet CLI. Requirements: - Use dotnet CLI for package management - Verify package licenses before installation - Monitor for security vulnerabilities - Maintain consistent versioning strategies

Package Installation:

  • Always use dotnet CLI commands:
    • Preferred: dotnet add package <PackageId> [-v <Version>]
    • Avoid manual .csproj/.fsproj edits
    • Examples:
      # Add latest stable version
      dotnet add package Newtonsoft.Json
      
      # Add specific version
      dotnet add package Serilog -v 3.1.1
      
      # Add package to specific project
      dotnet add MyProject/MyProject.csproj package Microsoft.Extensions.Logging
      
  • Before installation:
    • Check package license compatibility
    • Review package download statistics
    • Verify package authenticity (signed packages)
    • Consider package maintenance status

Check and Upgrade NuGet Packages:

To check for outdated packages and upgrade them in your .NET solution:

  1. Check for outdated packages

    dotnet list package --outdated
    

    This command will show:

    • Currently used version ("Resolved")
    • Latest available version ("Latest")
    • The version you're requesting ("Requested")
  2. Update package versions

    • If using central package management (Directory.Packages.props):

      • Update the versions in Directory.Packages.props:
      <PackageVersion Include="PackageName" Version="NewVersion" />
      
    • If using traditional package references:

      dotnet add package PackageName --version NewVersion
      
  3. Restore and verify

    dotnet restore
    dotnet build
    dotnet test
    

Example output of dotnet list package --outdated:

Project `MyProject` has the following updates to its packages
   [netstandard2.1]:
   Top-level Package      Requested   Resolved   Latest
   > Akka.Streams         1.5.13      1.4.45     1.5.38

Note: After updating packages, always:

  1. Check for breaking changes in the package's release notes
  2. Build the solution to catch any compatibility issues
  3. Run tests to ensure everything still works
  4. Review and update any code that needs to be modified for the new versions

Security Considerations:

  • Enable security scanning:
    • Run dotnet restore --use-lock-file to generate lock file
    • Use dotnet list package --vulnerable to check for known vulnerabilities
    • Configure GitHub Dependabot or similar tools
  • Monitor security:
    • Subscribe to security advisories
    • Regular vulnerability scanning in CI/CD
    • Automated security updates for patch versions
  • Example workflow:
    # Generate lock file
    dotnet restore --use-lock-file
    
    # Check for vulnerabilities
    dotnet list package --vulnerable
    
    # Update vulnerable package
    dotnet add package VulnerablePackage -v SecureVersion
    
    # Regenerate lock file
    dotnet restore --force-evaluate
    

License Compliance:

  • Verify licenses before adding dependencies:
    • Check license compatibility with your project
    • Document license requirements
    • Maintain license inventory
  • Common OSS-friendly licenses:
    • MIT
    • Apache 2.0
    • BSD
    • MS-PL
  • Warning signs:
    • No license specified
    • Restrictive licenses (GPL for commercial software)
    • License changes between versions

Version Management:

  • Use semantic versioning:
    • Lock major versions for stability
    • Allow minor updates for features
    • Auto-update patches for security
  • Version constraints:
    • Avoid floating versions (*)
    • Use minimum version constraints when needed
    • Document version decisions
  • Example in Directory.Packages.props:
    <Project>
      <ItemGroup>
        <!-- Locked major version -->
        <PackageVersion Include="Important.Package" Version="2.0.0" />
        
        <!-- Allow minor updates -->
        <PackageVersion Include="Feature.Package" Version="[3.0,4.0)" />
        
        <!-- Allow patch updates -->
        <PackageVersion Include="Stable.Package" Version="[1.2.3,1.3.0)" />
      </ItemGroup>
    </Project>
    

Read the full file on GitHub · 193 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 193 lines · 0 tokens per session scan A 22e2a1ace8a3

Subscribe to this mod's changes

dependency-management is a cursor rule published in the GitHub repository Aaronontheweb/dotnet-cursor-rules (134 stars, last pushed 1y ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 1,298 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.