.NET Obfuscation by Platform
The .NET decompilation vulnerability is the same across every platform - your compiled code is readable, and the techniques for protecting it are consistent. What changes by platform is the configuration: the specific failure modes, the build pipeline integration, and the patterns that need special handling to avoid breaking your application.
This cluster covers four platform contexts where those differences matter most. Each page is a self-contained guide for that platform - threat model, configuration specifics, and a working setup you can apply directly.
.NET MAUI
Protecting .NET MAUI Applications →
Xamarin reached end-of-life in May 2024, pushing a large population of mobile developers into .NET MAUI migrations. This page covers what changes in the obfuscation configuration when moving from Xamarin to MAUI, the Android AOT constraint that affects calli-based protection, and why XAML data bindings work correctly without special configuration given ArmDot's default behavior on public members.
If you are rebuilding your Xamarin obfuscation setup for MAUI, start here.
Blazor WebAssembly
Blazor WebAssembly Obfuscation →
Blazor WASM is the platform with the most exposed threat model in the .NET ecosystem. When a user opens a Blazor WebAssembly application, the browser downloads your compiled .NET assemblies over HTTP and executes them client-side. Anyone who visits your site can save those files and open them in ILSpy. This is not a misconfiguration - it is the fundamental architecture.
This page explains why AOT compilation does not solve this, how [Parameter] and [JSInvokable] attributes require specific handling, and when moving logic to a server-side API is the better answer.
WPF and WinForms
WPF and WinForms Obfuscation →
WPF and WinForms remain the foundation of a large portion of commercial Windows software - ERP systems, medical tooling, document management, point-of-sale applications. These are the applications where the IP concern, the licensing concern, and the budget to address both are most likely to align.
The key technical consideration for WPF is data binding: {Binding PropertyName} expressions resolve property names at runtime through reflection, and INotifyPropertyChanged implementations that use string literals rather than [CallerMemberName] create a mismatch when the property is renamed. This page covers both patterns and how ArmDot's default behavior handles the standard MVVM case automatically.
Unity
The most widespread misconception in Unity code protection: switching to the IL2CPP scripting backend makes your game code protected. It does not. IL2CPP generates global-metadata.dat alongside the native binary, containing every class, method, and field name from your original C# code. Tools like Il2CppDumper reconstruct a full symbol map from it in seconds.
This page corrects that misconception, covers the Mono backend (full .NET assembly exposure), explains what ArmDot preserves automatically for Unity builds (MonoBehaviour callbacks, SendMessage targets, [SerializeField] fields), and shows the ArmDotConsole-based workflow for integrating obfuscation into a Unity build pipeline.
Where to start
If you are migrating from Xamarin: start with the MAUI page - it has a dedicated migration section covering exactly what changes.
If you are building a Blazor WebAssembly application: start with the Blazor WASM page - the threat model is architecturally unusual and worth understanding before evaluating any solution.
If you are shipping a commercial Windows desktop application: the WPF/WinForms page is written specifically for your context.
If you are a Unity developer: start with the Unity page - the IL2CPP section alone is worth reading before making any decisions about your protection strategy.
Back to: .NET Obfuscation: The Complete Developer Guide →
Protect your .NET application with ArmDot
ArmDot supports all four platform contexts on this page - MAUI, Blazor WebAssembly, WPF/WinForms, and Unity (Mono backend) - with NuGet integration for standard .NET projects and ArmDotConsole for build pipelines that require post-build assembly processing. Free trial available - protected assemblies stop working after two weeks.