Frequently Asked Questions

Every other .NET obfuscator follows the same script: rewrite your assembly first, let you discover the breakage at runtime, then debug obfuscated stack traces until the application stops crashing. Demeanor reverses the order.

The demeanor audit command reads your code, classifies every construct known to break under obfuscation, and tells you:

• Which types need exclusions — and whether [Obfuscation(Exclude = true, ApplyToMembers = true)] in source is the right fix.
• Which patterns Demeanor will auto-detect and preserve without any configuration.
• Which code-level changes would produce a stronger obfuscation result — e.g., replacing a fragile string-based lookup with a type-token reference.

Only after that analysis does Demeanor touch a single byte of IL. The developer knows what will happen before it happens. No other commercial .NET obfuscator ships a pre-obfuscation audit. See the full workflow.

No. Demeanor is a standalone .NET obfuscator with a standalone audit command. Install the NuGet package, run demeanor audit MyApp.dll, read the report, apply the recommended fixes, then run demeanor MyApp.dll to obfuscate. No AI subscription, no MCP client, no LLM involvement. The audit output is plain English and designed to be read by a human.

Yes — optionally. Demeanor ships an opt-in MCP server so customers who already use Claude Code, Claude Desktop, Cursor, Windsurf, Continue.dev, or a VS Code MCP extension can run the same audit as a conversation. The assistant calls into Demeanor’s MCP server, relays the findings in prose, and — with your approval — applies the code changes Demeanor recommends.

The MCP server runs locally over stdio; no network, no phone-home. Nothing about Demeanor’s obfuscation pipeline depends on it; builds in CI run Demeanor unattended with no AI involvement. Requires your own Claude subscription — not included with Demeanor. See the CatalogService walkthrough for a complete 13-turn conversation over a repo sample, or the conversational workflow page for the full setup.

Four commonly-advertised features are absent by design: dead code injection, method body encryption, anti-dump, and code virtualization. Each is either trivially defeated by modern reverser tools, incompatible with NativeAOT, or both. Demeanor invests in permanent transformations that survive execution. Read the full rationale on each omission.

The Community tier is free indefinitely and includes real symbol renaming — not a crippled demo. Use it to evaluate Demeanor against a non-critical assembly before upgrading. There’s no time-limited trial because Community already is the evaluation.

The license key is signed with an expiry date. Before that date, Enterprise features are available. After that date, if you build without renewing, Demeanor falls back to Community tier — the build continues but only renaming is applied. Remove the license key to suppress the expiry warning.

Your license key continues working through the end of the paid term. Cancelling means we don’t bill you for the next year — it doesn’t revoke the key you already have.

Immediately. The Stripe checkout redirects to a page with your key. A copy is also emailed to the address on the order.

Stripe is the default. Payment by check is possible for teams that need it — email licensing@wiseowlsoftware.com to arrange. The license key is issued once payment clears.

No. Per-company means every developer machine, every CI agent, every build server in your organization is covered by one license. No seat counting, ever.

Two distribution SKUs of the same obfuscator binary. WiseOwl.Demeanor is a global tool (dotnet tool install -g) for interactive CLI use — demeanor audit, inspect, the optional /obfuscate Claude skill, and demeanor init to wire build-time obfuscation into a project. WiseOwl.Demeanor.MSBuild is the PackageReference demeanor init adds for you, invoked automatically on every Release build. It bundles the obfuscator binary itself, so CI agents need no tool install — dotnet restore plus dotnet build is enough. Both packages ship from the same pipeline, so there’s no version drift between them.

No. Community tier is free with no license key required. Install the NuGet package, enable obfuscation, and build. You get full symbol renaming.

The build fails with a clear error telling you the license has expired and linking to renewal. This prevents you from unknowingly shipping builds with reduced protection. To build without Enterprise features, remove the license key — the build then runs in Community tier (renaming only).

Never. License keys are self-validating using RSA-2048 signatures. No activation server, no internet connection required, no machine locking. Works fully offline and air-gapped.

Yes. Demeanor auto-detects common .NET framework patterns and freezes the symbols each framework resolves by name. For framework-by-framework specifics — including the exact annotations and exclusion patterns — see the Exclusions Guide.

Yes to all three. Demeanor v6 is built on .NET 10 and C# 14, and obfuscates assemblies targeting any version of .NET from Framework 1.0 through .NET 10. NativeAOT and trimming work because obfuscation runs as an MSBuild post-build step before AOT compilation — the obfuscated IL is what gets compiled to native code. Source generators produce C# source at compile time that the compiler turns into IL normally; Demeanor obfuscates the final assembly regardless of where the source came from.

No measurable runtime overhead in practice — renaming has zero cost, and string decryption adds nanoseconds per call. Assembly size grows 5–15% in practice, often offset by the savings from shorter names. Output is deterministic within the same version and configuration; use --report and --prior-report for incremental builds that preserve name mappings across versions.

Demeanor emits a JSON name-mapping report and supports incremental builds that preserve name mappings between versions (critical for serialization compatibility and customer support workflows). See Reports & Incremental for the full mechanics, and the incremental option reference for the CLI flags.

Demeanor auto-detects the common JSON, XML, WCF, and binary serialization patterns and automatically preserves the names they depend on. For most apps, serialization works with zero configuration.

If you have custom serialization, exclude the type with [Obfuscation(Exclude = true, ApplyToMembers = true)] or --exclude "Namespace.TypeName". Run demeanor audit first to see what was preserved. See the Exclusions Guide.

typeof(MyClass) works perfectly — the compiler resolves it at build time, so it tracks renames automatically. The danger is string-based reflection: Type.GetType("MyClass"), Activator.CreateInstance("MyClass"), and similar APIs that look up types or members by name. Exclude those types with [Obfuscation(Exclude = true)].

Pragmatically, no. Even with PDBs preserved via --debug, the symbols you would see in the debugger are the obfuscated names, so stepping through is impractical. If Demeanor's anti-debugging protection is enabled, the runtime actively prevents a debugger from attaching. For production diagnostics, use the JSON report (--report) to map obfuscated names back to originals.

Almost always a reflection or serialization pattern the audit didn't flag. Follow this order:

1. Run the audit first: demeanor audit MyApp.dll --include-deps --json > audit.json. If the audit shows Needs exclusion: 0 and Needs code change: 0, the issue is a pattern Demeanor didn't auto-detect.
2. Identify the culprit: The symptom is usually a runtime exception mentioning a mangled name, or a feature that silently stopped working (data binding, DI resolution, serialization). The type or member in the exception is your target.
3. Exclude it: Add [Obfuscation(Exclude = true, ApplyToMembers = true)] to the affected type in source. Or use --exclude "Namespace.Type" on the CLI for a quick test without rebuilding.
4. Re-obfuscate and verify. Once it works, move CLI excludes into source as [Obfuscation] attributes so they’re permanent.

If you’re stuck, send support the audit JSON, the runtime exception, and demeanor --version.

Your build pipeline is running obfuscation twice. The package's .targets file auto-skips test projects (anything where Microsoft.NET.Test.Sdk sets IsTestProject=true), so the common cause is two non-test projects in the chain — e.g., an intermediate library that the package processes once, then a shipping project that re-references the same DLL and processes it again. Set <Obfuscate>false</Obfuscate> on the intermediate, or scope the <PackageReference> to the leaf project that produces the shipping artifact.

Email support@wiseowlsoftware.com with the full terminal output (run with --verbose if you can), the exact command line you ran, demeanor --version, and the audit JSON from demeanor audit —json if available. Demeanor bugs are ship-stoppers on our side — you won’t wait long for a fix.

Demeanor supports the same [Obfuscation] attributes that Dotfuscator uses, so your existing code-level exclusions work without changes. Key differences: Demeanor installs as a NuGet package (no separate installer), uses per-company licensing (no per-seat costs), works offline (no activation server), and runs on Linux/macOS (not Windows-only). See the full comparison.

SmartAssembly uses a standalone GUI and per-machine licensing. Demeanor integrates directly into MSBuild via NuGet — no installer, no machine locking. If you used SmartAssembly’s [DoNotObfuscate] attribute, replace it with the standard [Obfuscation(Exclude = true)]. Your protection level is equivalent or stronger at a lower cost with unlimited seats. See the full comparison.