ILSpy 11.0 Preview 1: Avalonia port, newer C# constructs and hardened parsers

What happened on 19 July

On 19 July 2026 at 14:18 UTC, ILSpy 11.0 Preview 1 was published on GitHub. According to its notes, the UI was ported to Avalonia 12 and the WPF UI removed, CI now builds, tests and packages on Linux and macOS, and .NET 10 is required; the macOS app is neither signed nor notarized. On the decompiler side, it handles await on dynamic expressions and foreach over inline arrays, and decompiles runtime async without a separate C# 15 setting. Several changes bound parsing against crafted input, covering Xamarin compressed file headers, WebCil section access, the BAML reader, .rsrc resource trees and single-file bundle signatures. The page also warns that the project does not own the ilspy.org domain and to download only from GitHub Releases.

What it means for protecting .NET apps

The notes carry three lessons for .NET developers. First, decompilers follow new language features quickly, so relying on recent syntax to make code hard to reconstruct is not a dependable assumption. Second, packaging formats such as Xamarin compressed assemblies, WebCil and single-file bundles are within the scope of mainstream decompilers; packaging changes the file shape, not its confidentiality. Third, hardening against crafted input means techniques that rely on crashing analysis tools tend to stop working across versions, and they can also hurt your own compatibility and maintainability. A steadier stance is to assume IL is readable and to place logic that truly needs protection on the server or in an evaluated native implementation.

Checks you can run

First, open your own shipped assemblies and resources, including BAML, Avalonia resources and embedded files, in the decompiler your team actually uses, and confirm they contain no connection strings, license-verification keys or internal endpoints. Second, if you use single-file publishing, trimming or Native AOT, re-check after every .NET or toolchain upgrade which managed code and metadata the final artifact really contains. Third, treat the analysis tools your team uses as part of the supply chain: obtain them only from official release pages and verify the source. When describing protection to customers, avoid phrases such as cannot be decompiled.

Your checklist

• Inspect your own assemblies and resources for sensitive data with a mainstream decompiler
• Re-check single-file, trimmed or AOT output after every .NET upgrade
• Obtain internal analysis tools only from official release pages