Obfuscation is routinely oversold. It is a genuinely useful control, but it is not encryption and it does not make code unreadable. Being precise about what it does buys you is the difference between a sensible decision and a false sense of security.
The underlying problem
A .NET assembly is not machine code. It is IL plus an unusually rich metadata table describing every type, method, field and parameter — including their names. The runtime needs that metadata to execute your code, which means it must ship with your application, which means anyone holding the file has it too.
The practical consequence is that tools like ILSpy can reconstruct C# that is close to what you originally wrote, complete with your names and structure. How .NET decompilers read your code covers the mechanics.
Obfuscation attacks the readability of that reconstruction. Your ValidateLicense
method becomes a. The _trialExpiryDate field becomes
b. The IL still executes identically, but the free documentation the
metadata used to provide is gone.
What it meaningfully protects against
Casual inspection
This is the big one, and it covers most real-world snooping. A curious developer, a
competitor, or a customer poking at your binary opens it expecting readable code. Faced
with several hundred methods named a through zz and no
semantic hints, the overwhelming majority stop. Not because it is impossible, but
because it stopped being easy and nothing about it looked worth the effort.
Cheap intellectual property theft
If your product's value sits in a specific algorithm — a pricing model, a scheduling heuristic, a piece of domain logic refined over years — obfuscation stops someone lifting it by decompiling and pasting. They would have to understand the logic from unnamed control flow and reimplement it, which is a substantially larger undertaking than copying a readable method.
Automated and large-scale analysis
Tools that scan binaries for known patterns, and people grepping decompiled output for
terms like license, trial or activation, lose
their footholds. Attacks that rely on scale rather than individual effort become much
less productive.
Accidental disclosure
Internal class names leak more than teams expect: unreleased product names, customer names, the shape of your internal architecture, the identity of a partner integration. Renaming removes that whole category of unintentional information disclosure.
What it does not protect against
Being blunt about the limits, because these matter:
A determined, skilled attacker
Someone who genuinely wants to understand your code, and who has the skills and time, will succeed. They can attach a debugger, watch the code execute, rename symbols as they infer meaning, and rebuild understanding incrementally. Obfuscation raises the cost — it does not create an impossibility. Any vendor claiming otherwise is selling you something.
Anything visible at runtime
Your code has to actually run, which means everything it does is observable. Network traffic can be intercepted. Files it writes can be read. Its memory can be dumped mid-execution, at which point strings and decrypted values are sitting in plain view. Renaming metadata does nothing about any of this.
String literals
Name obfuscation renames identifiers — it does not touch the contents of strings. A hard-coded API key, connection string, or the exact text of your "Your trial has expired" message survives untouched, and that message is often the fastest route to your licensing code. Secrets do not belong in client binaries regardless of obfuscation.
Licence enforcement on the client
This is worth stating plainly: if your licence check runs on a machine the user controls, it can be defeated. Obfuscation makes finding the check harder and slower, but the check is still a branch in code the attacker owns. Server-side validation is the only approach that changes this, and obfuscation is a complement to it rather than a substitute.
Framework and library calls
Calls into the BCL and third-party packages keep their real names, because they have
to resolve against assemblies you did not obfuscate. A reader can still see that you
called HttpClient.PostAsync or File.WriteAllText, which
gives them meaningful signposts through otherwise anonymous code.
A sensible way to think about it
Obfuscation is a lock on a door, not a vault. It stops opportunists, deters the merely curious, and makes casual copying unrewarding. It will not stop a professional who has decided your software is worth the effort.
That is still a good trade. The overwhelming majority of people who ever open your assembly fall into the first group, and the cost of protecting against them is one step in your build. Where obfuscation goes wrong is when it becomes the reason a team puts a secret in a client binary, or trusts a client-side licence check it should not have trusted. Use it as one layer, keep secrets on the server, and validate anything that matters somewhere the user cannot reach.