ILSpy

ILSpy turns a program built on .NET (a DLL or EXE) back into C# code that you can read on screen. This review covers one use: opening a small app you built yourself, seeing that a secret you embedded is plainly readable, and learning why secrets must stay out of the program you ship.

This review is for people who build apps or libraries on .NET and want to see, before release, what someone can read from the build output. After reading it, you can do the following:

• Tell the ILSpy desktop app, the command-line tool (ilspycmd), and the VS Code extension apart
• Open a .NET app you built and read its code and strings
• Confirm that a dummy secret is readable, and rethink how you keep secrets

##What ILSpy is for

ILSpy is a browser and decompiler for .NET assemblies (the packaged files .NET programs run from). According to the official README, it can:

• Turn an assembly back into C# (or show it as IL, the intermediate language)
• Write out a whole project at once
• Search for types, methods, and properties, and follow links between them
• Explore assembly metadata (the tables that describe types and references)
• Open assemblies from disk, from a NuGet feed, and from a running process (the v11.0 release notes say the running-process feature works on all platforms; opening from the GAC is Windows-only)
• Add features with plugins

##Getting it and what it runs on

ILSpy uses the MIT license. The same name covers several entry points for different situations. As of 2026-10-28, the latest version is v11.2.

Here is what the official sources say about the desktop app:

• According to the v11.0 release notes, ILSpy moved from WPF to Avalonia. That brought Linux and macOS support. The WPF app was removed entirely, so from v11.0 on there is only the Avalonia app. The WPF app was Windows-only.
• The Windows zip files come in two kinds: one that needs a separate .NET runtime (x64 and arm64), and one that bundles the runtime (x64). The Linux and macOS downloads bundle the runtime.
• The Windows installer (MSI) installs per user, into %LocalAppData%\Programs\ILSpy. If you unpack a zip, no OS needs administrator rights. For Linux there are also .deb and .rpm packages, which install to /opt/ilspy and need root.
• The README says a Microsoft Store version exists (release versions only).
• The v11.2 downloads include no macOS Intel build and no Linux arm64 build. On those systems, build it yourself with the steps in the README.

Installing ilspycmd needs .NET SDK 10.0.100 or later. On Windows x64 and Linux x64, you get a Native AOT build that needs no .NET runtime. Elsewhere you get a build that runs on the .NET 10 runtime.

##Network connections

Here is what we confirmed by reading the source code:

• Desktop update check. It is on by default. At startup, in the background, the app fetches https://icsharpcode.github.io/ILSpy/updates.xml to see whether a newer version exists. It skips the check if the last successful one was less than 7 days ago. A failure shows no error. You can also run it by hand from “Help → Check for Updates”. To turn it off, clear “Automatically check for updates every week” on the About page.
• Open from NuGet feed. The app connects to a NuGet feed only when you use “Open from NuGet feed”. The default feed is https://api.nuget.org/v3/index.json.
• ilspycmd update check. It is on by default. On every run, it fetches https://api.nuget.org/v3-flatcontainer/ilspycmd/index.json and compares versions. If your copy is old, it prints a request to update on standard error. Add --disable-updatecheck to turn it off.
• VS Code extension. On first start, it downloads a .NET runtime automatically. The runtime goes into a VS Code folder and leaves the system alone. Only on Linux might it also install packages the runtime depends on.

The Privacy section of the README says ILSpy collects no personally identifiable information, sends no user files to third-party services, and uses no telemetry service. The update check code we read does not send the files you open either. We did not read all of ILSpy’s code, though.

##Try it safely: read a dummy secret in your own app

Use a small app you build yourself, not someone else’s software. The string you embed here is a dummy, not a real secret.

1. Install the .NET SDK, then create a console app in a working folder.

   dotnet new console -n demo

2. Replace demo/Program.cs with the following. It writes a dummy API key directly in the code.

   var apiKey = "DUMMY-API-KEY-0000-NOT-REAL";
   Console.WriteLine($"key length: {apiKey.Length}");

3. Run a release build in the demo folder.

   dotnet build -c Release

   The resulting bin/Release/<framework name>/demo.dll is the file you would ship. On my machine (.NET SDK 10.0.402), it was bin/Release/net10.0/demo.dll. A byte search confirmed that the dummy string sits inside this DLL as plain UTF-16. Reading it takes no special skill.

4. From the releases page, download the zip that fits your system, unpack it, and start ILSpy. If you pick the Windows zip that needs a separate runtime, install the .NET 10 runtime first. If you would rather not, pick the zip with selfcontained in the name.

5. Open demo.dll (use the File menu).

6. Select Program in the left tree. The decompiled C# appears on the right, and the dummy string you put in apiKey should be readable as it is.

7. You can also search with a filter, such as c:DUMMY. One of the search filters is Constant. The official docs do not say what range of values Constant covers, though. If nothing turns up, open Program and read it directly.

8. Then rethink how you keep secrets. Don’t write keys, tokens, or passwords in code or in config files that ship with the app. Keep them in environment variables, a secrets manager, or server-side logic. If a build you already shipped contained a real secret, treat it as leaked and issue a new key.

You can also inspect things in bulk from the command line.

1. Install ilspycmd.

   dotnet tool install --global ilspycmd

2. Run it on a DLL. Without an output folder, the decompiled C# goes to standard output.

   ilspycmd --disable-updatecheck demo.dll

3. Searching that output lets you check, on every build, that no secrets remain. It also pairs well with gitleaks, which scans source and repository history for the same problem.

##Common uses

These are the main ilspycmd options. ilspycmd --help lists all of them.

In the desktop app, you follow links to types and their references, and you can move between base types and derived types.

##How ILSpy differs from Ghidra, x64dbg, and jadx

A .NET program ships as intermediate language (IL) plus metadata. That is why ILSpy’s output stays close to the original C#. A native executable does not decompile that cleanly.

To choose by goal: use ILSpy to read the contents of a .NET build, Ghidra for native executables, x64dbg to watch behavior while a program runs, and jadx for Android apps.

##Cautions

##Read next

• jadxa tool that turns Android apps back into Java code you can readcd ../jadx
• Ghidraa reverse engineering tool for reading native programscd ../ghidra
• x64dbga debugger for inspecting Windows programs while they runcd ../x64dbg
• gitleaksa tool that finds secrets left in source and historycd ../gitleaks
• How to set up a safe test labcat ~/guides/lab-setup.md