Choose a .NET obfuscator by testing whether the transformed application still satisfies its reflection contracts—not by assuming that framework attributes or a vendor’s compatibility feature will preserve behavior. Name-based lookups can break when obfuscation renames types or members. A sound evaluation combines selective name preservation or mapping with runtime tests against the actual obfuscated build.
Will obfuscation break reflection?
It can. Calls such as Type.GetType, name-based GetMethod or GetProperty, and string-based activation depend on names that symbol obfuscation may change. The same risk can arise indirectly when a serializer, plugin loader, dependency-injection container, ORM, UI framework, or configuration file discovers types or members dynamically. Obfuz’s reflection documentation describes this metadata-name problem and approaches to detecting and handling it: Obfuz reflection support.
As an Amazon Associate I earn from qualifying purchases.
The relevant question is not whether an obfuscator says it supports reflection, but whether your app’s specific lookup paths work after transformation. A tool can warn about some risky patterns without discovering every lookup performed by dependencies, generated code, external manifests, or runtime conventions.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →What should remain stable—and what can change?
Start by identifying which names are part of a runtime contract. Preserve names when an external component or persisted configuration must continue to refer to them as written. If names may change internally, use a supported mapping mechanism only where callers can reliably translate an original name to the runtime type or member.
#1 Best Overall
- Preserve or exclude: Keep names unchanged for contracts that must be resolved directly by their original name. Selective exclusions can apply to particular types, members, or broader scopes, depending on the tool.
- Map names: A tool-provided or manually maintained map can connect original names with transformed names. Verify how mappings are generated, deployed, loaded, and used by each lookup path.
- Test the transformed output: Treat compatibility as a property of the built application and its runtime environment, not a guarantee inferred from configuration.
Obfuz documents offline compatibility warnings, ways to disable symbol obfuscation for selected metadata, and helpers that map original full type names to runtime types. Its documentation also describes registration requirements before lookups; account for that setup and verify which reflection consumers it covers rather than assuming every framework lookup is intercepted. Its Unity-specific serialization guidance should not be generalized to ordinary .NET applications. See Obfuz’s reflection documentation.
Do .NET obfuscation attributes guarantee name preservation?
No. Microsoft’s ObfuscationAttribute and ObfuscateAssemblyAttribute communicate instructions to tools; applying an attribute does not itself obfuscate code. Microsoft explicitly cautions: “However, there is no guarantee that a particular tool follows Microsoft recommendations.” Treat attributes as annotations whose effects must be confirmed for the obfuscator and version you use. See Microsoft Learn’s ObfuscationAttribute documentation.
ObfuscationAttribute can be applied at assembly, type, and member scope. At assembly or type scope, its effect can extend to members unless ApplyToMembers is false. Its Exclude property expresses whether the entity should be excluded from obfuscation, but tool interpretation and precedence still need verification. The Feature value is tool-recognized; Microsoft describes “default” and “all” as conventions, not as proof that every vendor implements identical behavior. Check the target tool’s documentation and inspect the output. Details are in the same Microsoft Learn reference.
Free tools Windows power users keep installed
One-click scans. No signup required.
Assembly intent matters too. Microsoft describes a private assembly generally as one used only by its application rather than intended as a library for other software; marking it private generally tells an obfuscator it may rename public methods during application obfuscation. Public libraries generally need public member names to remain stable for consumers. Consult Microsoft’s ObfuscateAssemblyAttribute constructor documentation, then verify the particular tool’s handling.
How to compare obfuscators for a reflection-heavy app
Use these questions to compare candidates on the same application slice and deployment requirements:
| Evaluation area | What to verify |
|---|---|
| Reflection controls | Can the tool flag risky lookups? Can rules keep selected types, members, namespaces, or names found in strings unchanged? If names are renamed, is there a mapping mechanism, and what must the app register or call for it to work? |
| Configuration and precedence | Can exclusions live in version-controlled configuration and run consistently in CI? Are framework attributes supported? If attributes, force-include rules, skip rules, and public/private API settings conflict, which one wins? |
| Framework and library behavior | Test the serializers, DI container, plugin loader, ORM, UI framework, and other reflection consumers actually used by the app. Do not infer compatibility for one framework from support for another. |
| Build and deployment | Check target framework and SDK support, output format, CI integration, signing and re-signing, symbol or mapping files, and stack-trace deobfuscation. |
| Generated code | Find out how compiler-generated types, async and iterator artifacts, and special-name members are handled. Confirm any generated-code exclusion feature exists and behaves as expected in the exact release being evaluated. |
| Protection goal | Decide whether symbol renaming is sufficient or whether you also need other transformations. Weigh added protection against compatibility and debugging costs; do not treat obfuscation as secure secret storage or a guarantee against reverse engineering. |
For example, Obfuscar is an open-source obfuscator under the MIT license; its project describes its features as basic obfuscation. Its configuration guide documents skip rules, attribute-based exclusions, and rule precedence. These details make it a candidate to test, not evidence that its output will satisfy a particular app’s reflection contracts. See the Obfuscar repository and its configuration guide.
Rank #4
How to evaluate a candidate safely
- Inventory dynamic lookups. Search application code for
Type.GetType, assembly and type enumeration, name-based method or property lookup, and string-based activation. Also document configuration-driven binding, plugin manifests, serializers, and dependency or framework behavior; not every lookup will appear as an obvious call in your own source. - Choose a representative slice. Build a production-like portion of the app with substantial reflection use, its real dependencies, and the target framework and SDK settings.
- Configure conservatively. Preserve names required by external contracts. Use mapping only for lookups that can actually invoke it. Check the configuration into source control, and record the precedence rules you rely on.
- Run tests on the obfuscated assemblies. Exercise reflection paths and application startup, plus serialization round trips, plugin discovery, signing, and install or upgrade workflows where applicable. Tests against only unobfuscated assemblies do not validate the transformation.
- Inspect output and diagnostics. Review warnings, maps, stack traces, and output metadata. Confirm the tool documents support for the target runtime and SDK versions you build with.
- Expand transformations in steps. Once the compatibility suite passes, increase obfuscation incrementally and retain regression tests for each known reflection contract.
What Obfuscar users should test specifically
Obfuscar’s configuration guide warns that XmlSerializer can encounter duplicate generated names after obfuscation. It suggests setting ReuseNames to false as a workaround for type, field, and property names. If the app uses XmlSerializer, test real serialization and deserialization with the configured output rather than treating this setting as a universal fix.
Recommended Free Tools
The same guide states that signed assemblies must be re-signed after obfuscation. Include the signing step in the production-like build and validate the resulting artifact and deployment flow.
Best Value
Obfuscar also documents SkipGenerated for excluding compiler-generated types, available from version 2.2.48, and decorator and decoratorAll SkipType attributes, available from version 2.2.49. The guide describes SkipGenerated as preview functionality, so check its status and behavior in the exact release you plan to use. These version details and caveats are in the Obfuscar configuration guide.
What obfuscation can—and cannot—protect
Obfuscation can raise the effort required to understand or modify an application, but it is not a guarantee against reverse engineering. In particular, reversible string hiding does not make embedded credentials, API keys, or other secrets safe: an application that must recover and use a value cannot rely on obfuscation as a substitute for an appropriate secret-management design. Obfuscar’s project describes its basic obfuscation scope in the project repository; its configuration documentation discusses string hiding and its caveat in the configuration guide.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
