Why I Built NuGet Lens to Visually Inspect .NET Solution Dependencies
A while ago, I kept running into a problem that was starting to get pretty annoying in larger .NET solutions.
NuGet conflicts would show up, different versions of the same package would exist across projects, and some dependencies seemed to come out of nowhere. Understanding what was actually happening meant jumping between multiple .csproj files, checking references, comparing versions, and mentally rebuilding the relationship between projects.
At some point, I realized this was taking more manual effort than it should.
That is why I started building NuGet Lens.
The idea behind it is simple: open a .NET solution and visually inspect its project relationships, package dependencies, and version conflicts without having to decode everything by hand.
The Problem
As solutions grow, understanding package relationships becomes harder than it should be.
A few of the pain points that pushed me in this direction were:
- multiple projects using different versions of the same package
- project references making dependency flow harder to follow
- having to inspect several .csproj files just to understand one issue
- losing time reconstructing the dependency graph mentally
Even when the issue is “just” a version mismatch, the process of finding it can feel much more complicated than the problem itself.
A Simple Use Case
Imagine a solution with a few projects that reference each other.
Two of those projects use different versions of the same package:
- one project references Serilog 4.3.1
- another references Serilog 3.1.0
That may look small at first, but it is exactly the kind of thing that can lead to confusion during restore, build, or runtime behavior depending on the setup around it.
NuGet Lens is meant to make that visible immediately.
Instead of manually tracing every reference, the tool lets me see:
- which projects are involved
- what packages each one references
- where a version conflict exists
- how those projects relate to one another
What NuGet Lens Can Do Right Now
The project is still evolving, but it already does a few things that are genuinely useful:
- open a solution through a file picker
- generate an overview of the solution as a visual dependency graph
- detect version conflicts between packages
- open focused project views in tabs
- show a side panel with detected conflicts and suggested action
That is already enough to make problem discovery much faster than doing everything manually.
Tech Stack
So far, I have been building it with:
- .NET / C# for the analyzer
- Tauri
- Rust
- React
- TypeScript
- Tailwind CSS
- React Flow
The analyzer is responsible for reading the solution, projects, package references, and building the graph data.
The desktop app handles the visual side of the inspection experience.
Why I’m Excited About It
What I like most about this project is that it came from a very real frustration.
It was not born from trying to invent a random developer tool for the sake of it. It came from wanting a better way to understand dependency relationships and package issues in a space where the default experience often feels too scattered.
NuGet Lens still needs more polish, more edge-case handling, and more intelligence in the analysis layer, but it already feels like a real tool instead of just an idea.
What’s Next
There are still a few things I want to improve, including:
- richer conflict detection
- better handling of package sources
- more polished focused project views
- more graph clarity for larger solutions
- more actions and inspection capabilities from the UI
My goal is to keep iterating on it, fix bugs, refine the UX, and turn it into something genuinely useful.
Open Source Soon
If things keep moving in the right direction, I plan to release NuGet Lens publicly as an open source project once it is more polished and stable.
I want it to be something people can try, break, improve, or even use as a base for their own ideas.
This is still early, but I’m excited about where it is going.