ILSpy: the .NET decompiler you can install as a dotnet tool

What ILSpy solves, and for whom

A .NET assembly is IL plus metadata, not C#. When you have a DLL and no source, tools that show you IL force you to reconstruct control flow and type shapes in your head. ILSpy's job is to turn that IL back into readable C# so you can answer concrete questions: what does this method actually do, which types does this library expose, why does this NuGet package behave differently from its documentation. The README describes it as an "open-source, cross-platform .NET assembly browser and decompiler", and the desktop UI runs on Windows, Linux and macOS on Avalonia. That cross-platform claim is worth separating from the rest: some features, such as opening an assembly from a running process or from the GAC, are marked Windows-only in the feature list, so Linux and macOS users get a smaller surface than the headline suggests. The audience is broad. Library authors checking what their own compiler emitted, engineers auditing a dependency before adding it, and people debugging a stack trace that points into a third-party binary all fit. So do plugin authors, because ILSpy is extensible through plugins and the engine is published separately as NuGet packages.

The engine is the product; the window is one frontend

The repository layout makes the architecture plain. ICSharpCode.Decompiler holds the decompiler engine, ICSharpCode.ILSpyX is a separate package for use in your own projects, ICSharpCode.ILSpyCmd is the command-line frontend, ICSharpCode.Decompiler.PowerShell wraps the engine in cmdlets, and the ILSpy project is the Avalonia desktop UI. Everything else consumes that engine. The README lists the frontends explicitly: the desktop app, the Visual Studio 2022 and 2026 extensions, the VS Code extension, the dotnet tool, the C# extension for VS Code (decompilation support is behind the "Enable Decompilation Support" setting), and the NuGet packages. It also notes that Visual Studio 2022 and 2026 ship decompilation support for F12 enabled by default, using engine versions 8.2 and 9.1 respectively. That detail is the most practically important thing on the page. If you press F12 on a type from a referenced assembly in Visual Studio and it shows you C#, you are already running an older ILSpy engine, and the version is tied to your IDE rather than to the latest release. Decompilation output is a best-effort reconstruction, not the original source. Names of locals and compiler-generated types are invented, and constructs the C# compiler erases are approximated. The README links a language support status issue rather than claiming complete coverage, which is the honest framing.

Installing ILSpy and decompiling a DLL with ilspycmd

For a first real use, the command-line tool is the shortest path and needs no IDE. The README points to the ILSpyCmd project in the repository and to the ilspycmd package on NuGet as a dotnet tool. The README does not print an install command for it, so follow the package page it links to, then read the ILSpyCmd directory in the repository for the argument syntax, which the README also does not spell out. If you prefer a graphical workflow, download the latest release from the Releases page, or install the Microsoft Store package, which the README says carries RTM versions only. Building from source is a heavier commitment. On Windows the documented path is Visual Studio with the .NET Desktop Development workload; on Unix and macOS the README gives these two build commands:

dotnet build ILSpy.Desktop.slnf
dotnet build ILSpy.XPlat.slnf

The first builds the cross-platform Avalonia desktop UI, which the README says you run with `dotnet run --project ILSpy`; the second builds only the CLI tool and the PowerShell cmdlets. Both source paths require the ILSpy-Tests submodule, fetched with `git submodule update --init --recursive`, and the README warns that the solution expects the .NET 11.0 SDK for unit tests, with Visual Studio refusing to load some projects if its bundled SDK has been upgraded.

ReadyToRun, BAML and the limits of the output

Two features go beyond plain IL decompilation. ReadyToRun binary support for .NET Core is documented with a tutorial on the wiki, and a BAML to XAML decompiler handles compiled XAML, with !AvaloniaResources support listed alongside it. Those matter if you are inspecting a published .NET application rather than a library: ReadyToRun images contain precompiled native code, and the README treats that as a separate, tutorial-worthy case rather than something the default view covers. The limitation to internalise is that decompiled C# is a reading aid. The README does not claim round-trip fidelity, and the linked language support status issue exists precisely because some constructs cannot be expressed back in C# exactly as the compiler saw them. Deeply nested or highly optimized methods are the usual failure mode. The README's build notes hint at why: ILSpy.exe is built with a 16MB stack instead of the default 1MB because "the decompiler makes heavy use of recursion, where small stack sizes lead to problems in very complex methods". If the desktop application can hit stack pressure on pathological input, then a script that feeds arbitrary assemblies to the engine should expect occasional failures and handle them rather than assuming every input decompiles cleanly.

ILSpy compared with dnSpy, and when it is the wrong tool

The most common comparison is with dnSpy, and the difference is in what each tool is built to do. ILSpy is an assembly browser and decompiler; the README lists navigation, bookmarks, history, a metadata explorer and search options, all aimed at reading and understanding code. dnSpy is a debugger and assembly editor first, which is why people reach for it when they want to step through a running process or patch an assembly. If your task is to attach to a live process and set a breakpoint in a method that has no source, ILSpy is the wrong tool, and the README does not present it as a debugger. The same applies to editing: nothing in the feature list describes writing modified IL back into an assembly. The other boundary is automation. The desktop UI is a reading environment, and the README's answer to programmatic use is not the app but the ICSharpCode.Decompiler and ILSpyX NuGet packages, the PowerShell cmdlets, and ilspycmd. Choosing the desktop app as a build step would mean driving a GUI, which the project does not document as a supported path. Finally, if you only need to glance at a type while coding, you may not need ILSpy installed at all: Visual Studio already has F12 decompilation on by default, and the C# extension for VS Code has a decompilation setting to switch on.

Licence, maintenance and upgrade cost

ILSpy is distributed under the MIT License. The README points to doc/ILSpyAboutPage.txt for details and to doc/third-party-notices.txt for the open-source libraries it includes, which is the file to read before redistributing a build, since MIT covers ILSpy itself but not necessarily everything linked into it. This is a description of what the repository states, not legal advice; if you ship ILSpy inside a product, have someone review those two files. On maintenance, the project is not archived and the last push to master was on 2026-09-20, with v11.0 released on 2026-08-12 after a release candidate and a preview. The upgrade cost is mostly about version skew rather than breaking API changes. Because Visual Studio 2022 and 2026 embed engine versions 8.2 and 9.1 for their built-in F12 decompilation, an IDE user can be several major versions behind the standalone release without noticing. If you script against ilspycmd or the NuGet packages, pin the version you install and treat engine upgrades as something to test against your own assemblies, since the decompiler's output is the interface you depend on. The repository's own build scripts, restore.ps1, build.ps1 and publish.ps1, exist for building from source rather than for consuming the tool.

Editorial conclusion

Adopt ILSpy if you need to read compiled .NET code and want the same engine the C# extension in VS Code and Visual Studio already use. Do not adopt the desktop app as an unattended pipeline component: the README points to the ICSharpCode.Decompiler and ILSpyX NuGet packages for your own projects, and the repository ships PowerShell cmdlets for scripting. Verify first that the language features in your target assembly are listed as supported in issue 829, and confirm the ILSpy version your toolchain bundles before filing a decompilation bug.

Frequently asked questions

Official sources

1. icsharpcode/ILSpy on GitHub
2. Issues
3. License: MIT
4. README
5. Releases