Incremental Obfuscation Enterprise
When you ship a new version of your application, symbols that existed in the previous version should keep the same obfuscated names. This ensures that serialized data (saved files, database blobs, network messages) created by the old version can be deserialized by the new version. Demeanor's incremental mode loads the prior version's JSON report and reuses its name mappings.
Usage
| CLI | MSBuild | Description |
|---|---|---|
--report | <ObfuscateReport>true</ObfuscateReport> | Generate JSON report (save after each release) |
--report-file <path> | <ObfuscateReportFile> | Custom report path |
--prior-report <path> | <ObfuscatePriorReport> | Load prior version's report |
Workflow
# Version 1.0 — generate the initial report
demeanor --report --report-file v1.0-report.json MyApp.dll
# Version 2.0 — load v1.0 report to preserve name mappings
demeanor --report --report-file v2.0-report.json \
--prior-report v1.0-report.json MyApp.dll
# Version 3.0 — chain from v2.0
demeanor --report --report-file v3.0-report.json \
--prior-report v2.0-report.json MyApp.dll What the Report Contains
The JSON report maps every renamed symbol from its original fully-qualified name to its obfuscated name, plus records excluded symbols and the reason for each exclusion. Example:
{
"assemblies": [{
"name": "MyApp",
"renamed": {
"types": {
"MyApp.PricingEngine": "a",
"MyApp.UserService": "b"
},
"methods": { ... },
"fields": { ... }
},
"excluded": [
{ "symbol": "MyApp.IPlugin", "reason": "public type in library" }
]
}]
} When to Use
- Applications with persistent storage — saved files, databases, or caches that contain serialized type/field names.
- Network protocols with versioned messages — both endpoints must agree on serialized names.
- Plugin systems — if plugins reference your types by obfuscated name, those names must be stable across updates.
Ready to protect your .NET code?