ILSpy 11.0: the .NET decompiler moves to Avalonia and goes cross-platform

What happened on this date

At 05:13 UTC on 2026-08-12, ILSpy published 11.0 on GitHub (the release candidate had shipped on 2026-08-04). The headline change is the move from WPF to Avalonia: the WPF front end was removed entirely, so ILSpy now runs on Linux and Mac as well as Windows. New features include opening from a NuGet feed, opening from a running process on all platforms, bookmarks in the decompiled C# view and an optional omnibar. The ilspycmd command line gained single-member decompilation with --member, fuzzy matching of type names with -t, and a --dump-table metadata dump mode. Listing and extracting embedded resources and decompiling BAML to XAML carry over from 10.1. The notes also mention hardening fixes against crafted input in several loaders and parsers, and fuzzing of the decompiler engine with NuGet packages. The release is built on .NET 10.0, and the notes point out that the macOS ILSpy.app is neither signed nor notarized.

Why it matters for people protecting app logic

IL and metadata in .NET assemblies have always decompiled to something close to C#, so that part is not new. What 11.0 changes is the barrier and the setting. Analysts no longer need Windows, and the command line can emit exactly one member, which makes it easy to script the extraction of snippets for an LLM to read. Opening from a running process means analysis is no longer limited to files on disk, so approaches that rely on assemblies being decrypted only at runtime should be assumed exposed once the assembly is loaded. Another detail is the hardening against crafted input: tricks that try to stop analysis by crashing the decompiler always had a short shelf life, and it just got shorter. To be clear, the release notes describe features only; we have not measured their effect on any particular protection product.

Concrete checks

First, run ilspycmd against your own release assemblies in CI and include the output in release review, so you see exactly what you are handing to users. Second, check embedded resources and BAML/XAML for connection strings, internal endpoints or licensing logic. Third, do not treat "the decompiler cannot open it" as a protection goal; anything that depends on parser bugs should be considered temporary. Fourth, keep license validation and key business rules on the server, leaving the client only the logic it needs for presentation and interaction. Repeat the ilspycmd review whenever you upgrade the .NET SDK or change trimming, publishing or packaging options, because each can change what ends up in the shipped assemblies.

Your checklist

• Decompile your release assemblies with ilspycmd in CI and review the output
• Check embedded resources and BAML/XAML for sensitive content
• Do not treat decompiler-crash tricks as lasting protection
• Keep licensing and key rules on the server