Nebula.NET

Tutorials by edition

Complete, end-to-end walkthroughs for the Free, Pro and Enterprise editions — pick your edition and follow the steps for your use case.

This page has a full walkthrough for each edition. Find your edition below and follow the steps for your scenario. Each tutorial is self-contained, so you only need to read the one that applies to you.

Edition	Who it’s for	Build integration
Free	Trying it out; small or open projects	No — tool only (CLI + GUI)
Pro	Commercial apps and libraries	Yes — MSBuild / CI
Enterprise	Larger teams; leak tracing; air-gapped	Yes — floating CI seats

To check which edition you’re running at any time:

nebula license

The GUI shows the same in its title bar and About box (FREE EDITION, PRO, or ENTERPRISE).

Free edition tutorial

The Free edition is the full tool — the CLI (nebula) and the desktop app — with three caps: up to 2 encrypted strings, up to 2 control-flow-protected methods, and no stack-trace de-obfuscation. Identifier renaming is unlimited. It is not build-integrated: obfuscating as part of dotnet build is a licensed feature, so in Free you run the tool by hand or as your own release step.

Scenario A — protect one assembly (GUI)

Install Nebula.NET from the download page and open the desktop app.
Click Open and select your built assembly (e.g. bin\Release\net8.0\MyApp.dll). Nothing is selected by default — that’s intentional so large inputs stay responsive.
In the tree, tick the members you want to protect (or the assembly node to select all).
Choose an output folder, enable Rename, Encrypt strings and Control flow, and click Protect.
Run your app from the output folder to confirm it behaves identically.

Scenario B — protect one assembly (CLI)

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
}

Run it:
```
nebula --config nebula.config.json
```
The protected copy is written to protected/. Run your tests against it.

Hitting the caps? If your app has more than 2 strings or methods worth protecting, Nebula protects the first 2 of each and tells you the rest were skipped because you’re on Free. That’s the signal to move to Pro, which removes all caps and adds anti-tamper, resource encryption and de-obfuscation.

What Free does not do

No dotnet build integration — the MSBuild task and NebulaObfuscate property require a license. In Free, obfuscate as a manual step or your own script.
No stack-trace de-obfuscation — you can’t map a renamed production stack trace back to original names.

Ready to remove the caps? See Getting a license.

Pro edition tutorial

Pro (the Licensed edition) removes every Free cap and unlocks anti-tamper/anti-debug, resource encryption, Authenticode signing, stack-trace de-obfuscation, and build integration. This is the edition for shipping a commercial product.

Step 1 — activate your license

After purchase you receive a key of the form LIC-….

nebula register --key LIC-XXXXXXXXXXXX
nebula license      # should now say: Licensed to <you> … / All features enabled.

Activation binds this machine to a seat and returns a signed lease, after which Nebula runs offline until the lease renews.

Step 2 — protect on every build (recommended)

Instead of running the tool by hand, let the build do it. Add the properties to the project that produces your shippable assembly:

<PropertyGroup>
  <NebulaObfuscate>true</NebulaObfuscate>
  <NebulaConfigFile>nebula.config.json</NebulaConfigFile>
  <NebulaPreservePublicApi>true</NebulaPreservePublicApi>
  <NebulaControlFlow>true</NebulaControlFlow>
  <NebulaEncryptStrings>true</NebulaEncryptStrings>
</PropertyGroup>

Now dotnet build -c Release produces a protected assembly automatically. See MSBuild & CI for the full property list.

Step 3 — protect only your official builds

A common requirement: developer builds stay unobfuscated, and only the build that produces your shippable packages is protected. Because NebulaObfuscate is just an MSBuild property, leave it unset everywhere and set it as an environment variable on the build agent only:

NebulaObfuscate=true
NEBULA_LICENSE=C:\keys\nebula-license.json   # a file PATH (or activate an online key once: nebula register --key LIC-…)

Developer machines (variable absent) build exactly as before; the build agent protects automatically — same source, no flags, no code changes. NEBULA_LICENSE is a file path, not a key; on a persistent agent you can instead activate an online key once with nebula register --key LIC-…. Full step-by-step (cmd / PowerShell / bash) and licensing options are in MSBuild & CI.

Step 4 — sign and de-obfuscate

Sign the protected output (Authenticode / strong name) so it ships trusted — set strongNameKeyFile in your config.
De-obfuscate a production stack trace back to original names:
```
nebula deobfuscate --map protected/MyApp.symbols.json --input crash.txt
```
See De-obfuscating stack traces.

Step 5 — multiple assemblies

If you rename public members that other assemblies of yours call, obfuscate them together so the references are rewritten consistently. Add all of them to inputs and enable crossAssemblyRename. See Multiple assemblies & renaming across them.

Enterprise edition tutorial

Enterprise includes everything in Pro plus leak tracing, an aggressive control-flow tier, and licensing built for larger teams. Enterprise keys activate exactly like Pro keys:

nebula register --key LIC-XXXXXXXXXXXX
nebula license      # shows: Enterprise, licensed to …

Scenario A — trace leaks with per-customer watermarking

Embed a hidden, unique id into each customer’s build so a leaked binary is traceable.

Give each customer a distinct id in their config:

{
  "schemaVersion": 1,
  "inputs": ["bin/Release/net8.0/MyApp.dll"],
  "outputDirectory": "protected",
  "watermark": "CUST-ACME-0042"
}

Build a separate output per customer and record which id went to whom.

Read the mark back from a suspected leak:

nebula watermark --input suspected.dll
# Watermark: CUST-ACME-0042

Scenario B — maximum protection for sensitive assemblies

Turn control-flow up to the Enterprise-only aggressive tier for your crown-jewel code:

{ "controlFlowObfuscation": true, "controlFlowIntensity": "aggressive" }

Under non-Enterprise licenses this automatically downgrades to standard intensity, so the same config is safe to share across a team.

Scenario C — CI build servers without burning developer seats

Enterprise includes floating CI-server licenses: protect on build agents without consuming a developer seat, plus on-prem / air-gapped activation for secure environments that can’t reach the internet. Set it up as in Pro step 3, using the CI/build-server arrangement from your Enterprise agreement. See Enterprise features.

Which edition do I need?

Free — evaluating, or a small/open project, and hand-running the tool is fine.
Pro — a commercial app or library; you want unlimited protection and automatic protection on every build.
Enterprise — you need leak tracing, the strongest control-flow, or floating/air-gapped licensing for a team.

Compare plans on the pricing page and see the full edition comparison.