DEV Community: dotnet

Merge and Combine PowerPoint PPT/PPTX Presentations in C#

Muhammad Mustafa — Thu, 17 Sep 2026 09:45:36 +0000

Tired of manually stitching together dozens of PowerPoint decks? In C# you can automate the whole process and output a single, polished presentation in seconds. This guide walks you through calling the GroupDocs Cloud REST API from a .NET app, covering setup, authentication, and the exact request payload needed to merge whole files or selected slides.

You’ll see step‑by‑step code snippets that download, combine, and save PPT or PPTX files, plus tips for handling slide ordering and preserving formatting. Whether you need to merge full presentations or cherry‑pick specific slides, the example projects give you a reusable pattern for any automation pipeline.

Integrate this solution into your CI/CD workflow and keep your decks up to date automatically.

Read the full guide → https://blog.groupdocs.cloud/merger/merge-powerpoint-pptpptx-files-online-using-rest-api-in-csharp/?utm_source=devto&utm_medium=social&utm_campaign=blogcaster

Hardcoded strings are leaking your .NET app’s secrets

Zero Heartbeat — Thu, 17 Sep 2026 09:20:55 +0000

Open any .NET binary in a decompiler and one of the first things you'll see is a clean list of every string literal in the app. For most applications, that list is a roadmap to how everything works — and sometimes to things that were never meant to be seen.

Why plain-text strings are a problem

String literals compile straight into your assembly's metadata, completely readable. From that list an attacker can immediately learn:

API endpoints and URLs your app talks to.
Error and log messages that reveal internal logic and control flow.
Registry keys, file paths, and feature flags.
Embedded secrets that shouldn't be there at all — API keys, tokens, connection strings.

Even without decompiling a single method, searching the string table often tells an attacker exactly where to look next — for example, jumping straight to your licensing code by searching for "license" or "trial".

What string encryption does

String encryption replaces those readable literals with encrypted data that's decrypted at runtime:

Each literal is encrypted at build time, ideally with a fresh per-build key.
The plain text no longer appears in the binary's string table.
At runtime, an inlined routine decrypts the value on demand.

Done well, the decryptor is unbranded (its name doesn't advertise which tool produced it) and inlined, so it's not a single obvious function an attacker can hook to dump every string at once.

What it doesn't do

String encryption raises the bar; it isn't a vault. A determined attacker can still run the app and recover decrypted strings from memory. So the rule stands: don't ship real secrets in the client at all. Keep private keys and master credentials server-side. String encryption protects your code's strings — endpoints, messages, logic markers — not secrets that should never leave your server.

Where it fits

String encryption is one layer of a hardened build, alongside:

Identifier renaming — removes readable names.
Control-flow flattening — hides logic structure.
Anti-tamper / anti-debug — stops live patching and stepping.

Nebula.NET encrypts string literals with a per-build key and an unbranded, inlined decryptor, as part of the same pass that renames and flattens your code — across .NET Framework 4.8 and .NET 6–10. See it on your own binary with the free edition: decompile before and after, and watch the string table go dark.

Adding licensing to your .NET app? Protect the license check too

Zero Heartbeat — Thu, 17 Sep 2026 09:20:40 +0000

Adding licensing to a .NET application is straightforward. Making that licensing hard to bypass is the part most developers underestimate. This post covers both.

Common .NET licensing approaches

Offline signed license files/keys. You sign a license (e.g. with RSA) and the app verifies it against an embedded public key. Simple, works offline, but can't be revoked once issued.
Online activation. The app contacts a server to activate a key, binding it to a machine and enforcing a seat limit. Supports revocation and subscriptions; needs a backend.
Node-locking. Tie a license to a hardware/machine fingerprint so a key can't be freely shared.
Feature gating. Unlock "pro" features based on the license tier.

All of these are good patterns. But they share one weakness.

The weak point: the check itself

Every one of these approaches eventually runs code like:

if (license.IsValid)
    EnableProFeatures();

In an unprotected .NET assembly, that check is trivial to defeat. An attacker opens your binary in dnSpy, finds the method, edits the IL so IsValid always returns true (or removes the check entirely), and saves a patched build. Your carefully signed, node-locked, online-activated license — bypassed in minutes, because the verification code was readable and editable.

What actually makes licensing hold

Obfuscation — rename and flatten the license logic so it's hard to locate and understand in a decompiler.
String encryption — hide the URLs, keys, and messages that make the licensing code easy to search for.
Anti-tamper — detect that the assembly was modified after signing, so a patched binary refuses to run.
Anti-debug — detect an attached debugger like dnSpy so attackers can't step through and edit the check live.

In other words: your licensing design provides the policy; obfuscation and hardening protect its enforcement. Skip the second half and the first is decorative.

Practical checklist

Choose a licensing model (offline signed, or online activation with revocation and seats).
Keep any real secrets — signing keys, server credentials — off the client.
Obfuscate and harden the Release build, including the licensing code, with anti-tamper enabled.
Verify the protected build still activates and runs identically.
Sign the binary so tampering is detectable.

Nebula.NET handles step 3–5 — obfuscation, string encryption, anti-tamper/anti-debug, and Authenticode signing — for .NET Framework 4.8 and .NET 6–10. See how it works, and note how the same techniques that hide your algorithms also protect your license enforcement.

Start free from the download page.

Can someone decompile my .NET app? Stopping dnSpy and ILSpy

Zero Heartbeat — Thu, 17 Sep 2026 09:15:59 +0000

If you've ever wondered whether someone can decompile your .NET app: they can, easily, with free tools. Here's how it works and what to do about it.

How decompilation works

.NET compiles to IL, which preserves names and structure. Decompilers reverse that:

ILSpy / dotPeek — open a .dll/.exe and show reconstructed C#.
dnSpy — goes further: it decompiles and lets an attacker set breakpoints, edit IL, and patch your assembly live. It's a favorite for defeating naive license checks — find the if (isLicensed), flip it, save.

Out of the box, none of this requires skill. That's the problem obfuscation and hardening solve.

Making your assembly hard to read

Identifier renaming strips the readable names dnSpy/ILSpy display.
Control-flow flattening turns clean methods into dispatcher state machines, so the decompiled output no longer resembles your logic.
String encryption removes the literal strings that make code easy to navigate and search.

Making your assembly hard to debug and patch

Reading is only half of it — dnSpy's real power is interactive tampering. To counter that:

Anti-debug detects when a debugger like dnSpy is attached and lets you react (exit, throw, or a custom response).
Anti-tamper detects when your assembly has been modified after signing, so a patched binary can refuse to run.

Together these stop the "attach dnSpy, patch the check, save" attack that trivially defeats unprotected apps.

A word on license checks specifically

If your app has any licensing or "pro feature" gating, the check itself is the target. An unprotected if (license.IsValid) is one dnSpy edit away from being bypassed. Obfuscating the check and adding anti-tamper is what makes it hold up. (More on this in protecting .NET license checks.)

Putting it together

The practical answer to "can someone decompile my .NET app?" is: yes by default, but you can make it far more trouble than it's worth. Obfuscate and harden your Release build, verify it still runs identically, sign it, and ship.

Nebula.NET provides renaming, control-flow flattening, string encryption, and anti-tamper/anti-debug across .NET Framework 4.8 and .NET 6–10 — try the free edition and open the result in ILSpy to see the difference yourself. Weighing your options first? Compare the best .NET obfuscators of 2026.

How to obfuscate a WPF app without breaking XAML data binding

Zero Heartbeat — Thu, 17 Sep 2026 09:15:40 +0000

WPF apps are a common obfuscation target — they ship to end users' machines, so the IL is right there to decompile. The one thing to get right is that XAML binds to your view-models by name at runtime, so those names have to survive. Here's the whole process.

Why WPF needs a little care

When you write {Binding CustomerName} or Command="{Binding SaveCommand}", WPF resolves CustomerName and SaveCommand by name at runtime via reflection. If obfuscation renames those properties to a and b, the binding silently fails — you get a blank field or a dead button, with a binding error in the debug output.

Everything else — your business logic, algorithms, services — has no such constraint and can be fully renamed, flattened and encrypted.

Step 1 — preserve what XAML binds to

The simplest, safest setting for a WPF app is preserve public API, because bound view-model members are usually public:

{
  "inputs": ["bin/Release/net8.0/MyApp.dll"],
  "outputDirectory": "protected",
  "preservePublicApi": true,
  "controlFlowObfuscation": true,
  "encryptStrings": true
}

If a bound member isn't public, exclude the view-model explicitly instead of leaving names exposed everywhere:

{ "exclude": ["MyApp.ViewModels.MainViewModel"] }

Nebula also auto-detects most reflection and serialization usage, so converters and types referenced with {x:Type} are generally preserved for you. See Keeping your app working.

Step 2 — obfuscate the internals hard

Your public view-model surface stays named, but the code behind it is where the value is — so lean on control flow and string encryption there. With preservePublicApi on, private and internal members are still renamed, and control-flow flattening applies everywhere.

Step 3 — run it and click through

This is the real test. Obfuscate, launch the protected build, and exercise the screens — especially anything data-bound. If a field is blank or a command is dead, check the debug output for a binding error naming the member, then add that member (or its view-model) to exclude.

Step 4 — sign it for distribution

Desktop users will hit a "Windows protected your PC / Unknown publisher" prompt on an unsigned installer. Sign the protected output with your Authenticode certificate (Nebula can apply it as part of the run) or distribute through the Microsoft Store. See Protecting different project types.

Summary

Keep preservePublicApi on so bound members survive.
Exclude any non-public view-model that XAML binds to.
Let control-flow + string encryption protect the internals.
Run the app and click through the bound screens as your acceptance test.
Sign the result before you ship it.

Ready to try it? Download Nebula.NET free and protect your first WPF build in a few minutes.

Obfuscate only on your build server (keep developer builds clean)

Zero Heartbeat — Thu, 17 Sep 2026 09:15:28 +0000

Obfuscation is great for what you ship and a nuisance for what you debug. The best-practice setup is: developers build normally (unobfuscated, debuggable), and only the build server that produces your official packages applies protection — same source, same dotnet build, no code changes. Here's how to set that up.

The idea

Nebula obfuscates your compiled output, not your source, and it's driven by configuration — so whether protection runs comes down to a single switch that exists only on the build agent. Developer machines don't have that switch, so their builds are untouched.

Option A — the MSBuild task, gated by an environment variable

Nebula's build target only runs when the NebulaObfuscate property is true, and MSBuild reads that from the environment. On the build agent, set:

NebulaObfuscate=true
NEBULA_LICENSE=<your build-server license key>

Every build on that agent is protected after compile; developer machines (variable absent) build exactly as before. Nothing changes in your .csproj behaviour on a dev box.

Option B — zero package reference (fully dependency-free)

If you don't want any Nebula reference in your projects at all, invoke the CLI from a repo-level Directory.Build.targets, gated by your own variable:

<Project>
  <Target Name="NebulaObfuscate" AfterTargets="Build" Condition="'$(NEBULA_OBFUSCATE)' == '1'">
    <Exec Command="nebula --config &quot;$(MSBuildProjectDirectory)/nebula.config.json&quot; --output &quot;$(TargetDir)obf&quot;" />
  </Target>
</Project>

Set NEBULA_OBFUSCATE=1 (and NEBULA_LICENSE=…) on the agent and install the CLI. Developer boxes skip the step entirely.

Setting the variable on the agent

Set it once, as the account your builds run under:

# Windows agent, machine-wide (run as Administrator):
[Environment]::SetEnvironmentVariable('NEBULA_OBFUSCATE', '1', 'Machine')
[Environment]::SetEnvironmentVariable('NEBULA_LICENSE', 'LIC-XXXX-XXXX-XXXX', 'Machine')

# Linux/macOS agent (service environment or profile):
export NEBULA_OBFUSCATE=1
export NEBULA_LICENSE=LIC-XXXX-XXXX-XXXX

Most CI systems also let you define these as pipeline/agent variables in their UI — set them on the agent, never in the repo. Full cmd/PowerShell/bash steps are in MSBuild & CI.

You only license the build machine

Because protection happens on the build server, only the build machine(s) need a license — not every developer. Activate on the agent and you're done.

Verify

Build on a dev box: output is normal and debuggable. Build on the agent: the output is renamed, flattened and encrypted, and your pipeline archives the protected artifact. Same commit, two very different binaries — exactly what you want.

Download Nebula.NET free to try it, and see the full build guide in the docs.

How to obfuscate a NuGet package before you publish it

Zero Heartbeat — Thu, 17 Sep 2026 09:15:18 +0000

If you distribute a commercial .NET library on NuGet, anyone who installs it can open your DLL in a decompiler and read your implementation. You can protect it — the trick is protecting the internals while keeping the public API your consumers call intact. Nebula handles the whole package for you.

The one rule: keep your public API

Consumers reference your library by its public types and members. If obfuscation renamed those, their code wouldn't compile against your package. So for a library the golden setting is preserve public API — public/protected names stay, everything internal is renamed, flattened and encrypted.

Step 1 — point Nebula at the package

You don't have to unpack anything. Give Nebula the .nupkg directly and it obfuscates the assemblies inside and repacks a protected package:

{
  "inputs": ["bin/Release/MyLib.1.2.3.nupkg"],
  "outputDirectory": "protected",
  "preservePublicApi": true,
  "controlFlowObfuscation": true,
  "encryptStrings": true
}

nebula --config nebula.config.json

The protected MyLib.1.2.3.nupkg lands in protected/, ready to push.

Step 2 — if you ship multiple libraries

Products often span several packages that call each other's public members. If you want to rename across them, obfuscate them together so the cross-references are rewritten consistently — otherwise renaming a public member in one breaks the others. Add all the assemblies to inputs and enable crossAssemblyRename. See Multiple assemblies.

Step 3 — mind reflection and serialization

Auto-detect preserves types and members referenced by reflection or carrying serialization attributes (System.Text.Json, Newtonsoft, DataContract, XML). If your library exposes DTOs that consumers serialize, keep those attributes (or exclude the DTOs) so the wire format doesn't change. See Keeping your app working.

Step 4 — sign and verify

Strong-name signing must be re-applied after obfuscation — set strongNameKeyFile and Nebula signs the protected output. Then install the protected package into a throwaway consumer project and run your tests against it: the public API compiles and behaves exactly as before, but the internals are now hard to read.

Automate it in your release pipeline

Wire this into CI so every published package is protected, without touching your source. See MSBuild & CI.

Download Nebula.NET free and protect your next NuGet release.

A .NET Reactor alternative in 2026

Zero Heartbeat — Thu, 17 Sep 2026 09:15:04 +0000

.NET Reactor, by Eziriz, is one of the most popular commercial .NET obfuscators — and for good reason. It's affordable, it's been around a long time, and it packs a lot into one tool. If you're comparing it with Nebula.NET, here's a straight, fair breakdown.

Where .NET Reactor is strong

Price. A one-time perpetual license at a genuinely accessible price point — a big part of its popularity with indies and small studios.
NecroBit. Its headline feature compiles IL to native code, so those methods can't be decompiled back to C# by ordinary tools. That's real protection for sensitive logic.
Built-in licensing. A full license-key system — trials, expiry, hardware locking — bundled in. If you need that in one box, it's convenient.
The usual suite — string/resource encryption, anti-tamper, anti-debug, control-flow obfuscation.

It's a lot of value. We're not here to pretend otherwise.

Where Nebula.NET differs

Nebula approaches the same problem — "make my shipped code not worth reverse-engineering" — with some different bets:

Code virtualization instead of native compilation. Nebula's Enterprise virtualization turns a method's IL into a custom bytecode run by an embedded VM. Native code (like NecroBit's output) has mature disassemblers and decompilers; a custom VM has none until an attacker builds one — for your specific build. Both remove readable IL; the VM route raises the reverse-engineering cost differently.
Verified de4dot resistance. Nebula's control flow and per-call-site string encryption are engineered — and tested against the real de4dot — to survive automated deobfuscation. We show the result rather than asserting it.
A genuine free edition + a free decompiler to check. Try Nebula on your own assembly for free, then open the output in Glass.NET and see exactly what a would-be attacker would. Being able to verify protection is underrated.
Modern targets. Dedicated Blazor WebAssembly protection — the most exposed .NET target — plus .NET Framework 4.8 through .NET 6–10.
Workflow. CLI, desktop GUI, and MSBuild/CI, with stack-trace de-obfuscation so your production crash reports stay readable.

Where .NET Reactor may still win for you

If a built-in licensing system is a hard requirement and you want it bundled with the obfuscator, .NET Reactor delivers that in one purchase — Nebula focuses on code protection and pairs with online activation rather than shipping a full key generator. And if native compilation specifically is what you want, NecroBit is its purpose-built feature.

How to decide

Don't decide on a feature list — decide on your binary. Protect a representative assembly with each, run your test suite against the output to confirm it still behaves identically, then try to read the protected build in a decompiler. Download Nebula.NET free and put it head-to-head; the one whose output you can't make sense of wins.

How to obfuscate a .NET assembly (step-by-step, 2026)

Zero Heartbeat — Thu, 17 Sep 2026 09:14:24 +0000

.NET assemblies are easy to decompile. Tools like ILSpy, dnSpy and dotPeek can turn your compiled DLL back into near-original C# in seconds, exposing your algorithms, license checks, API keys and business logic. Obfuscation raises the cost of that by rewriting the compiled IL so it's hard to read — without changing how your program runs.

This guide walks through obfuscating a .NET assembly the right way, using Nebula.NET.

Before you start

Obfuscate your release build, not debug, and keep a copy of the original. Decide what must keep its public names — for libraries and plugins, your public API and any members hit by reflection or serialization should be preserved.

Step 1 — Install the tool

Download the Windows installer from the download page and run it. It installs both a command-line tool (nebula) and a desktop GUI. No .NET runtime is required on the machine running it.

Step 2 — Create a configuration

Nebula is driven by a small JSON file. Create nebula.config.json next to your build output:

{
  "schemaVersion": 1,
  "inputs": ["bin/Release/net8.0/MyApp.dll"],
  "outputDirectory": "protected",
  "preservePublicApi": true,
  "encryptStrings": true,
  "controlFlowObfuscation": true
}

preservePublicApi keeps public types/members named — essential for libraries.
encryptStrings encrypts literal strings so keys and messages don't sit in plain text.
controlFlowObfuscation rewrites your methods so the original logic is obscured.

Step 3 — Run it

nebula --config nebula.config.json

You'll see a summary of what was renamed, flattened and encrypted, and a protected copy of your assembly appears in protected/.

Step 4 — Verify it still works

This is the step most people skip — and it's the most important. Obfuscation must never change behavior. Run your app or your full test suite against the protected build and confirm everything behaves exactly as before. Nebula validates output automatically and is tested to preserve runtime behavior across .NET Framework 4.8 and .NET 6–10, but you should always run your own tests too.

What each transform does

Identifier renaming replaces meaningful type/method/field names with meaningless ones, while preserving anything that must keep its name.
Control-flow flattening rewrites methods into dispatcher-driven state machines, so a decompiler can't show your original structure.
String encryption encrypts literals with a per-build key, decrypted at runtime by an inlined routine.
Anti-tamper and anti-debug detect a modified assembly or an attached debugger and react as you configure.

Watch out for reflection and serialization

If your code looks up types or members by string name (reflection, dependency injection, JSON/XML serialization, some ORMs), renaming those members will break it. Preserve them with preservePublicApi and Nebula's include/exclude rules. When something misbehaves after obfuscation, this is almost always the cause — narrow down which transform is involved and exclude the affected members.

Automate it in CI

Once it works locally, protect on every build. Nebula returns meaningful exit codes and takes a --json summary, so it drops into any pipeline:

nebula --config nebula.config.json --json nebula-summary.json

See MSBuild & CI for details.

Summary

To obfuscate a .NET assembly: install a tool, write a config that preserves your public API, enable the transforms you need, run it, and — crucially — verify your app still runs identically. Start with the free edition; it's enough to protect small projects and evaluate the full suite.

An Eazfuscator.NET alternative in 2026

Zero Heartbeat — Thu, 17 Sep 2026 09:13:37 +0000

Eazfuscator.NET, by Gapotchenko, is a well-regarded .NET obfuscator with a reputation for a clean developer experience and responsive support. If it's on your shortlist alongside Nebula.NET, here's an honest side-by-side.

Where Eazfuscator.NET is strong

MSBuild-native by design. It hooks into the build so protection happens automatically on every compile — very little ceremony. That "set it and forget it" integration is a genuine strength.
Code virtualization. It offers virtualization of sensitive methods, not just renaming and flattening.
Polished and supported. A mature tool with stack-trace decoding and a good reputation for support.

It's a solid, respected product. Our aim here is a fair comparison, not a takedown.

Where Nebula.NET differs

A genuine free edition. Eazfuscator is paid-only (with a trial). Nebula's free edition does real work — renaming with public-API preservation, plus string encryption and control flow — so you can protect a small project or fully evaluate before spending anything.
Transparent per-seat pricing on the pricing page, with a perpetual option — no subscription-only lock-in.
A desktop GUI and CLI and MSBuild. If you like Eazfuscator's build integration, Nebula matches it — and adds a GUI for one-off jobs, exploring settings, and onboarding teammates who don't live in the build scripts.
Verified de4dot resistance. Nebula's control flow and per-call-site string encryption are tested against the real de4dot to survive automated deobfuscation — with the result shown, not just claimed.
Modern targets. Dedicated Blazor WebAssembly protection for the most-exposed .NET deployment, plus .NET Framework 4.8 through .NET 6–10.
Verify the output. Protect a build, then open it in the free Glass.NET decompiler and see exactly what's exposed — a check most vendors don't hand you.

Both tools offer code virtualization and stack-trace de-obfuscation, so on those the decision comes down to workflow, pricing model, and the ability to try before you buy.

How to choose

If deep, zero-config MSBuild integration and an established support relationship are your top priorities, Eazfuscator.NET earns its reputation. If you want to start free, see transparent pricing, get a GUI alongside the build integration, and protect modern targets like Blazor WASM — evaluate Nebula.NET directly.

As always, decide on your own binary: protect a representative assembly with each, run your tests against the output, and try to read it back in a decompiler. Download Nebula.NET free and compare.

A Dotfuscator alternative for .NET in 2026

Zero Heartbeat — Thu, 17 Sep 2026 09:13:15 +0000

Dotfuscator, from PreEmptive, is the grandparent of .NET obfuscators — it's been protecting managed code since the early .NET Framework days and has a deep enterprise track record. If you're evaluating it in 2026, here's a fair look at where it fits and where a more modern, transparently-priced tool like Nebula.NET might serve you better.

Where Dotfuscator is strong

Credit where it's due. Dotfuscator has years of enterprise deployment behind it, PreEmptive's runtime tamper/shelf-life checks and application analytics, and the convenience of a Community Edition bundled right inside Visual Studio. For large organizations already standardized on it, that maturity and support relationship are real.

Where teams run into friction

Quote-based pricing. Dotfuscator Professional isn't publicly priced — you request a quote, and it's positioned for enterprise budgets. For an indie, a startup, or a small ISV, that alone is often a non-starter.
The free edition is very limited. The Visual Studio Community Edition does basic renaming only — not the control flow, string encryption, or tamper protection that actually resist reverse engineering. So "free" here doesn't mean "protected."
Enterprise-shaped workflow. The tooling and licensing are built around large-team procurement, which can feel heavy if you just want to protect a build and ship.

How Nebula.NET compares

Nebula.NET is a modern, actively-developed suite built for the same job with a different posture:

A genuine free edition — real renaming, plus a taste of string encryption and control flow — not just a rename-only stub. Try it on your own assembly before you pay.
Transparent per-seat pricing — see it on the pricing page; no quote process.
The full protection ladder — identifier renaming (public-API preserving), control-flow flattening, string encryption, anti-tamper/anti-debug, resource and metadata hardening, and Authenticode signing, via CLI, desktop GUI, and MSBuild/CI.
Modern protections Dotfuscator's lineage predates — Enterprise code virtualization (methods compiled to a custom bytecode VM, so there's no IL to read), dedicated Blazor WebAssembly protection, and control flow specifically engineered to survive automated deobfuscators like de4dot.
Verify it yourself — protect a build, then open it in our free Glass.NET decompiler and see exactly what's exposed. Most vendors don't hand you the tool to check their own output.

Which should you choose?

If you're a large enterprise already invested in PreEmptive's ecosystem and analytics, Dotfuscator's maturity may justify the price. If you want to see the price, start free, and get modern protections like virtualization and Blazor support without an enterprise procurement cycle, Nebula.NET is worth a direct comparison.

The honest test is your own binary: protect it with each, then try to read it back in a decompiler. Download Nebula.NET free and run that test — it takes a few minutes, and it's the only comparison that matters.

Does obfuscation actually protect .NET code?

Zero Heartbeat — Thu, 17 Sep 2026 09:13:02 +0000

Short answer: yes, but with realistic expectations. Obfuscation meaningfully raises the cost and effort of reverse engineering your .NET code — it does not make it mathematically impossible. Understanding that distinction helps you use it well.

Why .NET code is so exposed

C# and other .NET languages compile to IL (intermediate language), a high-level bytecode that retains type names, method names, and structure. Free decompilers (ILSpy, dnSpy, dotPeek) reconstruct near-original source from a shipped DLL almost instantly. Without protection, anyone with your binary effectively has your source.

What obfuscation actually does

Obfuscation rewrites that IL so it's hard for a human (and a decompiler) to follow, while producing the same runtime behavior:

Identifier renaming strips the meaningful names decompilers rely on.
Control-flow flattening rewrites methods into dispatcher-driven state machines, hiding the original logic and structure.
String encryption removes readable literals — API endpoints, keys, messages — from the binary.
Anti-tamper and anti-debug detect a modified assembly or an attached debugger and let you respond.

The result: a determined attacker can still analyze your code, but it takes far more time, skill, and motivation — often enough to make it not worth their while.

What obfuscation can't do

Be honest with yourself about the limits:

It's not encryption. The code must ultimately run, so a skilled reverse engineer with enough time can still make progress.
It won't hide secrets you shouldn't ship. Don't embed private keys or master credentials in a client and assume obfuscation makes them safe — it doesn't. Keep true secrets server-side.
It doesn't stop copying of the binary. That's what licensing and activation are for.

Build layered protection instead

Obfuscation is one layer. Combine it with:

Obfuscation + hardening — renaming, control flow, string encryption, anti-tamper. (Choosing a tool? See our 2026 obfuscator comparison.)
Licensing and activation — node-locked, seat-enforced keys so a copied binary can't just be reused, and can be revoked.
Keep real secrets off the client — put anything that must stay private behind your server/API.
Code signing — so users can verify the binary came from you and wasn't modified.

Nebula.NET does the first and fourth, and pairs naturally with online licensing for the second — see how it works.

Realistic expectations

Think of obfuscation like a good lock: it won't stop every determined attacker forever, but it stops the casual and opportunistic ones, and it buys time against the serious ones. For most commercial .NET software, that shift in cost-to-attack is exactly the point — and it's well worth doing.

Ready to try it? Grab the free edition and protect an assembly in a few minutes.