dotPeek is the safer first pick for teams already using JetBrains tools, while ILSpy is the cleaner choice for open source, lightweight assembly inspection. Both can inspect .NET assemblies, recover readable C# from IL, browse metadata, and help explain what a compiled library is doing.
TLDR: dotPeek suits professional teams that want polished search, Visual Studio-style workflows, PDB generation, and ReSharper-like navigation. ILSpy suits developers who want a fast, free, open source decompiler with strong C# output and fewer product ties. In one common support case, a team comparing a vendor DLL across three releases may save 30–45 minutes by using dotPeek’s richer search and symbol tools, while a solo developer may inspect the same assembly in ILSpy with almost no setup. For most assembly inspection tasks, the final choice depends less on decompilation quality and more on workflow, licensing, and debugging needs.
What dotPeek Does Well
dotPeek is JetBrains’ free .NET decompiler. It opens DLL, EXE, NuGet package, and assembly folders, then shows reconstructed C# code from compiled IL. It also displays metadata, resources, references, and type hierarchies.
Its strongest feature is polish. The interface feels close to JetBrains IDE habits. Search is solid. Navigation between classes, methods, and symbols feels predictable. A developer can jump from a method call to its declaration, inspect inherited members, and check external dependencies without much friction.
dotPeek also supports PDB generation. That matters when a team needs to debug third party code without original symbols. It can act as a symbol server, which helps when stepping through decompiled code in Visual Studio. For support teams dealing with black box libraries, that feature alone can justify keeping it installed.
The catch is that dotPeek can feel heavier than needed for simple checks. Opening a large solution cache or scanning a packed dependency folder may take longer than expected. It is not painful, but it can feel like using a full toolbox to tighten one screw.
Image not found in postmetaWhere ILSpy Wins
ILSpy is a free, open source .NET assembly browser and decompiler. It is widely trusted because it is transparent, fast, and focused. There is no account workflow, no commercial shell around it, and no hidden product ladder.
ILSpy is often the better pick for quick inspection. A developer can open an assembly, review types, switch language output, inspect IL, and export a project. It supports modern C# patterns well, though any decompiler can struggle with compiler-generated state machines, async code, iterators, and aggressive obfuscation.
Its project export feature is useful when legacy code is missing. A company may find an old internal DLL but no source repository. ILSpy can produce a rough project structure. That output still needs review. Decompiled code is rarely a perfect source replacement. Names, comments, formatting, and intent are often gone.
Honestly, it feels like ILSpy respects the user’s time. It opens quickly, does the job, and stays out of the way. For many engineers, that matters more than a polished commercial-grade interface.
dotPeek vs ILSpy: Practical Comparison
| Area | dotPeek | ILSpy |
|---|---|---|
| Cost | Free | Free and open source |
| Best fit | JetBrains users, debugging, symbol work | Fast inspection, open source workflows |
| Project export | Supported | Supported and commonly used |
| Debug support | Strong PDB and symbol options | Useful, but less integrated for some setups |
| Speed | Good, sometimes heavier | Usually very quick |
For decompilation quality, the gap is not huge in normal business code. Both tools can reconstruct readable C# from ordinary .NET assemblies. The difference appears in edge cases. Complex generics, async methods, obfuscated code, expression trees, and compiler tricks may produce different results.
When accuracy matters, developers should compare output from more than one tool. If dotPeek and ILSpy both produce similar logic, confidence rises. If they disagree, the IL view should be checked. Decompiled C# is an interpretation, not the original source.
Other .NET Decompilers Worth Knowing
dnSpyEx is a community-maintained continuation of dnSpy. It remains popular because it supports editing and debugging assemblies. That makes it powerful, but also risky in careless hands. Security researchers and modders often value it. Corporate teams may restrict it because patching binaries can create audit issues.
.NET Reflector is one of the older commercial decompilers. It earned its reputation years ago and still has users who like its add-ons and mature behavior. The downside is simple: many teams prefer free tools unless Reflector’s specific workflow saves billable time.
JustDecompile from Telerik was once a common free option. It may still appear in older tool lists, but active teams usually check current maintenance before adopting it. Decompiler tools age quickly when .NET adds new syntax and compiler behavior.
Common Assembly Inspection Use Cases
- Checking a third party DLL: Teams inspect public APIs, references, and suspicious behavior before adding a dependency.
- Recovering lost source: Decompiled output can help rebuild a project when source control is missing.
- Debugging production bugs: Engineers compare installed binaries with expected versions and symbols.
- Security review: Analysts inspect logic, hardcoded secrets, unsafe calls, and network behavior.
- Version comparison: Support staff check what changed between two vendor releases.
Expect to waste time on obfuscated assemblies. Names such as a.b.c, flattened control flow, encrypted strings, and anti-debug tricks can make every tool look worse. In those cases, IL inspection, runtime tracing, and logging may matter more than C# reconstruction.
Which Tool Should a Team Choose?
A JetBrains-heavy team should start with dotPeek. It fits familiar habits and works well beside Rider, ReSharper, and other JetBrains products. Its symbol support is also a real advantage for debugging scenarios.
A mixed team, student group, open source maintainer, or security analyst should start with ILSpy. It is easy to share, easy to install, and easy to trust. Its open source status also helps when policies require tool transparency.
For advanced binary editing or live debugging of assemblies, dnSpyEx may be the extra tool. It should be treated with care. Editing compiled code can solve a short-term problem and create a long-term maintenance mess.
The best setup is often two tools, not one. ILSpy handles quick reads. dotPeek handles deeper inspection and symbol-heavy debugging. That pair covers most .NET assembly inspection work without paid software.
Legal and Ethical Limits
Decompilers are legitimate engineering tools, but rights still matter. Developers should check license terms before inspecting commercial software. Internal review, malware analysis, compatibility checks, and debugging may be allowed in many settings, but redistribution of recovered source is a separate issue.
Companies should also avoid treating decompiled code as clean source. It may contain copyrighted material. It may also be wrong in subtle ways. Recovered code should support understanding, not replace proper source ownership.
FAQ
Is dotPeek better than ILSpy?
Not always. dotPeek is better for JetBrains-style navigation, PDB generation, and symbol workflows. ILSpy is better for quick, open source inspection with minimal friction.
Can dotPeek and ILSpy recover the original source code?
They can recover readable C# in many cases, but not the exact original source. Comments, original formatting, local variable names, and developer intent are often lost.
Is ILSpy safe to use?
ILSpy is open source and widely used. As with any tool, it should be downloaded from its official repository or trusted release source.
Can these tools inspect obfuscated assemblies?
Yes, but results may be ugly. Obfuscation can rename symbols, hide strings, alter flow, and confuse C# output. IL view may be more reliable.
Which decompiler is best for debugging third party DLLs?
dotPeek is often the better choice because of its PDB and symbol server support. ILSpy still works well for reading and exporting code.
Should a team keep more than one .NET decompiler?
Yes. Using dotPeek and ILSpy together gives stronger coverage. Differences in output can reveal where a method needs closer IL-level review.