What Obfuscation Breaks: Reflection, Serialization, and What to Exclude

When you inject an obfuscator into a .NET application, it can cause previously working components to break. For instance, the JSON returned by an API might have fields named "a" and "b" instead of their original names. Calls to methods using reflection, such as Type.GetMethod("Process"), may return null if the method name has been changed to something like "a".

WPF or XAML bindings that rely on property names, such as {Binding CustomerName}, may also fail to bind correctly if the property name is renamed. Additionally, Dependency Injection may not find services if they are mapped by name instead of by interface.

The core issue behind these problems is that names are the weakest link in obfuscation. Renaming a member at runtime still refers to it by its original name, which no longer exists in the assembly. Any runtime code that tries to retrieve a member based on its name will fail if the name has been obfuscated.

Serialization, reflection, data binding, and convention-based frameworks like Dependency Injection, Entity Framework Core, AutoMapper, and MVC model binding are all examples of code paths that rely on name resolution. When names are renamed, these components break, leading to failures in serialization, deserialization, reflection, data binding, and framework functionality.

To mitigate these issues, it is essential to exclude from renaming only the specific names that are resolved by string at runtime. These include serialized types (such as DTOs, settings files, message payloads), members reached through reflection, types and members referenced from XAML or other markup, and the public API surface of libraries that other assemblies compile against. This can be achieved using attributes or configuration rules to mark these types and members to be excluded from renaming.

Another approach is to decouple the wire names from the code names, so that serialization formats remain unchanged even if the member names are renamed. For example, explicitly specifying the JSON property names using attributes like [JsonPropertyName("total")] allows the serialized JSON to use the correct names regardless of the member names in the IL.

The most crucial point is that exclusion from renaming does not mean the code is unprotected. Obfuscation can still apply to other transformations, such as control-flow flattening, encryption of string literals, and masking of constants. Exclusions are purely name-level, not protection-level.

A reliable workflow involves obfuscating the code first and then running the complete test suite against the obfuscated build, not just the un-obfuscated version. Integration tests that serialize DTOs, hit APIs, or exercise plugins will immediately expose any issues caused by name resolution breakage. By fixing each failure by excluding the specific contract or pinning the wire names, rather than disabling renaming altogether, obfuscation becomes a one-time setup step rather than a recurring mystery, keeping the logic hard to read while preserving the integrity of the names your program depends on.