The situation
Selling a library is a peculiar situation: your customers need your public API to work exactly as documented, but the implementation behind that API is the thing you are actually selling.
Renaming the public surface of a library would break every consumer at compile time, or with a MissingMethodException at runtime. So the rule here is not negotiable — the contract stays.
What you are exposed to
- A licensee decompiling your library to reimplement it and stop paying.
- Your algorithms being copied into a competing component.
- Bypassing whatever licensing your component enforces.
What obfuscation does here
- Public renaming is ignored for libraries automatically — the option is decided by inspecting the assembly, so there is no way to break your API by ticking the wrong box.
- Everything below the surface is still renamed: private and internal types, fields, private methods. In a typical library that is the large majority of the code and all of the interesting parts.
- Your published API reference already documents the public surface, so preserving it costs you nothing you were not already giving away.
What it does not do
Worth being clear about the limits before you rely on this.
- The public API is fully readable by design. If your value is a thin public wrapper with little behind it, obfuscation has little to work with.
- A determined licensee can still trace execution through the renamed internals with a debugger.
- Strong-named assemblies must be re-signed after obfuscation, as the rewrite invalidates the signature.
Suggested setup
| Plan | Free for a single library under 1 MB; Pro to batch a multi-assembly SDK in one pass. |
| Public names | Not applicable — it is ignored for libraries. You cannot accidentally break your consumers. |
| Workflow | For maximum protection, split the product: a small MyLib.Abstractions holding the public contract, and MyLib.Core with implementation types marked internal and fully obfuscated. |
Test this before you ship
Obfuscation only breaks things that resolve a name at runtime, so a short checklist catches nearly everything:
- A sample consumer project still compiles against the obfuscated build.
- Your own integration tests pass against the obfuscated assembly.
- Any reflection your library performs on its own types still resolves.
- The NuGet package installs and the documented entry points work.
If something does break, obfuscation and reflection lists each cause with its fix.