How to decompile a .NET DLL to C# (2026 guide)

To decompile a .NET DLL back to C#, open the assembly in a .NET decompiler such as Glass.NET, ILSpy or dotPeek — the tool reads the IL and metadata inside the DLL and reconstructs readable C# you can browse, search and export as a project. No source files, PDBs or special build are required; a standard managed .dll or .exe is enough.

That works because of how .NET is built, and it takes about two minutes. Here's the why, the how, and an honest look at which tool to reach for.

Why .NET assemblies decompile so cleanly

A .NET assembly isn't machine code. When you build a C# project, the compiler emits Common Intermediate Language (CIL, or just IL) — a compact, stack-based instruction set — plus a rich metadata table describing every type, method, field, property and parameter by name and signature. That IL and metadata is what ships inside the .dll or .exe. The actual native code isn't produced until runtime, when the JIT (just-in-time) compiler turns IL into machine instructions for the current CPU.

That design is great for portability, but it also means the DLL carries a near-complete description of your program. Type and method names survive. Signatures survive. Control flow is fully recoverable from the IL. A decompiler's job is essentially to run the C# compiler in reverse: read the IL, match its patterns back to C# language constructs (a foreach, an async method, a LINQ query), and pretty-print the result.

This is why unobfuscated .NET decompiles far more readably than, say, a C++ binary. The metadata does most of the work. It's also why obfuscation exists — but more on that later.

Decompile a DLL to C#, step by step

The workflow is the same across tools. Here it is in Glass.NET, with notes on where other decompilers differ.

1. Open the assembly

Launch the decompiler and open your .dll or .exe (in Glass: File ▸ Open Assembly, or drag it onto the window). The tool loads the assembly's metadata and lists it in a tree. You don't need the source or a matching PDB — though if a PDB is present, some tools use it to recover original local-variable names.

2. Browse the type tree

Expand the assembly to see its namespaces ▸ types ▸ members. This mirrors the structure the compiler recorded. Click any type to decompile it on demand — decompilers work lazily, reconstructing C# for the member you select rather than the whole assembly up front, which keeps large libraries responsive.

3. Read the C# (and the IL)

Selecting a method shows the reconstructed C#. Most tools, Glass included, let you switch the same member between a C# view and a raw IL view — useful when the C# looks surprising and you want to confirm what the IL actually does. Glass renders code in an editor (AvaloniaEdit) with folding and syntax highlighting, and supports navigation like Go to Definition and Find All References so you can move through an unfamiliar assembly the way you'd move through your own source rather than scrolling.

4. Export to a buildable project

When you want the code on disk — to diff it, grep it, or open it in Visual Studio — export. In the GUI this is typically File ▸ Export to Project, which writes a .csproj plus the reconstructed .cs files. Glass also has a command-line interface, so you can script it:

# Export a decompiled assembly to a C# project
glass export MyLibrary.dll --output ./MyLibrary.Source

# Generate a software bill of materials for an assembly
glass sbom MyLibrary.dll

(Run glass --help or a subcommand with --help to see the exact options for your build.) A small assembly usually compiles straight back; a large or obfuscated one may need manual fixes before it builds — unresolved references and compiler-generated constructs are the usual culprits.

ILSpy vs dnSpy vs dotPeek vs Glass.NET

All of these are legitimate, widely-used tools. Here's a fair read on each.

ILSpy is the open-source workhorse of the .NET decompiler world. Its decompiler engine, ICSharpCode.Decompiler (MIT-licensed), is genuinely excellent and stays current with new C# language features. Many other tools — including Glass — build on it. If you want a free, no-frills, trustworthy reader and you're comfortable with a lean UI, ILSpy is a great default.

dnSpy / dnSpyEx does something the others don't: it debugs managed assemblies and can even edit and reassemble them. That's a different job from reading code, and for live debugging of a binary it's still unmatched. The catch is that the original dnSpy is archived and no longer maintained; the community carries it forward as dnSpyEx. Reach for it when you specifically need a debugger.

dotPeek, from JetBrains, is a solid free decompiler and a natural fit if you're already in the JetBrains ecosystem — it integrates with ReSharper and can act as a symbol server. It uses JetBrains' own decompiler rather than the ILSpy engine.

Glass.NET is Delta1 Labs' free decompiler. It's built on the same ICSharpCode.Decompiler engine as ILSpy, so the C# accuracy is on par — this isn't a "our decompilation is smarter" claim. What Glass focuses on is the experience around the code: a VS-native Avalonia UI with a real code editor and matching light/dark themes, side-by-side assembly compare with a line diff, SBOM export, and NuGet package authenticity checking so you can confirm a package matches what its author published. It runs on .NET 8, ships for Windows (including an MSIX Store build), and has the glass export and glass sbom CLI subcommands. It is not a debugger — if you need to step through code at runtime, that's dnSpyEx's territory.

There's no single "best" here — pick by workflow. If you want the leanest open-source option, ILSpy. If you need to debug, dnSpyEx. If you live in JetBrains tools, dotPeek. If you want a fast, modern reading experience with diff, SBOM and package verification, Glass. For a deeper feature-by-feature breakdown, see Glass.NET vs ILSpy, dnSpy and dotPeek.

The flip side: protecting your own code

If decompiling a DLL back to clean C# is this easy, the obvious question is: what happens to your code when you ship it? By default, anyone with a decompiler can read your algorithms, licence checks and secrets almost as clearly as you wrote them.

That's what obfuscation is for. Nebula.NET is Delta1 Labs' .NET protection suite — identifier renaming, control-flow flattening, string encryption, anti-tamper, and Enterprise code virtualization that compiles sensitive methods to a custom bytecode VM so there's no IL left to decompile. And because Glass and Nebula come from the same place, you can verify the result yourself: protect a build with Nebula, open it in Glass, and confirm the names are gone, the control flow is unreadable, and the virtualized methods show up as a VM call instead of your logic. Most vendors don't hand you the tool to check their own output.

Which should you use?

For reading and understanding an assembly — a dependency you rely on, a build you've lost the source for, a security review, or checking what an obfuscator produced — any of these free tools will get you accurate C#. Glass.NET is the one to try if you want that reading experience to feel like navigating your own project, with diff, SBOM and authenticity checks built in. It's free forever, no licence or sign-up.

Grab it from the download page or the Glass.NET product page, open a DLL, and read the C# for yourself. And if it's your code you're worried about, decompile it first — then decide whether it needs Nebula.NET.