Use JetBrains dotPeek if you want a polished, free .NET decompiler with strong search, project export, and smooth debugging help. Pick ILSpy if you want open source tools, command line use, and a lighter feel.
TLDR: dotPeek is great for teams that already like JetBrains tools and need to inspect assemblies fast. ILSpy is better if you want open source freedom and automation, such as decompiling 500 DLLs with ilspycmd. In a small test case, a developer checking 20 third party assemblies might save 30 to 40 minutes by using dotPeek search and project export. If you only need quick checks, both tools are good enough.
What dotPeek actually does
dotPeek takes compiled .NET files and turns them back into readable code.
That means files like:
- .dll libraries
- .exe apps
- .nupkg NuGet packages
- .winmd metadata files
It shows C# code from compiled IL. The result is not the original source. Comments are gone. Some names may look weird. Async code can look like it went through a blender. Still, it is often close enough to understand what is going on.
That is the point. You use dotPeek when the source code is missing, broken, hidden, or stuck in some old repository that nobody wants to talk about.
dotPeek vs ILSpy: the quick fight
dotPeek feels like a JetBrains product. It is tidy. It has strong search. It connects well with the JetBrains way of working. If you use ReSharper or Rider, it feels familiar.
ILSpy feels lean and direct. It is open source. It starts fast. It has a command line tool. It is loved by people who want control without extra fluff.
Honestly, it feels like dotPeek brings the comfy chair, while ILSpy brings the pocket knife.
| Tool | Best for | Main weak spot |
|---|---|---|
| dotPeek | GUI review, search, project export, debugging support | No source editing or live patching |
| ILSpy | Open source work, fast checks, automation | Interface feels more basic |
| dnSpyEx | Debugging and editing assemblies | Can be overkill for simple review |
| .NET Reflector | Older enterprise workflows | Paid tool, less common now |
Where dotPeek shines
dotPeek is very good when you need answers fast.
Say your app crashes inside PaymentGateway.Core.dll. You do not have the source. Great. Classic pain. Open the DLL in dotPeek. Search for the method name from the stack trace. Read the decompiled code. Find the null check that should have existed. Mutter at your screen. Fix your calling code.
Its best features are simple but useful:
- Assembly explorer: See types, namespaces, methods, and references.
- Search everywhere: Find classes, symbols, and text.
- Export to project: Turn a decompiled assembly into a Visual Studio style project.
- PDB generation: Create symbol files for debugging decompiled code.
- IL view: Check the lower level instructions when C# is not enough.
The project export feature is a big win. It lets you open decompiled code like a normal project. Not perfect. But it is much nicer than clicking through a hundred classes one by one.
Where ILSpy wins
ILSpy wins when you care about openness and scripts.
Its command line tool, ilspycmd, is a very big deal. You can use it in build scripts. You can inspect many assemblies at once. You can dump output for review. That helps with audits and repeatable checks.
For example, imagine you receive 300 plugin DLLs from vendors. Opening each one by hand is a bad afternoon. With ILSpy command line, you can batch export the code, scan it, and flag risky calls. That is not glamorous. It is just useful.
ILSpy also has a clean C# decompiler. It supports modern .NET pretty well. It can show IL. It can inspect NuGet packages. It is small enough that you do not feel like you installed a spaceship to read one DLL.
What about dnSpyEx?
dnSpy was famous because it could decompile, debug, and edit assemblies. The original project stopped. dnSpyEx keeps the idea alive.
This tool is powerful. Maybe too powerful for casual use.
Use dnSpyEx when you need to debug an assembly without source code. You can set breakpoints. You can inspect runtime values. You can edit IL or code in some cases.
That sounds cool. It also gets risky.
If you change a compiled assembly, you can break signing, licensing, version checks, or deployment rules. Expect to waste time on weird errors if you patch things without a plan. A one line change can turn into two hours of “why does this not load?”
What about .NET Reflector and JustDecompile?
.NET Reflector was once the big name. Many .NET developers used it before free tools became so good. It still exists as a paid product. Some companies keep it because it fits old habits and plugins.
Telerik JustDecompile was once popular too. It is less active now. You may still see it in older blog posts and tool lists. For most new work, dotPeek or ILSpy will be the better pick.
Which tool should you choose?
Here is the simple version.
- Choose dotPeek if you want a friendly desktop tool.
- Choose dotPeek if you use JetBrains products already.
- Choose ILSpy if you want open source software.
- Choose ILSpy if you need command line decompilation.
- Choose dnSpyEx if you need debugging or assembly editing.
- Choose Reflector only if your team already depends on it.
For everyday reverse engineering, dotPeek and ILSpy cover most needs. Really, most developers should install both. They are free. They do slightly different jobs. There is no trophy for suffering with one tool.
Real user case: the mystery DLL
A team inherits an old ASP.NET app. It has five private DLLs. No source code. No docs. Of course.
The app fails when users upload large files. The stack trace points to Legacy.Upload.dll. The team opens it in dotPeek. They find a hard coded 10 MB limit in 90 seconds. Then they export the project and inspect related classes.
Next, they use ILSpy command line to export all five DLLs. They search the output for other hard coded limits. They find six more. In one hour, they know more about the old app than the handover document ever said.
That is the real magic. Decompilers turn mystery into plain annoyance. Annoyance is fixable.
Things decompilers cannot fix
Decompilers are not time machines.
They cannot restore comments. They cannot always recover original variable names. They may produce ugly code for async methods, iterators, lambdas, and compiler generated classes.
Obfuscation makes things worse. If a DLL was protected with a strong obfuscator, you may see names like a.b.c(). That is technically code. It is also headache soup.
Legal rules matter too. Inspect code you own. Inspect code you are allowed to review. Do not use decompilers to steal software or bypass licenses. That is not clever. That is trouble.
Final verdict
dotPeek is the best easy pick for visual .NET assembly reverse engineering. It is clean, free, and strong at search and project export.
ILSpy is the best pick for open source fans and automation. It is fast, scriptable, and widely trusted.
Use dotPeek when you want to read code like a human. Use ILSpy when you want repeatable output or batch work. Keep dnSpyEx nearby for debugging emergencies. Your future self will thank you, probably while grumbling at a DLL from 2014.