NDepend is a static analysis tool designed specifically for .NET codebases. It helps development and DevOps teams measure code quality, track technical debt, enforce architectural rules, and integrate code analysis directly into CI/CD pipelines. Getting started with a tool this feature-rich can feel overwhelming, so this article walks through the fastest practical path to productive use.
What Is NDepend?
NDepend is a Visual Studio extension and standalone tool that performs deep static analysis of .NET assemblies. Unlike lightweight linters, NDepend generates detailed metrics — cyclomatic complexity, coupling between components, lines of code, test coverage correlation, and more — and presents them through interactive dashboards and dependency graphs.
One of NDepend’s most distinctive features is CQLinq (Code Query LINQ), a query language that lets you write custom rules against your codebase using familiar C# LINQ syntax. This means you can express architectural constraints such as “no class in the UI layer may directly reference the data access layer” as executable, version-controlled queries.
Why NDepend Matters for DevOps Teams
Static analysis is most valuable when it runs automatically and consistently — not just on a developer’s local machine before a commit, but on every build in your pipeline. NDepend supports this workflow through:
- CI/CD integration: NDepend ships with a command-line runner that integrates with build servers such as Azure DevOps, Jenkins, TeamCity, and GitHub Actions.
- Build-breaking rules: You can configure quality gates so that a build fails when technical debt exceeds a defined threshold or a critical architectural rule is violated.
- Trend tracking: NDepend stores analysis history and surfaces trends over time, making it easy to see whether code quality is improving or regressing across sprints.
- HTML and XML reports: Automated reports can be published as build artifacts or emailed to stakeholders.
The Fastest Way to Get Started
The challenge most engineers face with NDepend is information overload on first launch. The tool surfaces hundreds of metrics and dozens of pre-built rules at once. The following approach — based on common onboarding advice in the .NET community — helps you reach productive use quickly.
1. Install and Attach to Your Solution
Download NDepend from the official site and install the Visual Studio extension. Once installed, use NDepend → Attach New NDepend Project to VS Solution to create an NDepend project file (.ndproj) alongside your solution. Commit this file to source control so team members share the same configuration.
2. Run Your First Analysis
Trigger an analysis with NDepend → Run Analysis. NDepend will inspect your compiled assemblies — make sure you build the solution first. The initial analysis produces an interactive HTML dashboard and opens the NDepend interactive panel inside Visual Studio.
3. Focus on the Dashboard, Not Every Metric
Resist the urge to explore every panel immediately. Start with three sections:
- Technical Debt: NDepend estimates the time required to fix all flagged issues. Use this as a baseline rather than treating every issue as urgent.
- Critical Rule Violations: Pre-built rules flagged as critical are worth reviewing first. These typically catch real design problems such as types that are too large, methods with excessive complexity, or inappropriate dependencies.
- Dependency Graph: The dependency graph is one of NDepend’s most immediately useful features. Use it to visualise how your assemblies and namespaces relate to each other and spot unexpected coupling.
4. Write Your First CQLinq Rule
Once you’re comfortable with the dashboard, open the Queries and Rules Explorer and experiment with CQLinq. A simple starting rule might flag all public methods with cyclomatic complexity above a team-agreed threshold:
warnif count > 0 from m in JustMyCode.Methods
where m.CyclomaticComplexity > 15
select new { m, m.CyclomaticComplexity }Code language: JavaScript (javascript)Custom rules like this can be saved, committed to source control, and enforced automatically on every CI build.
5. Integrate with Your Build Pipeline
After validating your rule set locally, add the NDepend command-line runner to your CI pipeline. The runner accepts your .ndproj file as input and returns a non-zero exit code when quality gates fail, which most CI systems interpret as a build failure. This closes the feedback loop and ensures code quality analysis is not optional.
Common Pitfalls
- Analysing generated code: NDepend can pick up auto-generated files. Use the JustMyCode filter in CQLinq queries to exclude generated assemblies and focus on code your team actually owns.
- Treating every warning as a blocker: The default rule set is intentionally strict. Tune quality gates to reflect your team’s current baseline, then tighten them incrementally.
- Skipping the baseline commit: Running NDepend once without committing the project file means you lose trend data. Trend tracking only works when analysis results are stored and compared across builds.
Further Reading
Erik Dietrich’s original walkthrough on DZone provides a first-person account of getting up to speed with NDepend and is worth reading alongside this article: The Fastest Way to Get to Know NDepend – DZone DevOps.
Original article by Erik Dietrich, published on DZone.