A successful build only proves the obfuscator did not crash. It says nothing about whether the output is actually hardened. A keep rule that is one glob too wide, a feature that is not enabled on your edition, a config key you misspelled, or an input that was already processed will all produce a clean exit code and an assembly that is wide open. This is the silent fallback to no protection, and because nothing fails, it survives all the way to production.

Nebula.NET 2.2.0 closes that gap with two things that belong in every pipeline: a protection report emitted on every build, and nebula verify, a gate that fails the build when the transforms you asked for did not land.

The protection report

Every Nebula.NET build can emit a machine-readable summary of what it actually did. It is plain JSON with a versioned, stable schema, so you can parse it, archive it, and diff it across builds without worrying that the next release will reshuffle the fields.

Turn it on in your nebula.json:

{
  "obfuscate": true,
  "rename": true,
  "stringEncryption": true,
  "controlFlow": true,
  "report": {
    "enabled": true,
    "path": "artifacts/nebula-report.json"
  }
}

Or ask for it on the command line, which overrides the config and is handy in CI:

nebula protect MyApp.dll --report artifacts/nebula-report.json

Here is a real excerpt from a report for a Pro build:

{
  "schemaVersion": "1.0",
  "tool": { "name": "Nebula.NET", "version": "2.2.0", "edition": "Pro" },
  "input":  { "assembly": "MyApp.dll", "mvid": "2f1c8e0a-7b44-4d2e-9a6b-1e5d0c3f9a21" },
  "output": { "assembly": "MyApp.dll", "mvid": "b9d4e7c2-0a31-4f88-ae10-6c2f7b4d1e90" },
  "summary": {
    "typesTotal": 412,
    "methodsTotal": 3187,
    "renamedMembers": 3904,
    "renameRatio": 0.97,
    "residualPublicTypes": 12
  },
  "transforms": [
    { "name": "rename",           "requested": true, "applied": true, "typesAffected": 400, "methodsAffected": 3090 },
    { "name": "stringEncryption", "requested": true, "applied": true, "stringsEncrypted": 1884 },
    { "name": "controlFlow",      "requested": true, "applied": true, "methodsAffected": 2731 },
    { "name": "virtualization",   "requested": false, "applied": false }
  ],
  "residualPublicSurface": [
    "MyApp.PluginContract",
    "MyApp.PluginContract.IPlugin",
    "MyApp.Api.HealthController"
  ]
}

How to read it

A handful of fields tell you almost everything:

• transforms[].requested vs applied — the single most important comparison. If you asked for controlFlow and applied is false, your flattening did not happen. This is the field nebula verify keys on.
• summary.renameRatio — the fraction of eligible members that were renamed. A healthy library build sits in the high 0.9s. If it drops to, say, 0.4, a keep rule is excluding far more than you intended.
• summary.residualPublicTypes / residualPublicSurface — the public API you deliberately left legible, because callers bind to it. This should be a short, familiar list: your plugin contracts, your public entry points. If a type you expected to be hidden shows up here, it is reachable through your public surface and was skipped on purpose — a signal to tighten your keep rules.
• output.mvid — the Module Version ID of the produced assembly. Because it changes on every real rewrite, it is a cheap tamper and freshness check: if input.mvid equals output.mvid, nothing was rewritten at all.

On Pro and Enterprise, each transform also carries a per-type breakdown (which types were flattened, which methods were virtualized), so you can confirm your most sensitive methods specifically were covered rather than trusting an aggregate count. All editions emit the summary and the top-level transform results.

nebula verify — the CI gate

Reading the report by eye is fine once. In a pipeline you want a machine to do it on every build and stop the line when something is wrong. That is nebula verify.

Point it at the output assembly (or the report directly). It compares requested transforms against applied ones and exits non-zero if any requested transform did not land:

nebula verify MyApp.dll --report artifacts/nebula-report.json

The exit codes are stable and scriptable:

Exit code 3 is dedicated to the one failure you actually care about — "you asked for protection and did not get it" — so you can distinguish a real protection regression from a broken invocation.

You can also assert specific transforms regardless of what the config requested, which is useful when a build profile must include a given layer:

nebula verify MyApp.dll --require rename,stringEncryption,controlFlow

Wiring it into a pipeline

In a shell-based CI step, the gate is one line — set -e and a non-zero exit do the rest:

# GitHub Actions
- name: Harden and verify
  run: |
    nebula protect src/bin/Release/net8.0/MyApp.dll \
      --report artifacts/nebula-report.json
    nebula verify src/bin/Release/net8.0/MyApp.dll \
      --report artifacts/nebula-report.json

- name: Archive protection report
  uses: actions/upload-artifact@v4
  with:
    name: nebula-report
    path: artifacts/nebula-report.json

Prefer MSBuild? Make the gate part of the build graph so a skipped transform fails dotnet build:

<Target Name="VerifyProtection" AfterTargets="Nebula">
  <Exec Command="nebula verify &quot;$(TargetPath)&quot; --report &quot;$(OutDir)nebula-report.json&quot;" />
</Target>

Because Exec fails the target on a non-zero exit code, an exit 3 from verify stops the build with the rest of your pipeline.

Archive it, then diff it

The report earns its keep over time. Upload nebula-report.json as a build artifact on every run and you get a protection history you can diff:

# Fail if this build renamed far fewer members than the last green build.
prev=$(jq '.summary.renameRatio' baseline-report.json)
curr=$(jq '.summary.renameRatio' artifacts/nebula-report.json)
awk -v p="$prev" -v c="$curr" 'BEGIN { exit !(c >= p - 0.05) }'

A build-to-build diff catches the slow regressions verify alone cannot: a keep rule someone widened last month, a new public type that quietly enlarged your residual surface, a transform that still applies but now covers 60% of methods instead of 95%. The transform either landed or it didn't is a yes/no question; the ratios are a trend, and trends are where protection silently erodes.

One more guard: nebula doctor

Most silent-fallback failures trace back to a keep rule that is too broad. nebula doctor analyzes your configuration against the assembly and flags rules that match far more than they probably should:

nebula doctor MyApp.dll

It will tell you, for example, that keep: MyApp.* is holding 400 of 412 types legible — almost certainly not what you intended when you only meant to preserve a plugin contract. Run it when renameRatio looks low or residualPublicSurface is longer than you expected; it turns "why isn't this being renamed?" into a direct answer.

Takeaway

Obfuscation that runs but does not apply is worse than no obfuscation, because it ships with a false sense of security. Nebula.NET 2.2.0 makes that failure impossible to miss: emit the protection report on every build so you can see exactly what landed, run nebula verify as a gate so a skipped transform fails the build on a dedicated exit code, archive and diff the report so slow erosion shows up as a trend, and keep nebula doctor handy when a keep rule is doing more than you asked. Protect the software you have the right to protect — and prove, on every build, that you actually did.

Keyright 2.9.0 makes those the first-class things a license grants. AI and agent entitlements name the models, endpoints and tools a build may touch, and bound an autonomous agent with a credit budget and a lease — all enforced fail-closed and offline from the signed license, with an opt-in metered POST /v1/consume for running usage across instances.

The entitlement shape

Six conventional keys sit on a license tier as a template; issuing a license at that tier bakes them into the signed lease the customer activates.

• ai.enabled — the master switch. Boolean. When false, nothing else matters.
• ai.models — an allow-list of model identifiers the build may call, e.g. openai/gpt-5, anthropic/claude-sonnet-4.6.
• ai.endpoints — the API hosts a build may reach, e.g. api.openai.com.
• ai.tools — the tool names an agent may invoke, e.g. web.search, code.run.
• agent.budget.credits — the hard ceiling of credits one agent may spend.
• agent.lease.seconds — how long an agent may run before its lease must be renewed.

The three list-valued keys are allow-lists with wildcards. A * matches any single segment, so openai/gpt-* admits openai/gpt-5 and openai/gpt-5-mini but not openai/o3; a bare * admits everything in that dimension. Allow-lists fail closed: a model, endpoint or tool that matches nothing on the list is denied. You grant by naming; you never have to enumerate what is forbidden.

A signed license, carrying AI entitlements

Here is what a Pro-tier agent license looks like once issued. The ent block is the entitlement template baked in at issue time; the whole payload is signed, so every value below is tamper-evident.

{
  "sub": "acme-corp",
  "product": "atlas-agent",
  "tier": "pro",
  "exp": "2027-11-12T00:00:00Z",
  "ent": {
    "ai.enabled": true,
    "ai.models": ["openai/gpt-5", "openai/gpt-5-mini", "anthropic/claude-*"],
    "ai.endpoints": ["api.openai.com", "api.anthropic.com"],
    "ai.tools": ["web.search", "code.run", "file.read"],
    "agent.budget.credits": 50000,
    "agent.lease.seconds": 3600
  },
  "sig": "ed25519:9f2c…c41a"
}

Note what this grants: any current Claude model (anthropic/claude-*) but only two specific OpenAI models; two provider endpoints; three tools; fifty thousand credits per agent; a one-hour lease. Change any character — add a model, raise the ceiling — and the Ed25519 signature no longer verifies against the public key the app embeds at build time. The check fails closed rather than silently granting more.

Reading and enforcing in your app

The SDK parses the entitlements from the verified lease once, then answers synchronously with no network call. In C#, the AI entitlements hang off info.Ai:

var client = KeyrightClient.Initialize(options);
var info = await client.ActivateAsync(licenseKey);   // lease cached locally

// Guard the master switch first.
if (!info.Ai.Enabled)
    throw new FeatureNotLicensedException("ai");

// Soft check — branch without throwing.
if (info.Ai.AllowsModel("openai/gpt-5"))
    useModel("openai/gpt-5");

// Hard check — throws ModelNotLicensedException when the model is not allowed.
info.Ai.EnforceModel(requestedModel);

// Endpoints and tools work the same way.
info.Ai.EnforceEndpoint("api.openai.com");
info.Ai.EnforceTool("code.run");

// The per-agent budget ceiling is readable offline.
long ceiling = info.AgentBudgetCredits;   // 50000, straight from the signed lease

AllowsModel returns a boolean after matching the identifier against ai.models, wildcards included; EnforceModel is the throwing form you put at the boundary of the call itself. Both fail closed: an unknown model is denied, and a lease with no ai.models key grants nothing.

The same surface exists in the other SDKs — same identifiers, same wildcard semantics, idiomatic casing:

// Node
if (info.ai.allowsModel("anthropic/claude-sonnet-4.6")) { /* ... */ }
info.ai.enforceModel(requestedModel);        // throws when not allowed

# Python
if info.ai.allows_model("anthropic/claude-sonnet-4.6"):
    ...
info.ai.enforce_model(requested_model)        # raises when not allowed

// Java
if (info.ai().allowsModel("anthropic/claude-sonnet-4.6")) { /* ... */ }
info.ai().enforceModel(requestedModel);       // throws when not allowed

Metering a per-agent credit budget

agent.budget.credits is the offline ceiling — a hard cap an air-gapped agent self-limits against. But a real agent fleet shares one budget across many concurrent instances, and each needs to know the running total, not just the cap. That is what POST /v1/consume meters.

Before (or after) a unit of work, the agent reports what it spent. The service decrements a shared counter keyed to the license and returns the remaining balance; when a charge would take the balance below zero it is rejected, and the agent stops. The call is the only part of AI enforcement that touches the network, and only when you opt into shared metering.

// Charge the shared budget for one step. Fails closed when exhausted.
var result = await client.ConsumeAsync(new ConsumeRequest
{
    AgentId = agentId,
    Credits = step.EstimatedCredits
});

if (!result.Granted)
    throw new AgentBudgetExhaustedException(result.Remaining);  // Remaining == 0

logger.LogInformation("Agent {Agent} spent {Spent}; {Left} credits left",
    agentId, step.EstimatedCredits, result.Remaining);

The offline ceiling and the online meter compose. An agent that cannot reach the service still cannot exceed info.AgentBudgetCredits locally; an agent that can reach it additionally cannot exceed the shared balance, so ten instances cannot each spend the full ceiling. agent.lease.seconds bounds the other axis: a runaway agent whose lease has lapsed stops regardless of remaining credits.

A concrete gating scenario

Put it together. A customer on the license above spins up an agent and, on step three, the planner asks for openai/o3 — a model not on their allow-list — then requests a 40,000-credit batch.

public async Task RunStep(AgentStep step)
{
    // 1. Deny the unlicensed model, before any provider call or spend.
    if (!info.Ai.AllowsModel(step.Model))
        throw new ModelNotLicensedException(step.Model);   // "openai/o3" is denied

    // 2. Enforce the tool and endpoint the step wants.
    info.Ai.EnforceTool(step.Tool);
    info.Ai.EnforceEndpoint(step.Endpoint);

    // 3. Meter the spend against the shared per-agent budget.
    var charge = await client.ConsumeAsync(new ConsumeRequest
    {
        AgentId = step.AgentId,
        Credits = step.EstimatedCredits        // 40000 requested
    });
    if (!charge.Granted)
        throw new AgentBudgetExhaustedException(charge.Remaining);

    await Execute(step);
}

openai/o3 is rejected at line one — offline, before a single token is bought — because it matches nothing in ai.models. Had the planner asked for openai/gpt-5-mini instead, the model check would pass, the tool and endpoint checks would pass, and the 40,000-credit charge would succeed against a fresh 50,000 ceiling — but a second such step would be rejected with Remaining == 10000 < 40000, and the agent would stop rather than overspend. No build change, no redeploy: moving openai/o3 into the plan, or raising the ceiling to 100,000, is a change to the tier template and a re-issued license.

Takeaway

Treat AI capabilities the way you already treat features: as named, signed entitlements your code checks locally. Let ai.models, ai.endpoints and ai.tools say what an agent may call and agent.budget.credits / agent.lease.seconds say how much and how long — enforce them fail-closed with AllowsModel / EnforceModel and meter shared spend through POST /v1/consume. The model allow-list, the tool allow-list and the budget ceiling all hold offline, straight from the signature; metering is the one thing you reach the network for, and only when a fleet shares a budget. Your packaging — which tier gets which models, how many credits — stays configuration on the server, not constants in your binary.

Glass.NET 1.3.0 covers both. It adds a headless CLI — the same ICSharpCode.Decompiler engine as the UI, no window required — and glass mcp, a Model Context Protocol server that lets an AI assistant open assemblies and read decompiled C# on your behalf. Everything below is strictly static analysis: Glass reads metadata and IL and reconstructs C#. It never runs the assembly it inspects. And all of it is free — no tiers, no license, no seats.

The command surface

Four commands do the batch and scripting work, plus the server:

• glass export — reconstruct a buildable C# project, or dump a single member.
• glass sbom — emit a software bill of materials for an assembly or package.
• glass verify — check a NuGet package's authenticity and strong-name identity.
• glass diff — compare two builds and report what changed in the public surface.
• glass mcp — start the MCP server for an AI assistant.

Run glass --help for the full list; every command takes --json so you can pipe output into jq or a build step.

glass export — a buildable project, or one member

Point export at an assembly and a directory and you get a reconstructed, compilable project back:

$ glass export ./Acme.Payments.dll -o ./out/Acme.Payments
Decompiling Acme.Payments.dll (net8.0) …
  142 types, 1,206 members
Wrote ./out/Acme.Payments/Acme.Payments.csproj
Wrote 142 source files
Done in 1.9s — static analysis only, assembly was not executed.

That .csproj targets the assembly's own TFM and lists its references, so dotnet build ./out/Acme.Payments just works — useful when you need to diff against source, patch-and-recompile, or hand a reproducible tree to someone.

When you only care about one method, skip the whole project and ask for the member by its documentation-comment ID:

$ glass export ./Acme.Payments.dll --member "M:Acme.Payments.Gateway.Charge(System.Decimal)"

public ChargeResult Charge(decimal amount)
{
    if (amount <= 0m)
        throw new ArgumentOutOfRangeException(nameof(amount));
    var req = new ChargeRequest(amount, _clock.UtcNow);
    return _transport.Send(req);
}

You can pass a type ID (T:Acme.Payments.Gateway) to dump every member of a type, or --il to get the IL view instead of C#. This is the fast path for "show me exactly what this one method does" without opening a UI.

glass sbom — a bill of materials for a binary

glass sbom reads an assembly's metadata and produces a dependency inventory in CycloneDX JSON — the assembly's identity, its target framework, and every AssemblyRef it binds against, with versions and public-key tokens:

$ glass sbom ./Acme.Payments.dll --format cyclonedx -o payments.sbom.json
$ jq '.components[] | {name, version}' payments.sbom.json
{ "name": "Newtonsoft.Json", "version": "13.0.3" }
{ "name": "System.Text.Json", "version": "8.0.0" }
{ "name": "Acme.Core", "version": "4.2.1" }

Because it works from the compiled binary rather than a packages.lock.json, it tells you what the shipped artifact actually references — including transitive assemblies that a project-file audit can miss. Point it at a .nupkg and Glass enumerates the assemblies inside each lib/<tfm> folder and merges their references into one document.

glass verify — is this package what it claims to be?

Before you trust a package, glass verify checks two things statically: the NuGet signature on the .nupkg, and the strong-name identity of the assemblies inside it.

$ glass verify ./Acme.Payments.4.2.1.nupkg
Package     Acme.Payments 4.2.1
Signature   author-signed, counter-signed (timestamp 2026-10-30)  ✓
Assemblies
  Acme.Payments.dll   strong-named  pkt=b77a5c561934e089   ✓
  Acme.Core.dll       NOT strong-named                     ⚠
Verdict     signature valid; 1 assembly unsigned — review before trusting.

It reports whether the package is author- or repository-signed, whether the signature is intact, and which assemblies carry a strong name and which don't. It does not vouch for intent — a validly signed package can still do something you dislike — which is why verify pairs naturally with export to actually read the code. And, as with every command, verification reads bytes; it never runs the package.

glass diff — what changed between two builds

Hand diff two versions of the same assembly and it reports the delta in the public API surface:

$ glass diff ./Acme.Payments-4.2.0.dll ./Acme.Payments-4.2.1.dll
+ public ChargeResult Gateway.Charge(decimal, Idempotency)   added overload
- internal void Gateway.ResetCounters()                       removed
~ public sealed class ChargeResult                            field layout changed
3 changes (1 added, 1 removed, 1 modified)

With --json this becomes a gate: fail the build when a dependency bump quietly changes a signature you depend on, or flag an internal-to-public promotion in review.

A worked example: vet a NuGet package before trusting it

Say a new transitive dependency, Contoso.Telemetry, showed up in a lockfile and you want to know what it does before it ships. The whole audit is static — nothing here executes the package:

# 1. Download the package without installing it into a project.
$ nuget install Contoso.Telemetry -Version 2.1.0 -OutputDirectory ./pkgs -DependencyVersion Ignore

# 2. Is it signed, and are its assemblies strong-named?
$ glass verify ./pkgs/Contoso.Telemetry.2.1.0/Contoso.Telemetry.2.1.0.nupkg
Signature   author-signed  ✓
Assemblies  Contoso.Telemetry.dll  strong-named  ✓

# 3. What does it reference? (Watch for networking / reflection you didn't expect.)
$ glass sbom ./pkgs/Contoso.Telemetry.2.1.0/lib/net8.0/Contoso.Telemetry.dll --json \
    | jq -r '.components[].name'
System.Net.Http
System.Text.Json

# 4. It binds System.Net.Http — read the code that uses it.
$ glass export ./pkgs/Contoso.Telemetry.2.1.0/lib/net8.0/Contoso.Telemetry.dll \
    --member "M:Contoso.Telemetry.Beacon.Flush"

Four commands, no window, nothing executed — and you've gone from "an unknown dependency appeared" to reading the exact method that touches the network.

The flow that ties it together:

glass mcp — hand the decompiler to your AI assistant

The same static inspection is available to an AI coding assistant through the Model Context Protocol. glass mcp starts a JSON-RPC server over stdio that exposes a small set of read-only tools:

Register it with any MCP-capable assistant by pointing command at glass:

{
  "mcpServers": {
    "glass": { "command": "glass", "args": ["mcp"] }
  }
}

Now, instead of you decompiling a method and pasting it into chat, the assistant does it itself. A tools/call for glass_decompile looks like this on the wire:

{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
  "params": { "name": "glass_decompile",
    "arguments": { "member": "M:Contoso.Telemetry.Beacon.Flush" } } }

and the server answers with the reconstructed C# as text content:

{ "jsonrpc": "2.0", "id": 7,
  "result": { "content": [ { "type": "text",
    "text": "private async Task Flush(CancellationToken ct)\n{\n    using var http = new HttpClient();\n    await http.PostAsync(_endpoint, Serialize(_buffer), ct);\n}" } ] } }

So you can ask your assistant, in plain language, "open Contoso.Telemetry 2.1.0 and tell me what Beacon.Flush sends and where" — and it opens the assembly, reads the decompiled method, and tells you it POSTs a serialized buffer to a configured endpoint. The assistant is reading static output: glass mcp decompiles, it does not execute, so even an assistant acting on your behalf can inspect an untrusted package without running it.

Takeaway

Glass.NET 1.3.0 turns decompilation from something you do by hand in a window into something you can script and delegate. Use glass export for a buildable tree or a single method, glass sbom for a bill of materials, glass verify to check a package's signature and strong names, and glass diff to gate on public-surface changes in CI. When you'd rather ask a question than run a command, glass mcp gives your AI assistant the same read-only, static view. Every one of these reads the binary and reconstructs C# — none of them ever run it — and all of it is free. Grab the latest build from the Glass.NET download page and point it at the next dependency you're unsure about.

The dump attack

A memory-dumping tool (the genre that MegaDumper and similar represent) does something conceptually simple: attach to or scan your running process, locate the loaded .NET module in its address space, and write those bytes out as a .dll. Because it copies the loaded image, it gets:

• strings that string-encryption decrypted at runtime, now sitting in the clear,
• the real IL for methods the JIT needed (for non-virtualized code),
• a module that can often be loaded straight into a decompiler.

The attacker never had to defeat your on-disk file. They let your own process do the decryption and then photographed the result. This is why "I encrypted my strings" is not, by itself, enough.

How anti-dump defends the loaded image

The key insight behind anti-dump is that a PE's headers are read once, by the loader, at load time. After the CLR has parsed the DOS header, NT headers, section table, and the CLI/metadata directory, the already-running code does not consult them again — the JIT works from structures the runtime has already built. So those header regions are, from the running program's perspective, dead weight after startup, while from a dumper's perspective they are essential: without valid headers, the dumped bytes are not a recognizable assembly.

Anti-dump exploits that asymmetry. A small routine, injected and run early, locates the module's base address in memory (for example via the module handle / Marshal.GetHINSTANCE) and zeroes or scrambles the header regions — the DOS and NT headers, the section table, and the metadata directory pointers. Your program keeps running without noticing. A tool that then dumps the module copies a blob whose front matter is destroyed, so it does not load and does not open in a decompiler until someone manually reconstructs the headers from scratch — a far cry from one-click dumping.

Honest limits, and layering

Anti-dump is a speed bump, not a wall, and it is important to say so plainly. A determined attacker can rebuild PE headers by hand, or dump at a moment before the wipe runs, or reconstruct metadata from the live runtime. Its value is defeating the easy path — the automated dumpers that make lifting an assembly a thirty-second job — and raising the cost of the hard path.

That is exactly why it belongs in a stack, not alone:

• String encryption keeps secrets off disk; anti-dump keeps the decrypted form harder to capture.
• Anti-debugging and anti-tamper make the process hostile to the tools a dumper is usually paired with.
• Code virtualization ensures that even a successful dump yields virtualized methods an attacker still cannot read.

Layered, a dump becomes expensive to take and worth little once taken.

Doing this with Nebula

Nebula applies anti-dump conservatively — corrupting only the header regions the runtime has finished with — so the protection is transparent to your app while a casual memory dump yields an unusable blob. It composes with Nebula's string encryption, anti-debugging, anti-tamper, and (on Pro) code virtualization, so the in-memory image is defended at the same depth as the on-disk file. Where an assembly legitimately reloads its own image at runtime, you can exclude it.

Start with the free edition, or see the plans for the full in-memory protection stack.

Why ephemeral breaks node-locking

Node-locking derives a fingerprint from a machine's hardware and binds the license to it, so a seat represents a distinct device. That is exactly right for desktops and exactly wrong for ephemeral compute, where "distinct device" is a meaningless unit — there is a new one every few minutes, none of them lasts, and the thing you actually want to limit is not how many machines but how much concurrent (or total) use.

Worse, the cleanup assumption fails too. Node-locked seats are normally freed by an explicit deactivation when a user moves machines. A CI runner is not deactivated; it is deleted. So its seat lingers until something reclaims it, and in a busy pipeline seats are consumed far faster than any manual process frees them.

Three models that fit ephemeral compute

Pick by what you actually mean to limit.

Floating / concurrency. License the number of simultaneous uses, not machines. A pool of N concurrent leases means at most N builds run at once; a finished (or destroyed) runner's lease is reclaimed and the next build takes it. This is the natural fit when parallelism is what you are selling — see floating concurrent licenses. Pair it with heartbeat lease reaping so a runner that vanishes without deactivating has its lease freed after a short timeout rather than lingering.

Build-scoped entitlement. If you only need to gate the feature in CI (prove the customer is licensed, without counting machines), validate a signed entitlement with a token that does not consume a seat at all. The build checks the entitlement offline and runs; nothing is node-locked.

Metered builds. If the fair unit is total runs, meter them — count builds as usage against a quota, with an idempotency key so a retried build does not double-count.

Detecting CI and taking the right path

The implementation hinge is letting your software know it is in CI so it takes the ephemeral path instead of the desktop one:

static bool IsCi() =>
    Environment.GetEnvironmentVariable("CI") is "true" or "1"
    || Environment.GetEnvironmentVariable("GITHUB_ACTIONS") == "true"
    || Environment.GetEnvironmentVariable("GITLAB_CI") == "true"
    || Environment.GetEnvironmentVariable("TF_BUILD") == "true"      // Azure Pipelines
    || Environment.GetEnvironmentVariable("JENKINS_URL") is not null;

// In CI, validate against a concurrency/entitlement path — not a node-locked activation.
var result = IsCi()
    ? keyright.ValidateFloating()   // or a build-scoped entitlement check
    : keyright.Activate();          // normal desktop node-lock

The desktop experience is unchanged; the CI path simply validates the dimension that makes sense there and never writes a per-machine activation that would strand a seat.

Doing this with Keyright

Keyright supports all three models — floating concurrency with heartbeat reaping, build-scoped entitlements validated without consuming a seat, and metered build counting — so you can license ephemeral CI and autoscaled agents by concurrency or usage instead of by machine, and never watch a pipeline exhaust your seats. Each path validates offline against a signed payload, so a runner with restricted egress still works. Keyright is self-hosted, so your entitlements and usage data stay on infrastructure you control.

See the plans, or start from floating concurrent licenses and add CI detection to route runners onto it.

How P/Invoke is stored

A [DllImport] method does not carry a method body — it is an extern declaration. In the assembly it becomes a method flagged pinvokeimpl, with an entry in the ImplMap metadata table that records four things: the module (the native DLL), the entry-point name, the calling convention, and the character set / name-mangling rules. The managed signature (parameter and return types, plus any [MarshalAs]) lives in the normal method signature and parameter metadata.

A decompiler like Glass reads the ImplMap and the signature and reconstructs the original declaration — attribute and all:

[DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true,
           CallingConvention = CallingConvention.Winapi)]
static extern IntPtr CreateFileW(
    [MarshalAs(UnmanagedType.LPWStr)] string lpFileName,
    uint dwDesiredAccess, uint dwShareMode, IntPtr lpSecurityAttributes,
    uint dwCreationDisposition, uint dwFlagsAndAttributes, IntPtr hTemplateFile);

Everything in that reconstruction — the DLL name, CharSet, SetLastError, CallingConvention, and the [MarshalAs] on the string — came from metadata, not from guesswork.

Building a native-call inventory

Because every P/Invoke is an ImplMap entry, you can enumerate an assembly's entire native surface. In Glass, open the assembly and look at its P/Invoke methods: each one names a DLL and a function. That inventory answers the questions that matter when you are auditing something you did not write:

• Which native libraries does it touch? kernel32/user32 is routine; a bundled unknown .dll, ws2_32 (sockets), or advapi32 crypto/registry calls are worth a closer look.
• What can it do to the system? File, process, registry, and network functions are all visible by name.
• How does data cross the boundary? The [MarshalAs], [StructLayout], and [FieldOffset] metadata reconstruct the ABI contract, so you can see how a managed struct maps to the native layout a function expects.

This is the same workflow as analyzing a suspicious assembly, with native interop as the lens.

The modern twist: LibraryImport

.NET 7 introduced [LibraryImport], a source-generated alternative to [DllImport]. Instead of the runtime marshalling arguments, a source generator emits the marshalling as C# at compile time: a partial method you declared, plus a generated stub that marshals the arguments and calls a private, DllImport-style native target. Decompiled, a [LibraryImport] therefore shows up as more code than a classic P/Invoke — the generated stub is right there — which is actually a bonus for reading: you see exactly how each argument is converted, rather than trusting the runtime to do it. It reads much like any source-generated code does once lowered.

Doing this with Glass

Glass reconstructs [DllImport] declarations from the ImplMap — DLL, entry point, calling convention, charset, and [MarshalAs] — and shows the generated stubs behind [LibraryImport], so you can read an assembly's complete native-interop surface and the exact marshalling of every call. It is the fastest way to answer "what does this assembly do to the machine?" and it is free.

Point Glass at an assembly and list its P/Invoke methods to see its native reach at a glance.

The three problems a channel creates

Selling through partners raises three distinct questions that direct licensing never has to answer:

1. Authority — how does a partner mint keys without being able to mint anything? They must be confined to their product, their tier, their quota.
2. Attribution — when a key activates, which partner provisioned it? You need this for revenue share, royalties, and scoped support, and it must be forgery-proof.
3. Isolation — a partner must never see, revoke, or interfere with another partner's (or your direct) customers.

All three are solved by two mechanisms: a scoped provisioning token per partner, and a partner claim inside the signed key.

Scoped provisioning tokens

Instead of your admin credential, each partner gets a provisioning token whose authority is bounded to exactly what the agreement allows:

• a product/tier it may issue (and no others),
• a quota — a maximum number of keys or seats, or a value cap,
• an expiry on the token itself,
• and no read/revoke access to anything it did not create.

The partner calls a provisioning endpoint with that token to mint a key on demand (or you pre-generate a block and hand it over). The issuing service enforces the quota as they go and refuses once it is reached. A partner who leaks or abuses their token can only ever damage their own allocation — never your catalog, your pricing, or another partner's customers.

// Partner side: mint a key within the partner's scope (no admin token involved).
var key = await channel.ProvisionAsync(new ProvisionRequest {
    Product = "acme-suite",
    Tier    = "pro",
    Seats   = 5,
    Customer = "end-customer-ref",   // partner's own reference
});
// The service checks the partner token's quota/product scope and refuses if exceeded.

The partner claim: attribution that cannot be forged

Every key a partner issues carries a partner/reseller claim stamped into the signed payload — partnerId, and whatever else you need for accounting. Because it is inside the signature, it is tamper-evident (editing it breaks validation) and it travels with the key forever. That gives you, without any trust in the partner's own records:

• Revenue share / royalties — sum activations by partnerId.
• Scoped support — a key presented to support identifies its partner instantly.
• Scoped revocation — revoke by partnerId to unwind a terminated partner, affecting only their keys (revocation strategies apply per-partner).

This pairs naturally with product claim suites when a partner resells a bundle, and with entitlements when their tier unlocks a different feature set than your direct one.

White-label: making the vendor invisible

A true white-label deployment goes one step further: the end customer should not see you at all. Two pieces make that work. The key format and activation messaging carry the partner's branding rather than yours. And each partner can be given its own signing identity (or product), so the keys validate against a public key the partner embeds in their branded build — the cryptography is scoped to them. The licensing engine is yours; every surface the end customer touches is the partner's.

Doing this with Keyright

Keyright supports this channel model directly: issue each partner a scoped provisioning token (bounded by product, tier, and quota), stamp a partner claim into every signed key for forgery-proof attribution, and keep revocation and reporting scoped per partner — all without ever sharing your admin credentials. Partners provision on demand through the API or from pre-generated blocks, and white-label partners get their own signing identity so your name never appears. Because Keyright is self-hosted, the signing keys and all partner and customer data stay on infrastructure you control.

See the plans, or start from automating license fulfillment and add a partner scope to the issuance.

Why ClickOnce is unusually sensitive

Most deployment mechanisms copy files and run them. ClickOnce does more: its application manifest records, for every file in the deployment, a cryptographic hash and a size, and the ClickOnce runtime verifies each file against that record before launching. This is a tamper- and corruption-detection feature — it guarantees the user runs exactly what you published.

That guarantee is precisely what obfuscation collides with. Obfuscation rewrites the bytes of your assemblies — renaming, control-flow flattening, string encryption all change the file. If the manifest's hash for MyApp.dll was computed over the pre-obfuscation DLL, the post-obfuscation DLL you actually ship no longer matches, and ClickOnce halts with a validation error before a line of your code runs.

The correct build order

The rule is one sentence: every transformation of the assemblies must happen before the manifests are generated, and manifest generation must be last. Concretely:

1. Compile the project.
2. Obfuscate the output assemblies.
3. Re-apply the strong name if you delay-signed (obfuscation that re-emits the assembly must preserve or re-establish the strong name — see re-signing obfuscated assemblies).
4. Authenticode-sign the binaries, if you sign them.
5. Generate the application and deployment manifests with mage/mageUI or the MSBuild ClickOnce targets — this is where the hashes are computed, over the now-final files.
6. Sign the manifests.

If you use Visual Studio's one-click Publish, the trap is that publish does step 5 for you right after build, before any post-build obfuscation hook has run. The fix is to take manifest generation out of the Publish step and run mage yourself after obfuscation (a small CI script), or run obfuscation as part of the build such that it completes before the ClickOnce targets execute.

A minimal CI sketch

# 1-2: build then obfuscate the output
dotnet build -c Release -o publish
nebula protect publish/MyApp.dll   # (plus other assemblies)

# 3-4: re-sign as needed
sn -R publish/MyApp.dll keypair.snk           # if delay-signed
signtool sign /f cert.pfx publish/MyApp.dll    # Authenticode (optional)

# 5: generate manifests over the FINAL files (hashes computed now)
mage -New Application -Processor msil -ToFile publish/MyApp.exe.manifest \
     -Name "MyApp" -Version 1.2.0.0 -FromDirectory publish
mage -New Deployment -Processor msil -Install true \
     -ToFile MyApp.application -AppManifest publish/MyApp.exe.manifest \
     -providerUrl "https://downloads.example.com/MyApp/"

# 6: sign the manifests
mage -Sign MyApp.application -CertFile cert.pfx

Because the hashes in step 5 are taken over the obfuscated, signed assemblies, the ClickOnce runtime's verification passes and the app launches.

Doing this with Nebula

Nebula slots into the obfuscation step above, and because it runs as a build/CI stage (see obfuscating on the build server only and the Azure DevOps / GitHub Actions guides), it is straightforward to place it before ClickOnce manifest generation. It preserves strong-name signing so the re-sign step is clean, and its keep-rules handle any WinForms/WPF reflection your app does. The only ClickOnce-specific rule is the ordering — get that right and nothing else changes.

Start with the free edition, or see the plans.

What ships to the browser

When a Blazor WebAssembly app loads, it fetches a manifest — _framework/blazor.boot.json — that lists every assembly the app needs, each with a filename and an integrity hash. The browser then downloads those files from _framework/. In current .NET they arrive as webcil: your PE assembly wrapped in a WebAssembly-compatible container. Webcil exists for a mundane reason — some proxies, CDNs, and corporate firewalls mangle or block raw .dll downloads — so the .dll is repackaged in a form that sails through as a .wasm-style asset. Crucially, webcil is a wrapper, not encryption: the original ECMA-335 metadata and IL are inside, byte-for-byte.

So the chain from "deployed app" to "your source" is short: blazor.boot.json names the assemblies, _framework/ serves them, webcil holds the real PE, and a decompiler lifts the IL back to C#.

Reading them in Glass

The workflow is the same one you would use on any assembly, with one small front step for webcil:

1. Open the running app's _framework/blazor.boot.json (dev tools → Network, or fetch it directly) and note the assemblies you care about — typically your app assembly and any of your own libraries, not the framework ones.
2. Download those files from _framework/.
3. Open them in Glass. Glass reads the .NET assembly inside the webcil container and reconstructs C# — your components, your services, your models — exactly as it does for a desktop DLL. (For older Blazor versions the files are plain .dll and open directly.)

From there it is ordinary decompilation: navigate types, read method bodies, follow references — the same as decompiling any DLL to C#.

The real lesson: client-side is public

This is less a decompilation tutorial than a security reminder with a demonstration attached. Blazor WebAssembly code runs on the user's machine, so it is as exposed as JavaScript. Anything you embed in it — an API key, a connection string, a licensing bypass, proprietary pricing logic — can be read back in minutes with the steps above. The defensive conclusions:

• Keep secrets and sensitive logic server-side (a backend API, or Blazor Server where the C# stays on the server and only DOM diffs cross the wire).
• If you must ship sensitive logic to the client, obfuscate it — Blazor WASM assemblies can be renamed and string-encrypted like any assembly (see protecting Blazor WebAssembly from decompilation) — while remembering that client-side protection raises the bar, it does not make the code secret.

Being able to read your own app the way an attacker would is the point: do it once, and you will know exactly what not to put in the browser.

Doing this with Glass

Glass opens the assemblies behind a Blazor WebAssembly app — reading straight through the webcil wrapper to the IL and reconstructing C# — so you can audit precisely what your deployed client exposes. It is free, and it is the same tool you would use to understand any unfamiliar .NET code.

Grab it from the Glass page and open your own app's _framework to see what ships.

The key distinction: the generator ships, the generated code does not

Two different pieces of code are in play, and conflating them is where the confusion starts.

The generated code — the DynamicMethod body, the TypeBuilder type, the compiled expression delegate — is created in memory at runtime and never written to your assembly. The obfuscator never sees it, so it is neither protected nor harmed. (If protecting it mattered you could not, anyway; it is ephemeral.)

The generator — the method full of il.Emit(...) calls, or the expression-building code — is in your assembly. It is plain IL and gets renamed, control-flow-flattened, and string-encrypted like everything else. That is fine, with one catch: the generator usually references your types and members, and how it references them decides whether obfuscation breaks it.

Where it breaks: string-based member lookup

A generator that resolves the members it emits calls to by string name is the one that breaks. Consider a DynamicMethod that calls a getter it found by name:

MethodInfo getter = typeof(Order).GetMethod("get_Total")!; // string lookup
var dm = new DynamicMethod("ReadTotal", typeof(decimal), new[] { typeof(Order) });
var il = dm.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Callvirt, getter);   // emits a call to whatever `getter` resolved to
il.Emit(OpCodes.Ret);

After obfuscation renames Order.Total (and its get_Total accessor), the string "get_Total" no longer matches anything, so GetMethod returns null and the next line throws NullReferenceException / ArgumentNullException — at runtime, with no compile-time hint. Same failure for TypeBuilder code that defines overrides by name, and for Expression.Property(p, "Total").

The fix is one of two things. Keep the name of the specific members the generator looks up by string (a targeted keep-rule, not a blanket exclusion). Or, better, stop using strings: capture the member through something the obfuscator can rewrite.

What survives: references the obfuscator can see

When the generator captures a member as a metadata reference rather than a string, the obfuscator rewrites that reference as part of the rename, and everything keeps working:

// Survives renaming — MethodInfo captured from a delegate, not a string.
MethodInfo getter = ((Func<Order, decimal>)(o => o.Total)).Method; // won't help: that's a lambda's Method
// Better: read the MemberInfo out of an expression tree
Expression<Func<Order, decimal>> e = o => o.Total;
var prop = (PropertyInfo)((MemberExpression)e.Body).Member;          // real PropertyInfo, token-based

Compiled expression trees are the friendly case: o => o.Total carries a PropertyInfo reference that the obfuscator renames along with the property, so Expression.Compile() binds to the right member afterwards. The rule of thumb: expression trees and typeof(T).GetMethod(someMethodInfo-derived-reference) are rewrite-safe; any "string" member name in a generator is not.

A practical checklist

• Audit your runtime-codegen sites for string literals naming your own members; those are the breakage points.
• Prefer expression trees or delegate/MethodInfo capture over GetMethod("Name") where you can.
• For the unavoidable string lookups, add targeted keep-rules for exactly those members — and remember their bodies are still obfuscated; only the name survives.
• Test the obfuscated build's codegen paths explicitly, because the compiler and even a smoke test that skips the generated path will not catch a broken emit.

Doing this with Nebula

Nebula renames, flattens, and string-encrypts your generators like any other code, and its keep-rule model is precise enough to preserve exactly the members your Reflection.Emit or expression-building code resolves by name, while still obfuscating their bodies. Pair it with the guidance in reflection and serialization pitfalls and you can ship obfuscated code that generates code without a single runtime surprise.

Start with the free edition, or see the plans.

The root cause: versioned install directories

A cached activation is a signed lease — a small, node-locked, RSA-signed blob the SDK writes after a successful activation so the app can validate offline on later launches without phoning home. The question is which directory it lands in.

Velopack and Squirrel do not update in place. They install version 1.0.0 to …\YourApp\app-1.0.0\, then install 1.1.0 to …\YourApp\app-1.1.0\ and point a stub launcher at the new folder. If your lease was written next to the EXE — AppDomain.CurrentDomain.BaseDirectory or Assembly.Location's folder — it was written into app-1.0.0, and the 1.1.0 process starts in a folder where that file does not exist. The lease is not gone; it is stranded in the previous version's directory, which the updater will eventually clean up.

Where to put the lease, per updater

The rule is one line: store the lease in a stable, version-independent location, and point the SDK's lease-cache path at it. The specifics differ by updater.

Velopack / Squirrel. Use a fixed per-user folder — %LocalAppData%\YourApp (the stable parent of the app-* folders) or Roaming if you want it to follow a roaming profile:

string dir = Path.Combine(
    Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
    "YourApp");
Directory.CreateDirectory(dir);
keyright.LeaseCachePath = Path.Combine(dir, "license.lease");

MSIX. Packaged apps are redirected, but in your favour: ApplicationData.Current.LocalFolder persists across package updates because the package identity is stable. Write the lease there (not next to the EXE inside the package, which is read-only anyway):

// MSIX-packaged app
var folder = Windows.Storage.ApplicationData.Current.LocalFolder.Path;
keyright.LeaseCachePath = Path.Combine(folder, "license.lease");

This pairs with the packaging and machine-id details in licensing an MSIX-packaged app.

ClickOnce. Avoid the per-deployment data directory (it is isolated per version and migrated in ways you do not control). Use a fixed app-data folder you own, exactly like the Velopack case above.

In every case the SDK then reads that path on startup, verifies the lease signature against your embedded public key, and — because the hardware fingerprint is unchanged by a software update — validates offline with no server round-trip.

Why this is safe, and the idempotency backstop

Two facts make this robust. First, the lease is node-locked to hardware, and updating software does not touch the fingerprint, so a persisted lease is still valid for the machine after the update. Second, even in the edge case where a lease is genuinely lost (a user clears app-data, say), re-activating the same machine is idempotent in Keyright — the fingerprint matches the existing activation, so it does not burn a second seat (the mechanics are in node-locking and seat management). So the worst case is a silent, seat-neutral re-activation, and the normal case is no prompt at all.

Doing this with Keyright

Keyright lets you set the lease-cache path explicitly, so you control exactly where the signed activation lives — a stable %LocalAppData% folder, the MSIX LocalFolder, or your own ClickOnce data directory — and it validates offline against the hardware fingerprint after every update. Combined with idempotent same-machine re-activation, your users activate once and never see the prompt again, no matter how often you ship. It is self-hosted, so the activation data and signing stay on infrastructure you control.

See the plans, or start from storing an activated license on the client and move the path to a stable location.

What an R2R image actually contains

A normal .NET assembly is metadata + IL, JIT-compiled to native code on first execution. An R2R image is produced by crossgen2, which runs that JIT ahead of time and stores the resulting native code in the assembly — so the runtime can skip JITting on startup. Crucially, it stores the native code in addition to, not instead of, the original metadata and IL.

So the PE file contains three things that matter here: the ECMA-335 metadata tables (types, methods, signatures — untouched), the IL method bodies (also present), and a ReadyToRun section with precompiled native code plus the tables the runtime needs to use it. A ReadyToRunHeader, reachable through the CLI header's managed-native-header directory, ties it together and marks the image as R2R.

Why the decompiler ignores the native side

A decompiler like Glass is an IL-to-C# reconstructor: it walks the metadata tables to recover types and signatures, then reads each method's IL body and lifts it back to C#. R2R's native code lives in a separate section with its own lookup tables, and the decompiler simply does not consult it — the IL is the authoritative, portable definition of every method, and it is still right there. So opening an R2R image is indistinguishable, from the decompiler's point of view, from opening a JIT-only assembly: same metadata, same IL, same C# out.

This is why you can decompile the .NET runtime libraries (which ship as R2R), a PublishReadyToRun app, or a crossgen'd container image without any special handling. The "it's precompiled" worry is about the native bytes, and those are not what a decompiler reads.

Recognizing R2R, and the one real exception

To confirm an assembly is R2R, look for the ReadyToRun header (tools label it "ReadyToRun" and often show an R2R version number), or simply know its origin: crossgen2 / PublishReadyToRun. The IL being present is the guarantee you can decompile it.

The exception that trips people up is NativeAOT, which sounds similar but is the opposite case. NativeAOT compiles the entire app to a self-contained native executable with no IL and no managed metadata to recover — there is nothing for an IL decompiler to read. The quick test: if a tool can load the file as a .NET assembly at all, it is managed (plain IL or R2R) and decompiles; if it is just a native binary, it is NativeAOT and you are looking at a native-disassembler job, not a decompilation one. (For how this affects your threat model as a vendor, see protecting .NET code from decompilation.)

Doing this with Glass

Glass opens ReadyToRun assemblies transparently — it reads the intact IL and reconstructs C#, ignoring the native R2R section, so the runtime libraries, a crossgen'd service, or a PublishReadyToRun app all read like any other assembly. It is the same workflow as decompiling a DLL to C#; R2R simply does not get in the way.

Glass is free — point it at an R2R image and see the IL come back as C#.

The counting trap

Reach for Environment.ProcessorCount and you will ship a licensing bug. It returns the number of logical processors available to the current process — which is not the capacity you are selling, in at least three ways:

• It counts hyperthreads, so an 8 physical-core chip typically reports 16.
• It shrinks under affinity: if the process is pinned to a subset of CPUs (via affinity masks or a scheduler), it reports the subset, not the machine.
• It ignores container quotas: in a Kubernetes pod limited to 2 CPUs on a 64-core node, it may still report a large number depending on runtime and version — you are not measuring the limit the orchestrator actually imposed.

So before you write a single check, decide which number is your licensing unit: physical cores, logical processors, or the container CPU quota. Then measure that one on purpose.

Measuring the right number

Logical processors (cheap, but least meaningful on its own):

int logical = Environment.ProcessorCount;

Physical cores on Windows — sum NumberOfCores across sockets:

using System.Management; // Windows only
int physical = 0;
using var searcher = new ManagementObjectSearcher("SELECT NumberOfCores FROM Win32_Processor");
foreach (var mo in searcher.Get())
    physical += Convert.ToInt32(mo["NumberOfCores"]);

Physical cores on Linux — count unique (physical id, core id) pairs:

var pairs = new HashSet<(string socket, string core)>();
string socket = "0", core = "0";
foreach (var line in File.ReadLines("/proc/cpuinfo"))
{
    if (line.StartsWith("physical id")) socket = line.Split(':')[1].Trim();
    else if (line.StartsWith("core id")) core = line.Split(':')[1].Trim();
    else if (line.Length == 0) pairs.Add((socket, core));
}
int physicalLinux = Math.Max(pairs.Count, 1);

Container CPU quota — the number that actually matters in Kubernetes/Docker:

// cgroup v2: /sys/fs/cgroup/cpu.max  →  "<quota> <period>" or "max <period>"
static double? CgroupCpuLimit()
{
    const string v2 = "/sys/fs/cgroup/cpu.max";
    if (File.Exists(v2))
    {
        var parts = File.ReadAllText(v2).Split(' ', StringSplitOptions.RemoveEmptyEntries);
        if (parts[0] == "max") return null;                 // unlimited
        return double.Parse(parts[0]) / double.Parse(parts[1]);
    }
    // cgroup v1
    const string q = "/sys/fs/cgroup/cpu/cpu.cfs_quota_us";
    const string p = "/sys/fs/cgroup/cpu/cpu.cfs_period_us";
    if (File.Exists(q) && File.Exists(p))
    {
        double quota = double.Parse(File.ReadAllText(q).Trim());
        if (quota <= 0) return null;                        // unlimited
        return quota / double.Parse(File.ReadAllText(p).Trim());
    }
    return null;
}

Pick one of these as your measured capacity — most server products settle on physical cores for bare-metal/VM and the cgroup quota (rounded up) for containers.

Binding the entitlement into the license

Measuring is only half the job; the measured number has to be checked against something the customer cannot edit. That something is a signed entitlement. The license carries a maxCores value in its payload, signed by your private key, and the client verifies the signature before trusting it (the mechanics are in licensing entitlements and feature flags and the anatomy of a signed key). Then, at startup:

var license = keyright.Validate();              // verifies signature against embedded public key
int licensedCores = license.GetInt("maxCores"); // trusted entitlement from the signed payload
int measured = MeasureLicensingCores();          // one of the numbers above, chosen per policy

if (measured > licensedCores)
{
    // Fail closed — but loudly and actionably.
    throw new LicenseException(
        $"This license permits {licensedCores} cores; this host exposes {measured}. " +
        $"Reduce the CPU allocation or upgrade the license.");
}

Two design notes worth the ink. First, fail closed, but diagnose: an operator who accidentally scheduled your service on a bigger node should read exactly what happened — measured versus licensed — not watch the process die with a generic error. Second, consider a short grace or a one-time warning before enforcement bites, so a transient over-provision during a rollout does not take down production; this mirrors the grace thinking in license server downtime and grace windows. Because the core count is read locally and the entitlement is verified locally, the whole check works offline and on every launch without a phone-home.

Doing this with Keyright

Keyright lets you put a maxCores (or maxLogicalProcessors, or a container-quota) entitlement into the signed license, and its .NET SDK verifies that payload against a public key you embed at build time — so the comparison between licensed and measured cores runs locally, offline, and fail-closed, with the diagnostic message you choose. You decide the counting policy; Keyright gives you the tamper-resistant number to check it against. It is self-hosted, so your signing key and your customers' license data stay on infrastructure you control.

See the plans, or start from adding licensing to a .NET app and add the core-count entitlement to the model you already have.

This post covers what each Unity backend actually exposes, the specific things Unity resolves by name, and the keep-rules that let you obfuscate aggressively without a single broken prefab.

Two backends, two threat models

Unity has two scripting backends, and they change what obfuscation even means.

Mono compiles your scripts to managed assemblies that ship as real .dll files (Assembly-CSharp.dll, Assembly-CSharp-firstpass.dll, and any precompiled assemblies/asmdefs). These are standard CLI images: decompilable, and therefore fully obfuscatable. Renaming, control-flow flattening, and string encryption all apply to the shipped binary exactly as they would to any .NET app.

IL2CPP takes that same managed IL and transpiles it to C++, which is then compiled to a native library for the target platform. There is no managed assembly to rename at runtime — but IL2CPP emits a global-metadata.dat file alongside the binary that preserves type names, method names, field names, and (critically) every string literal in clear text. Tools like Il2CppDumper read that file to reconstruct a near-complete picture of your code. So IL2CPP is not obfuscation; it is transpilation with a metadata sidecar. Protection there means transforming the managed assemblies before IL2CPP runs, so the names and strings that get baked into global-metadata.dat are already encrypted or renamed.

What Unity resolves by name — and will break if you rename it

The editor and runtime both do a surprising amount of string- and name-based binding. Each of these is a place where blind renaming corrupts the game.

• Serialized fields. Every public field and every [SerializeField] private field on a MonoBehaviour or ScriptableObject is saved into scenes, prefabs, and asset files keyed by its exact name. Rename the field and the saved value no longer loads.
• Script type references. A scene stores "this GameObject has a component of type PlayerController" by type (and assembly) identity. Renaming the class detaches every instance.
• UnityEvents. Inspector-wired UnityEvent listeners (your button OnClick, etc.) persist the target method name as a string. Rename the method and the button does nothing.
• String-dispatched calls. SendMessage, BroadcastMessage, Invoke, InvokeRepeating, and AnimationEvent all call methods by string name.
• Lifecycle & attribute hooks. Unity finds Awake, Start, Update, OnEnable, etc. by name via reflection; it also scans for [RuntimeInitializeOnLoadMethod], [MenuItem], and similar. Magic methods are usually on a built-in keep list, but custom reflection is not.
• Addressables / asset bundles. Anything you load by type name or by string address at runtime.

A concrete example

Here is a perfectly normal component that renaming would wreck in three different ways:

using UnityEngine;
using UnityEngine.Events;

public class TurretController : MonoBehaviour   // (1) type name is in every scene/prefab using it
{
    [SerializeField] private float fireRate = 0.5f;   // (2) field name is saved in the asset
    [SerializeField] private UnityEvent onFire;        // (3) persistent listeners store a method name

    // Called by name from an AnimationEvent on the fire clip:
    public void SpawnProjectile() { /* ... */ }         // (4) resolved by string, not a direct call
}

If Nebula renames TurretController → a, fireRate → b, and SpawnProjectile → c, then every turret prefab loses its fire-rate value, every scene loses its turret components, and the fire animation stops spawning projectiles — with no compiler error, because none of these bindings are checked at compile time.

The keep-rules that fix it

The goal is not "exclude MonoBehaviours from obfuscation." That would leave most of your code in the clear. The goal is to keep only the names Unity binds to, and obfuscate everything behind them — method bodies, private helpers, algorithms, and string literals.

Nebula expresses this through its keep-list / rename-exclusion rules (the same mechanism covered in keep-lists and rename exclusions). A practical Unity rule set keeps:

• the names of all types deriving from UnityEngine.MonoBehaviour and UnityEngine.ScriptableObject;
• all serialized members on those types (public fields and [SerializeField] fields, and [field: SerializeField] auto-properties);
• any method targeted by a UnityEvent or called via SendMessage/Invoke/AnimationEvent.

Expressed against members, that is "keep the name of any field marked [SerializeField] or public on a UnityEngine.Object subclass, and keep the type name of any MonoBehaviour/ScriptableObject subclass." Method bodies are never affected by name-keep rules, so control-flow flattening and string encryption still apply to SpawnProjectile even though its name is preserved — the logic is protected, only the identifier survives.

Everything else — your pure C# domain logic, networking, save-game format, anti-cheat, and all the string literals in them — gets the full treatment.

Fitting it into the build

Keep obfuscation out of the editor and off developer machines; run it on the artifact. For the Mono backend, add a post-build step (a BuildPipeline post-process or a CI stage) that obfuscates Assembly-CSharp.dll and your other game assemblies in the player's Managed directory, then repackages. For IL2CPP, obfuscate the managed assemblies before the IL2CPP conversion so the generated C++ and global-metadata.dat inherit renamed symbols and encrypted strings. Running protection in CI (see obfuscating on the build server only) means your team keeps debugging clean, readable code and only shipped builds are hardened.

Doing this with Nebula

Nebula obfuscates the managed assemblies a Unity game is built from — renaming, control-flow flattening, and string encryption — with a keep-list model precise enough to preserve exactly the serialized fields, component type names, and event-target methods Unity binds by name, while still hardening every method body behind them. It runs as a post-build or CI step, so your editor stays fast and only the shipped player is protected. Nebula Pro adds code virtualization for the handful of routines that matter most — license checks, anti-cheat, purchase validation.

Start with the free edition to harden your first build, or see the plans when you are ready for virtualization.

The fingerprint: FSharp.Core and CompilationMapping

Two things immediately mark an assembly as F#-origin. First, a reference to FSharp.Core.dll, the runtime every F# program depends on. Second, the [CompilationMapping] attribute sprinkled across types and members. That attribute carries a SourceConstructFlags enum value — Module, SumType, RecordType, UnionCase, Field, Value, and friends — that records what the element was in F# source. A C# decompiler prints these attributes as-is, so they double as a legend: a type tagged SourceConstructFlags.SumType is a discriminated union, one tagged Module is an F# module, and so on.

A worked example

Take a small, idiomatic piece of F#:

type Shape =
    | Circle of radius: float
    | Rectangle of width: float * height: float

type Point = { X: float; Y: float }

module Geometry =
    let area shape =
        match shape with
        | Circle r -> System.Math.PI * r * r
        | Rectangle (w, h) -> w * h

Decompiled to C#, Glass shows roughly this shape (trimmed for clarity):

[CompilationMapping(SourceConstructFlags.SumType)]
public abstract class Shape {
    public abstract int Tag { get; }               // discriminates the cases
    public static class Tags { public const int Circle = 0, Rectangle = 1; }

    [CompilationMapping(SourceConstructFlags.UnionCase, 0)]
    public class Circle : Shape {
        public readonly double radius;
        public override int Tag => 0;
    }
    [CompilationMapping(SourceConstructFlags.UnionCase, 1)]
    public class Rectangle : Shape {
        public readonly double width, height;
        public override int Tag => 1;
    }
}

[CompilationMapping(SourceConstructFlags.RecordType)]
public sealed class Point : IEquatable<Point>, IStructuralEquatable, IComparable<Point>, IComparable {
    public double X { get; }
    public double Y { get; }
    // structural Equals / GetHashCode / CompareTo generated by the F# compiler
}

[CompilationMapping(SourceConstructFlags.Module)]
public static class Geometry {
    public static double area(Shape shape) {
        switch (shape.Tag) {
            case 0: { double r = ((Shape.Circle)shape).radius; return Math.PI * r * r; }
            default: { var rc = (Shape.Rectangle)shape; return rc.width * rc.height; }
        }
    }
}

Every F# construct is now legible as a C# pattern: the union became an abstract base with nested subclasses and an integer Tag; the record became a sealed class carrying the structural Equals/GetHashCode/CompareTo the F# compiler synthesises; the module became a static class; the match became a switch on Tag. Pattern reading, once you know the mapping, is mechanical.

The rest of the vocabulary

• Functions and currying. A let-bound function on a module is a static method. A curried or partially-applied function surfaces as an FSharpFunc<,> value, often with a compiler-generated closure class holding the captured arguments. Higher-order code reads as FSharpFunc invocations rather than lambdas.
• Tuples. F# tuples become System.Tuple<...> (reference tuples) or System.ValueTuple<...> for struct tuples; element names are not preserved at the IL level.
• Options. 'T option is FSharpOption<T> with Some/None; None is the null reference, which is why you sometimes see null checks where the F# said None.
• Entry point. [<EntryPoint>] becomes a static int Main(string[]) tagged with [CompilationMapping(SourceConstructFlags.Value)] plus [EntryPoint]-style marking.
• Nullary union cases (like a None-style tag) are usually exposed as cached singleton instances rather than fresh allocations.

Reading an unfamiliar F# library

This is where a C# decompiler earns its keep: you have a third-party F# assembly with no source, and you need to understand its public surface. In Glass, open the assembly, and the [CompilationMapping] flags immediately tell you which types are unions versus records versus plain classes. Expand a union to see its cases and payloads; expand a module's static class to read the functions; follow a switch (x.Tag) to see how a function branches on a union. Because F# does not strip or mangle names, the identifiers you see are the ones the author wrote — the only translation you are doing in your head is F#-construct → C#-shape, and the CompilationMapping legend hands you that for free.

The honest limit: you are reading the lowered form. Computation expressions have been desugared into Bind/Return calls, inline functions may have vanished into their call sites, and active patterns appear as ordinary method calls returning options. You can always recover the behaviour; you cannot always recover the elegant F# that produced it.

Doing this with Glass

Glass is a free, VS-native .NET decompiler, and because it reconstructs C# from CLI metadata it reads F#-compiled assemblies as readily as C# ones — showing the [CompilationMapping] attributes, the union class hierarchies, and the record equality members so you can navigate an unfamiliar F# library the same way you would any .NET assembly. It is the same workflow as decompiling C# records or iterator state machines; F# just adds one legend to learn.

Grab it from the Glass page — it is free — and open your first F# assembly.

A licensing SDK depends on three things the platform provides: somewhere per-user to keep a small signed file, a stable identity for the machine, and — less obviously — an application that gets relaunched often enough to refresh what it cached. On Windows those are %LocalAppData%, the registry MachineGuid, and the fact that desktop apps start every morning. Off Windows all three are different, and a Keyright integration that was tested on a developer's Windows laptop can quietly do the wrong thing on the Linux box it is deployed to. This post is the Linux and macOS version of the story: where the files go, what the fingerprint is made of, how to give a systemd service a home, and the refresh loop a process that never restarts needs.

Where the files go when there is no AppData

A Keyright client keeps up to three files per product, all rooted on Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData):

{LocalApplicationData}/Keyright/{product}/lease.json     signed activation lease (cached after ActivateAsync)
{LocalApplicationData}/Keyright/{product}/state.json     first-seen / last-seen timestamps (trial clock, clock-tamper)
{LocalApplicationData}/Keyright/{product}/license.json   default location for an offline license file

On Unix, .NET resolves LocalApplicationData the XDG way: $XDG_DATA_HOME if it is set, otherwise $HOME/.local/share. And it does that on macOS too — not ~/Library/Application Support, which is where a Mac user would look. So for a user dana the lease sits at:

Linux   /home/dana/.local/share/Keyright/acme-agent/lease.json
macOS   /Users/dana/.local/share/Keyright/acme-studio/lease.json

Three things follow from "it is under $HOME", and they are the whole first half of this post.

It is per user. Two users on the same machine each have their own cache and each activate once. That is not two seats: both activations fingerprint the same machine and send the same machineId, so the service binds one seat and refreshes it twice — exactly the shared-PC behaviour described in the MSIX post. The cache is per user; the seat was always per machine.

It depends on HOME being real and writable. A systemd unit with ProtectHome=yes sees an empty, read-only /home. A DynamicUser=yes unit runs as a transient UID whose home is /. A hand-made service account is often created with --home /nonexistent or --home /var/empty. In all of those, ~/.local/share/Keyright cannot be created. The SDK does not throw: the lease cache is deliberately best-effort, so a failed write is swallowed, ActivateAsync returns a perfectly valid LicenseInfo, and the service runs licensed — until the next restart, when there is no cached lease and it activates again. Online, that is invisible; it just costs a round-trip. Offline, it is NoLicense and a fail-closed service that worked yesterday.

A sandboxed Mac app has a different HOME. Under App Sandbox, HOME is redirected to the app's container, so ~/.local/share/Keyright/acme-studio/lease.json lands at ~/Library/Containers/com.acme.studio/Data/.local/share/Keyright/acme-studio/lease.json. Everything works — the sandbox is writable, it survives updates, and it is deleted when the user removes the app and its container. It is the macOS counterpart of MSIX write virtualization: the path the SDK logs is not the path the bytes are in. Make it explicit with LeaseCachePath and friends if a support engineer will ever need the file.

What the fingerprint anchors to

The machine fingerprint the SDK sends on activation is a set of salted hashes, KRM1:anchor:soft1:soft2, built from an ordered list of components where index 0 is the anchor that must always match and the rest are soft signals that NodeLockTolerance (default 1) lets drift one at a time. On Windows the anchor is HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid. Off Windows there is no registry, and the SDK reads the platform's equivalent:

• Linux: /etc/machine-id, the 32-hex-character id systemd generates on first boot, with /var/lib/dbus/machine-id as a fallback for systems that only have the D-Bus one. It is world-readable (mode 0444), so a service running as an unprivileged user can read it without any capability — which is why DynamicUser= units fingerprint correctly.
• macOS: the IOPlatformUUID of the IOPlatformExpertDevice entry in the I/O registry, read via ioreg. It is the per-machine id Apple's own services use, and it survives OS upgrades, hostname changes and a user wiping ~/.
• Nothing readable: the SDK generates a random id, persists it at ~/.local/share/Keyright/machine.id, and anchors on that. On Windows and on any normal Linux or Mac install this file never exists; it is the last resort for a container with no machine-id, or a locked-down sandbox that cannot spawn ioreg. Note what it costs: the fallback is per user, so two users on such a machine would be two machines and two seats.

The two soft components are the host name and Environment.OSVersion.Platform plus the major version — Unix:6 on a Linux 6.x kernel, the macOS major on a Mac. The tolerance is what keeps those honest: rename the host and the anchor still matches, one soft component differs, the lease validates. Upgrade a distribution from a 5.x to a 6.x kernel, same thing. Do both in the same week and you have two soft mismatches, which exceeds the default tolerance — the lease reports MachineMismatch and the next ActivateAsync re-binds, idempotently, because the service matches on the anchor. The design is explained in the fingerprint post; the Linux-specific point is just that your "hardware" anchor is a file.

The two machine-id traps

Because the anchor is a file, it can be copied, and it can be missing. Each is a different failure.

Copied: the golden image. Build a VM image, install your agent, snapshot it, provision forty hosts from the snapshot. Unless something cleared /etc/machine-id before the snapshot was sealed, all forty boot with the same id, hash to the same anchor, and present the same machineId. Keyright does what it does for a machine it has already seen: the first host activates and binds a seat, the other thirty-nine refresh it. The dashboard shows one device. You sold one seat and are running forty — this is the trap that fails open, which is the kind you do not get a ticket about. The fix lives in the image, not the SDK: truncate -s0 /etc/machine-id before sealing (an empty file tells systemd to generate a fresh id on first boot), or run systemd-machine-id-setup from first-boot provisioning. cloud-init does this; templates built by hand often do not. The cloned-VM post covers detecting the duplicates from the service side when you cannot control the images. If you want many hosts to count as one deployment, say so with a custom IMachineComponents, as in the containers post — a decision in code, not an accident in a template.

Missing: the container. Minimal container images ship an empty /etc/machine-id or none at all. The SDK reads an empty string, treats it as unreadable, and falls through to the persisted random fallback — which lives in the container's writable layer and is gone with the container. Every restart is a new machine and a new seat. That is the same problem the containers post solves by overriding the identity source, and nothing on this page changes it; what this page adds is why the default behaves that way: the file is empty.

A systemd service: giving the SDK a home

Now the half of the post that matters for most Linux deployments: a licensed .NET worker running under systemd. A unit written with modern hardening looks like this, and every line that matters to licensing is annotated:

# /etc/systemd/system/acme-agent.service
[Unit]
Description=Acme Agent
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/opt/acme/acme-agent
User=acme
Group=acme
Restart=on-failure

# Hardening: the filesystem is read-only and /home is empty. $HOME/.local/share is not writable.
ProtectSystem=strict
ProtectHome=yes

# The one directory this service may write. systemd creates /var/lib/acme-agent, chowns it to acme,
# and exports it as $STATE_DIRECTORY. This is where the lease, local state and offline license go.
StateDirectory=acme-agent
StateDirectoryMode=0700

# Site/OEM deployments: hand the service a signed license file nobody else on the host can read.
# Exposed at $CREDENTIALS_DIRECTORY/license.json, readable by this service only, not in the environment.
LoadCredential=license.json:/etc/acme/license.json

# Key-activated deployments instead: the license key, same mechanism. One or the other.
# LoadCredential=license-key:/etc/acme/license.key

[Install]
WantedBy=multi-user.target

StateDirectory= is the answer to the HOME problem. It gives the service a directory that exists, is owned by the service user, survives restarts and upgrades, and is exempt from ProtectSystem=strict. StateDirectoryMode=0700 keeps other users on the host out of it. LoadCredential= is the answer to "where does the license come from on a machine with no human": systemd copies the file into a per-service tmpfs and tells the process where with CREDENTIALS_DIRECTORY. Unlike an Environment= line, the content never appears in systemctl show, /proc/<pid>/environ, or a child process.

The client reads both:

using Keyright.Client;

static KeyrightClient CreateLicenseClient()
{
    var options = new KeyrightOptions
    {
        Product         = "acme-agent",
        PublicKeyBase64 = AcmeKeys.LicensePublicKey,       // public key only; safe to ship in the binary
        ServiceUrl      = "https://licensing.acme.example",
    };

    // systemd StateDirectory= — may list several directories, colon-separated; the first is ours.
    string? state = Environment.GetEnvironmentVariable("STATE_DIRECTORY")?.Split(':')[0];
    if (!string.IsNullOrEmpty(state))
    {
        string root = Path.Combine(state, "keyright");
        options.LeaseCachePath     = Path.Combine(root, "lease.json");
        options.LocalStatePath     = Path.Combine(root, "state.json");
        options.DefaultLicensePath = Path.Combine(root, "license.json");
    }

    // systemd LoadCredential= — a site/OEM license file. Explicit path = authoritative, no fall-through.
    string? creds = Environment.GetEnvironmentVariable("CREDENTIALS_DIRECTORY");
    if (creds is not null && File.Exists(Path.Combine(creds, "license.json")))
        options.LicenseFilePath = Path.Combine(creds, "license.json");

    return KeyrightClient.Initialize(options);
}

Outside systemd — a developer running the binary from a shell — neither variable is set, the SDK defaults to ~/.local/share, and the same code is right. There is no "am I a service" flag to get wrong.

The LicenseFilePath branch is the same explicit-source rule as everywhere else in the SDK: when it is set, the ambient sources (KEYRIGHT_LICENSE, the config path, the default path, the cached lease) are not consulted, and a missing or invalid file is NoLicense or SignatureInvalid rather than a fall-through. For a deployment where licensing is an operator decision, that is what you want. Note that the license file is not a secret in the way a password is — it is a signed document bound to this machine's fingerprint, useless anywhere else — but it does carry the license key and the licensee's name, and LoadCredential= is simply the cleanest way to put a file in front of exactly one process on a Linux host.

The macOS daemon story is the same with different names. A LaunchDaemon running as a dedicated _acme user has a home of /var/empty, which is read-only; HOME for a root daemon is /var/root. Put the three paths under /Library/Application Support/Acme/keyright/ with mode 0700, owned by the daemon's user, and the SDK is happy. launchd has no LoadCredential=; a 0600 file under /Library/Application Support/Acme/ referenced via LicenseFilePath is the equivalent.

The daemon that never relaunches

Here is the difference that has nothing to do with file paths and bites hardest.

An activation lease is a short-lived signed token — 14 days by default — and the SDK's recommended refresh pattern is call ActivateAsync at startup. For a desktop app that is a complete solution: the user launches it most days, each launch refreshes the lease when online, and a laptop that stays offline for two weeks is the edge case the window was sized for. A service inverts the frequencies. It launches once, after a deploy, and then runs for months. Nothing calls ActivateAsync again, the lease reaches leaseExpiresUtc, and the next Validate() — in a request handler, on day 15 — returns Expired with the message "reconnect to re-validate". The process is up, the network is fine, the license is paid for, and the service has failed closed to Free because nobody relaunched it.

The fix is a refresh loop inside the service. ActivateAsync is safe to call repeatedly: re-activating a machine the service has already seen is idempotent — same seat, fresh lease — and if the licensing service is unreachable the SDK falls back to the still-valid cached lease rather than discarding it, so the loop can only ever extend the window, never shorten it.

using Keyright.Client;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

/// <summary>Keeps the activation lease fresh in a process that may run for months without restarting.</summary>
public sealed class LeaseRefresher(KeyrightClient license, ILogger<LeaseRefresher> log) : BackgroundService
{
    private static readonly TimeSpan Interval = TimeSpan.FromHours(6);

    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        // Key-activated deployment: the key arrives as a systemd credential, never in the environment.
        string? creds = Environment.GetEnvironmentVariable("CREDENTIALS_DIRECTORY");
        string? keyPath = creds is null ? null : Path.Combine(creds, "license-key");
        if (keyPath is null || !File.Exists(keyPath))
        {
            log.LogInformation("No license key credential; running from a license file, nothing to refresh.");
            return;                                   // site/OEM file deployments: the file IS the license
        }
        string key = (await File.ReadAllTextAsync(keyPath, ct)).Trim();

        using var timer = new PeriodicTimer(Interval);
        do
        {
            LicenseInfo info = await license.ActivateAsync(key, ct);   // idempotent: same machine, same seat, new lease
            if (info.IsValid)
                log.LogInformation("License lease refreshed; {Status}, {DaysRemaining} days remaining.", info.Status, info.DaysRemaining);
            else
                log.LogWarning("License refresh did not yield a valid lease: {Status} — {Message}", info.Status, info.Message);
        }
        while (await timer.WaitForNextTickAsync(ct));
    }
}

Register it with services.AddHostedService<LeaseRefresher>() next to the singleton client. Six hours is a reasonable interval: the lease is then always within six hours of fresh, so the 14-day window becomes fourteen days of tolerated outage of your licensing service rather than fourteen days of uptime. The first iteration runs immediately, which doubles as the startup activation. Log the status, never the key — the structured-logging post explains why info.Status and info.DaysRemaining are the right fields.

Two things the loop does not do, on purpose. It does not restart the process when the status goes bad: Validate() already fails closed on its own, and the health-check post shows how to surface a degraded license to the orchestrator without a crash loop. And it does not run for file-based deployments: a signed site license file has its own expiry and nothing to refresh, so the loop checks for the key credential and steps out.

The file mode the lease deserves

On Windows the lease lives under a profile only its user can read. On Linux, File.WriteAllText creates files at 0666 & ~umask, which with the usual 022 is 0644 — readable by every account on the host. The lease is not dangerous to read: it is signed, so editing it yields SignatureInvalid, and it is bound to this machine's fingerprint, so copying it elsewhere yields MachineMismatch. But it does carry the license key, and a key lets its holder attempt an activation against your seat limit from any machine. On a single-user laptop that is nothing; on a shared build host or a jump box it is a key leak via ls.

StateDirectoryMode=0700 already closes this for a systemd service. For everything else, tighten the directory before the SDK writes into it — KeyrightClient.Initialize does not create the directories, the first write does, so creating them yourself first wins:

using System.IO;

static void SecureLicenseDirectory(string leaseCachePath)
{
    if (OperatingSystem.IsWindows()) return;                  // ACLs on the profile already do this
    string dir = Path.GetDirectoryName(leaseCachePath)!;
    Directory.CreateDirectory(dir, UnixFileMode.UserRead | UnixFileMode.UserWrite | UnixFileMode.UserExecute);   // 0700
    if (File.Exists(leaseCachePath))
        File.SetUnixFileMode(leaseCachePath, UnixFileMode.UserRead | UnixFileMode.UserWrite);                   // 0600
}

Directory.CreateDirectory(path, UnixFileMode) and File.SetUnixFileMode are .NET 7+ APIs; on older targets a chmod P/Invoke does the same. A 0700 directory is enough on its own — a 0644 file inside a directory nobody else can traverse is unreadable — so the file-mode call is belt and braces for a lease that already existed before you tightened the directory.

Print what the gate will see

Every post in this series ends up recommending the same diagnostic, because it is the thing that turns a ticket into one line: a --license-info flag that prints the paths and the fingerprint from the code path the gate uses, so what it shows is what the SDK does.

using Keyright.Client;
using Keyright.NodeLock;

// acme-agent --license-info
static void PrintLicenseInfo(KeyrightClient license)
{
    var fp = MachineFingerprint.Current();
    LicenseInfo info = license.Validate(out LicenseSourceKind source);

    Console.WriteLine($"Machine id    : {fp.ToBoundString()}");              // what the dashboard's Devices panel lists
    Console.WriteLine($"Display id    : {fp.DisplayId}");                    // short form for a support conversation
    Console.WriteLine($"Anchor source : {AnchorSource()}");
    Console.WriteLine($"Lease cache   : {license.LeaseCachePath}  (exists: {File.Exists(license.LeaseCachePath)})");
    Console.WriteLine($"Local state   : {license.LocalStatePath}");
    Console.WriteLine($"License file  : {license.DefaultPath}");
    Console.WriteLine($"Status        : {info.Status} via {source}  — {info.Message}");
}

static string AnchorSource()
{
    if (OperatingSystem.IsWindows()) return "registry MachineGuid";
    if (OperatingSystem.IsMacOS())   return "IOPlatformUUID";
    foreach (var p in new[] { "/etc/machine-id", "/var/lib/dbus/machine-id" })
        if (File.Exists(p) && File.ReadAllText(p).Trim().Length > 0) return p;
    return "persisted fallback (~/.local/share/Keyright/machine.id) — per user, not per machine";
}

The Anchor source line is the one that catches the golden-image and container traps before they reach production: /etc/machine-id on a real host, the fallback in a bare container. The via {source} suffix — Lease, ExplicitFile, EnvironmentVariable, DefaultPath — tells you which of the sources won, which is the first question when a service that should be reading a credential file is somehow activating online instead.

Verify it

The whole argument is testable on one host in a few minutes. The important trick is in step 2: run the diagnostic inside the unit's environment, not from your own shell as the service user — sudo -u acme gives you the user but not STATE_DIRECTORY or the credentials, and the paths it prints are the wrong ones.

# 1. The anchor. Non-empty, and different on every host built from the same image.
cat /etc/machine-id
#    → e.g. 8c3f1a2b...   (empty? the image was not cleared: truncate -s0 /etc/machine-id and reboot)

# 2. Activate once, as the unit would. systemd-run builds a transient unit with the same properties.
sudo systemd-run --pty --wait -p User=acme -p StateDirectory=acme-agent \
    -p LoadCredential=license-key:/etc/acme/license.key \
    /opt/acme/acme-agent license activate
sudo systemd-run --pty --wait -p User=acme -p StateDirectory=acme-agent \
    /opt/acme/acme-agent --license-info
#    → Lease cache : /var/lib/acme-agent/keyright/lease.json (exists: True), Status: Valid via Lease
#    Dashboard: the license shows 1 device, the KRM1:… machine id from the line above.

# 3. Owner and mode: the service user, nobody else.
sudo ls -la /var/lib/acme-agent/keyright/
#    drwx------ acme acme .     -rw------- acme acme lease.json

# 4. Restart: the lease survives, no second seat. Dashboard: still 1 device.
sudo systemctl restart acme-agent && sudo journalctl -u acme-agent -n 3
#    → "License lease refreshed; Valid, 364 days remaining."

# 5. The loop. Block the licensing service for an hour and watch the warning line; unblock and watch it recover.
#    Then confirm with the dashboard's last-seen time that the lease is refreshed every 6 hours without a restart.

Add the one that matters for a fleet: provision a second host from the same image and run step 1 on both. If the two ids match, stop and fix the image; nothing after that is meaningful until they differ.

What to take away

Keyright treats Linux and macOS as first-class, and the SDK calls are identical, but the platform underneath a licensing SDK is not. The data folder is ~/.local/share on both and is per user, so a hardened service needs an explicit home — StateDirectory= gives it one, and LoadCredential= hands it a license file or key without a single secret in the environment. The fingerprint anchors on /etc/machine-id or the IOPlatformUUID instead of a registry value, which is just as stable — as long as your images do not ship one id to forty hosts, and your containers do not ship none. And the lease is refreshed by relaunching, which a daemon never does, so give it a loop. Make the paths explicit, print them and the anchor source in a diagnostic, and the day a support engineer asks why a licensed service went Free on day 15, the answer is already in the log.

The method: a static method wearing one attribute

Start with the definition. A trivial extension on string:

public static class StringExtensions
{
    public static int WordCount(this string s)
        => s.Split((char[]?)null, StringSplitOptions.RemoveEmptyEntries).Length;
}

Compile it and look at what this became. It is gone from the parameter — s is an ordinary string parameter — and in its place are two [Extension] attributes, one on the method and one on the class:

.class public abstract sealed auto ansi beforefieldinit StringExtensions
    extends [System.Runtime]System.Object
{
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.ExtensionAttribute::.ctor() = ( 01 00 00 00 )

    .method public hidebysig static int32 WordCount(string s) cil managed
    {
        .custom instance void [System.Runtime]System.Runtime.CompilerServices.ExtensionAttribute::.ctor() = ( 01 00 00 00 )
        // ... ldarg.0; call String::Split(...); ldlen; ...
    }
}

That is the entire difference between an extension method and a static helper. The method is public static, the first parameter is a normal parameter of a normal type, there is no special calling convention. The attribute on the method is what lets a decompiler render the first parameter as this s; the attribute on the class is what tells a consuming compiler the class is worth scanning for extensions in the first place. Strip both and you have StringExtensions.WordCount(x) and nothing else; add them and x.WordCount() becomes legal too.

The call site: byte-identical to a static call

Now call it two ways and compare the IL:

int a = "the quick brown fox".WordCount();         // fluent
int b = StringExtensions.WordCount("the quick brown fox");   // explicit static

Both compile to the same three instructions — load the string, call the static method, store:

ldstr      "the quick brown fox"
call       int32 StringExtensions::WordCount(string)
stloc.0

There is no second form. The CLR has no concept of an extension call, so the this is resolved and discarded at compile time, and the call site keeps no record of which syntax the author used. This is the crux of the whole problem: a decompiler cannot learn from the call whether the source was fluent. It can only look at the method being called, see [Extension] on it, and choose to print the call as a member access on its first argument — "the quick brown fox".WordCount() — because that is the idiomatic form and almost always the original. Both renderings are legal and compile identically, so the choice is readability, not correctness. Glass.NET makes it, which is why the output reads like C# a human wrote rather than like a macro expansion.

The chain: one rule, applied outward

The reason the dot matters is LINQ, where reading the IL literally produces something correct and unreadable. Take a pipeline:

var top = people.Where(p => p.Active).Select(p => p.Name).OrderBy(n => n).ToList();

Every one of Where, Select, OrderBy, ToList is a static extension method on Enumerable, so the IL is a nest — the outermost call emitted last, each result feeding the next call's first argument:

call ...ToList( call ...OrderBy( call ...Select( call ...Where(people, <lambda>), <lambda>), <lambda>))

Read that literally and you get Enumerable.ToList(Enumerable.OrderBy(Enumerable.Select(Enumerable.Where(people, …), …), …)) — a four-deep nest you have to read inside-out. Because each method carries [Extension], Glass.NET applies the one rule repeatedly: print each static call as a member access on its first argument. The innermost Where(people, …) becomes people.Where(…); that whole expression is the first argument of Select, so it reads people.Where(…).Select(…); and so on outward until the nest has unrolled into the original chain. The precedence has to be exact — a lambda body with a conditional, or a cast inserted mid-chain, needs the right parentheses or the meaning shifts — but the shape falls straight out of applying "member access on the first argument" from the innermost call out.

Why the attribute, not the call, is the source of truth

It is worth being precise about what Glass trusts. The call site is ambiguous by construction — it is the same IL for both syntaxes — so it carries no signal. The method's metadata is unambiguous: [Extension] is present or it is not. So Glass keys its decision on the method:

• Target method has [Extension] → render the call as arg0.Method(rest).
• Target method does not → render it as Type.Method(args).

This also handles the awkward real cases correctly. If someone deliberately wrote Enumerable.Where(list, p) in explicit static form, Glass still prints list.Where(p) — which is fine, because it compiles back to the same IL and reads better. And a generic extension method like Select<TSource, TResult> carries the attribute just the same; Glass renders src.Select(f) and lets C#'s type inference recover the type arguments at recompile, only spelling them out when inference cannot. The attribute is a reliable, local signal on the method being called, which is exactly what a decompiler wants — no global analysis, no guessing from surrounding using directives that are not even in the IL.

The C# 14 extension-block shape

Newer code may use extension blocks, which group members under one receiver and, for the first time, allow extension properties:

public static class StringExtensions
{
    extension(string s)
    {
        public int  WordCount => s.Split((char[]?)null, StringSplitOptions.RemoveEmptyEntries).Length;
        public bool IsBlank()  => string.IsNullOrWhiteSpace(s);
    }
}

This is new syntax, not new runtime. The members still lower to static methods on the enclosing static class, marked so a consumer's compiler can route name.WordCount and name.IsBlank() to them — an extension property becomes a static accessor method, an extension method a static method with the receiver as its first parameter, plus grouping metadata tying several members to one receiver. A decompiler reading such an assembly sees static methods with marker metadata and a receiver parameter, much as before. Glass.NET reconstructs them as extensions; a plain extension method can be shown either as the classic this-parameter form or inside a block, but an extension property has no classic spelling, so it comes back as a block. The semantics are identical either way, because the lowered static methods are identical — the skin changed, not the IL.

The takeaway

An extension method leaves exactly one trace in metadata: the [Extension] attribute, on the method so the first parameter can wear this, and on the class so a compiler knows to look there. The call site keeps no trace at all — text.WordCount() and StringExtensions.WordCount(text) are byte-identical IL — so a decompiler cannot learn the fluent form from the call and must read it off the method instead. Glass.NET does exactly that: it prints any static call whose target carries [Extension] as a member access on the first argument, applies that one rule from the innermost call outward to unroll a LINQ nest back into a chain, and recognises the C# 14 extension-block lowering as the same static methods under a newer syntax. The result reads like the pipeline that was written, not the nest the compiler left — because the decompiler trusted the attribute, which is the only thing that survived.

That matters to licensing more than to almost anything else an app writes, because a licensing SDK keeps exactly the kind of small, important files whose location and lifetime you need to understand: a signed activation lease that lets the app run offline, a local timestamp that stops a trial from being restarted, a record of the last time the clock was seen. This post looks at what the Keyright SDK writes, where those bytes actually land inside a packaged app, what an uninstall does to them, and how to make the whole thing explicit instead of letting a file-system filter decide.

What the SDK writes, and where it thinks it is writing it

A Keyright client is initialised once with the product name and the embedded public key, and from then on it keeps up to three files for that product:

{LocalApplicationData}\Keyright\{product}\lease.json     signed activation lease (cached after ActivateAsync)
{LocalApplicationData}\Keyright\{product}\state.json     first-seen / last-seen timestamps (trial clock, clock-tamper)
{LocalApplicationData}\Keyright\{product}\license.json   default location for an offline license file

There is a fourth, {LocalApplicationData}\Keyright\machine.id, which only exists as a last resort: the machine fingerprint is anchored on the OS machine GUID, and the random persisted id is written only if that GUID cannot be read at all. On a Windows machine it normally never exists.

Every one of those paths comes from Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), and that call returns the same thing inside an MSIX package as outside it: C:\Users\dana\AppData\Local. The SDK, your app, and anything that logs client.LeaseCachePath will all report that path. It is just not where the file is.

Where it actually goes

A desktop app packaged with the runFullTrust capability runs inside a lightweight container, and one of the things that container does is file-system write virtualization for the user's AppData folders. When the process writes to %LocalAppData%\Keyright\acme-studio\lease.json, a filter driver redirects the write to

%LocalAppData%\Packages\<PackageFamilyName>\LocalCache\Local\Keyright\acme-studio\lease.json

The redirect is invisible to the process. File.WriteAllText succeeds, File.Exists returns true, Directory.EnumerateFiles lists the file — all against the virtual path, which the container presents as a merged view: reads check the package's LocalCache first and fall through to the real %LocalAppData% if the file is not there, and writes always land in LocalCache (copy-on-write if the real file existed). Open File Explorer at C:\Users\dana\AppData\Local\Keyright and there is nothing in it; the files are two levels down inside Packages.

Three consequences fall out of that, and they are the whole reason this post exists.

The lease survives package updates. LocalCache belongs to the package family, not the package version. When winget upgrade installs 2.4 over 2.3, the folder is untouched, the cached lease is still there, and the app starts licensed. Calling ActivateAsync at startup — the pattern the SDK recommends anyway — refreshes it silently when the machine is online.

The lease does not survive uninstall. Removing the package removes %LocalAppData%\Packages\<family> with everything in it. lease.json, state.json, a license.json the user pasted into the default location: gone. This is the behaviour an MSI never had, and it is the one that surprises people.

The machine fingerprint is unaffected by either. The anchor the fingerprint is built on is HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid, which belongs to the Windows installation, sits outside the package, and is read — not written — by the SDK. HKLM reads are not virtualized; the package's virtual registry overlays only the keys the package itself carries. The machine name and OS version, the two softer signals, are likewise not package state. So the fingerprint the app presents to the licensing service is byte-for-byte the same before an uninstall and after a reinstall.

What uninstall and reinstall do to the seat

Put the last two consequences together and the seat accounting follows.

The seat is not a file on the machine. It is a record on the licensing service that says this license, this machineId. When the customer uninstalls the package, nothing tells the service anything — the lease cache is deleted locally, the seat stays bound. When they reinstall and enter their key again, the app fingerprints the same machine, sends the same machineId, and the service does what it does for any machine it has already seen: refreshes the existing activation and returns a fresh lease. Re-activation on the same machine is idempotent. No second seat is consumed, the dashboard still shows one device, and the customer never knew there was a question.

The case that does go wrong is the one where the customer uninstalled because they were leaving the machine. They retire a laptop, set up a new one, install the package, enter the key — and the new laptop is a new fingerprint. If the license had one seat, the service answers LicenseStatus.SeatLimit: all seats in use, free one first. The old laptop cannot free it; the app is no longer on it.

Two things handle that, and neither is specific to MSIX, but MSIX makes them matter more because uninstalling is so much cleaner than it used to be:

• Give the user a deactivate in the app. DeactivateAsync(key) releases this machine's seat on the service and clears the local lease. Put it where a user who is about to retire a machine will find it — a "Move this license to another computer" item next to "Enter license key" — and say what it does. A packaged app has no uninstall hook you can run code from, so the deactivate has to happen before the uninstall, which means the UI has to invite it.
• Free dead machines vendor-side. The license's Devices panel in the Keyright dashboard lists every bound machine with a Free seat action, and POST /admin/licenses/{id}/free-seat does the same from a support script. The customer's next activation takes the freed seat.

What you should not do is try to reconstruct a deactivation from the uninstall. There is no package-level uninstall script in MSIX by design, and a licensing call that runs during uninstall would be the least reliable network request in your product.

Know you are packaged, and say where the files go

Relying on the redirect is fine until a support engineer asks for lease.json and spends twenty minutes in the wrong folder. The cleaner approach is to detect package identity at startup and hand the SDK explicit paths inside the package's own data folder, so the path the app logs is the path the bytes are in.

Package identity comes from GetCurrentPackageFullName in kernel32. Outside a package it returns APPMODEL_ERROR_NO_PACKAGE (15700); inside one it returns the package full name.

using System.Runtime.InteropServices;
using System.Text;

public static class PackageContext
{
    private const int APPMODEL_ERROR_NO_PACKAGE = 15700;

    [DllImport("kernel32.dll", CharSet = CharSet.Unicode, ExactSpelling = true)]
    private static extern int GetCurrentPackageFullName(ref int length, StringBuilder? fullName);

    /// <summary>The package full name when running packaged; null when unpackaged or not on Windows.</summary>
    public static string? FullName { get; } = Resolve();

    public static bool IsPackaged => FullName is not null;

    private static string? Resolve()
    {
        if (!OperatingSystem.IsWindowsVersionAtLeast(10)) return null;
        int length = 0;
        int rc = GetCurrentPackageFullName(ref length, null);     // ERROR_INSUFFICIENT_BUFFER when packaged
        if (rc == APPMODEL_ERROR_NO_PACKAGE) return null;
        var sb = new StringBuilder(length);
        rc = GetCurrentPackageFullName(ref length, sb);
        return rc == 0 ? sb.ToString() : null;
    }
}

With that, the client is built in one of two shapes. Unpackaged, the SDK defaults are right. Packaged, point every path at ApplicationData.Current.LocalFolder — the package's LocalState folder, which is the documented home for a packaged app's data, is never virtualized because it is already package-private, survives updates, and is deleted on uninstall exactly like LocalCache:

using Keyright;
using Windows.Storage;                       // needs a Windows TFM, e.g. net8.0-windows10.0.19041.0

static KeyrightClient CreateLicenseClient()
{
    var options = new KeyrightOptions
    {
        Product         = "acme-studio",
        PublicKeyBase64 = AcmeKeys.LicensePublicKey,       // public key only; safe to ship in the package
        ServiceUrl      = "https://licensing.acme.example",
    };

    if (PackageContext.IsPackaged)
    {
        // Explicit, package-private, visible in Explorer at the path we log.
        string root = Path.Combine(ApplicationData.Current.LocalFolder.Path, "keyright");
        options.LeaseCachePath     = Path.Combine(root, "lease.json");
        options.LocalStatePath     = Path.Combine(root, "state.json");
        options.DefaultLicensePath = Path.Combine(root, "license.json");
    }

    return KeyrightClient.Initialize(options);
}

The SDK creates the directory on first write, so there is nothing else to set up. If your project targets plain net8.0-windows without a Windows SDK version, GetCurrentPackageFamilyName from the same DLL gives you the family name, and LocalState lives at %LocalAppData%\Packages\<family>\LocalState.

Then add the diagnostic that turns the support ticket into a one-liner — the same idea as the --site-info command in the site-license post: print what the gate will see, from the code path the gate uses.

// acme-studio --license-info
Console.WriteLine($"Packaged     : {(PackageContext.IsPackaged ? PackageContext.FullName : "no")}");
Console.WriteLine($"Lease cache  : {License.LeaseCachePath}  (exists: {File.Exists(License.LeaseCachePath)})");
Console.WriteLine($"Local state  : {License.LocalStatePath}");
Console.WriteLine($"License file : {License.DefaultPath}");
Console.WriteLine($"Machine id   : {MachineFingerprint.Current().ToBoundString()}");

The machine id line is the one a support engineer needs to match a device in the dashboard, and it prints the same value packaged or not — which is the point.

A shared PC: two users, one seat

MSIX packages are registered per user. On a shared workstation where Dana and Sam both use the app, each has their own Packages\<family> folder, their own LocalCache, their own lease. Each of them has to activate once. That sounds like two seats and it is not: both activations fingerprint the same machine, send the same machineId, and the service binds one seat and refreshes it twice. The per-user cache is a convenience for the lease; the seat was always per machine.

The one thing to avoid is "fixing" this by moving the lease to %ProgramData% so both users share one file. Writes outside the user's AppData are not virtualized, so it would work, but you then own the ACLs — a folder Dana's installer created is not writable by Sam — for no gain, because the seat count is already right.

Shipping a license inside the package

Not every license is activated by the user. Site licenses, OEM builds and air-gapped deployments ship a signed license file with the product, and a package is the right vehicle for it: the install directory under C:\Program Files\WindowsApps\<PackageFullName> is read-only, signed as part of the package, and AppContext.BaseDirectory resolves there at runtime.

<!-- Acme.Studio.csproj: bundle the signed site license as content -->
<ItemGroup>
  <Content Include="licenses\license.json" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

// Site/OEM build: the license is part of the package. Explicit file path = authoritative.
options.LicenseFilePath = Path.Combine(AppContext.BaseDirectory, "licenses", "license.json");

LicenseFilePath is an explicit source in the SDK's precedence rules: when it is set, the ambient sources — the KEYRIGHT_LICENSE environment variable, a config path, the default AppData path — are not consulted, and a missing or invalid file is a NoLicense or SignatureInvalid result rather than a fall-through. That is what you want for a build whose licensing is a deployment decision rather than a user one. The two signatures do different jobs: the package signature says the bytes came from you; the license signature, verified against the public key you embedded, says the claims came from you. The read-only install directory keeps anyone from editing the file in place, but that is a convenience — it is the signature that makes the edit pointless.

For a mixed product — most customers activate with a key, enterprise customers get a site file — leave LicenseFilePath unset in the retail package and let the site customers drop the file at DefaultPath, which under the explicit-paths setup above is a stable, documentable location inside LocalState.

The trial that lives in a file

One Keyright behaviour deserves a specific MSIX note. A trial activated online carries an expiry the service wrote at issuance; the clock is on the service and an uninstall changes nothing. A trial shipped as an offline signed license file with trialDays and no baked-in expiry is timed from first use on this machine, and the first-seen timestamp that anchors it is kept in state.json. Under a packaged app that file lives in the package's data folder, and uninstall deletes it — so an uninstall/reinstall cycle restarts the local clock.

The fix is to not keep the trial clock in package-scoped storage. Either issue trials online so the expiry is fixed by the service, or point LocalStatePath at a per-user location that is not inside Packages\<family> — which, in a virtualized app, means disabling write virtualization for that write or choosing a non-AppData path. The post on trials that don't leak covers the general shape; the MSIX-specific lesson is just that "the user's AppData" is not where the file is.

When to turn virtualization off

You can tell Windows not to redirect AppData writes for your package:

<Package
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:desktop6="http://schemas.microsoft.com/appx/manifest/desktop/windows10/6"
  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
  IgnorableNamespaces="desktop6 rescap">

  <Properties>
    <desktop6:FileSystemWriteVirtualization>disabled</desktop6:FileSystemWriteVirtualization>
    <desktop6:RegistryWriteVirtualization>disabled</desktop6:RegistryWriteVirtualization>
  </Properties>

  <Capabilities>
    <rescap:Capability Name="runFullTrust" />
    <rescap:Capability Name="unvirtualizedResources" />
  </Capabilities>
</Package>

With that in place, %LocalAppData%\Keyright\acme-studio\lease.json is a real file at the real path, it survives uninstall, and an unpackaged build of the same product reads the same cache. That last point is the only strong reason to do it: if you ship both an MSI and an MSIX edition, or a support tool that inspects the licensing files directly, a shared unvirtualized location keeps them consistent. Otherwise the default is better — a cache that dies with the package is exactly the right lifetime for a cache, the seat survives it anyway, and unvirtualizedResources is a restricted capability that the Store will ask you to justify (sideloaded and winget packages can declare it without ceremony).

Verify it

The whole argument above is testable on one machine in a few minutes, and it is worth doing once before you ship the first packaged build.

# 1. Install the package and activate from inside the app. Then find the cache.
$pkg = Get-AppxPackage -Name Acme.Studio
Get-ChildItem "$env:LOCALAPPDATA\Packages\$($pkg.PackageFamilyName)\LocalState\keyright"
#    → lease.json, state.json. Dashboard: the license shows 1 device, your machine id.

# 2. Upgrade in place; the files and the activation must survive.
winget upgrade Acme.Studio
Get-ChildItem "$env:LOCALAPPDATA\Packages\$($pkg.PackageFamilyName)\LocalState\keyright"

# 3. Uninstall; the folder is gone. Dashboard: still 1 device — nothing told it.
Remove-AppxPackage -Package $pkg.PackageFullName
Test-Path "$env:LOCALAPPDATA\Packages\$($pkg.PackageFamilyName)"      # False

# 4. Reinstall and activate again. Dashboard: still 1 device, same machine id, lease refreshed.

Add one more step if you offer an in-app deactivate: run it before step 3 and confirm the dashboard shows 0 devices before the uninstall, then 1 again after step 4. (For debugging only, Remove-AppxPackage -PreserveApplicationData keeps the data folder through an uninstall, which is handy when you want to test the update path without re-activating.)

And the test that catches the trial case, if you ship offline trial files: activate a trialDays trial, note the expiry the app shows, uninstall, reinstall, and confirm the expiry is the same — which it will be only if state.json outlived the package or the trial clock is on the service.

What to take away

MSIX moves your app's AppData without telling your app, deletes it on uninstall, and leaves the machine itself alone. For licensing that is almost entirely good news: the cached lease is a cache and behaves like one, the fingerprint anchor is not package state so a reinstall is the same machine, and idempotent activation means the customer who reinstalls never burns a seat. The two things to design for are the customer who uninstalls to move — give them a deactivate they can find — and the one file that should not be a cache, the local trial clock. Make the paths explicit, print them in a diagnostic, and the day a support engineer needs lease.json they will find it on the first try.

The method: a static method wearing one attribute

Start with the definition. A trivial extension on string:

public static class StringExtensions
{
    public static int WordCount(this string s)
        => s.Split((char[]?)null, StringSplitOptions.RemoveEmptyEntries).Length;
}

Compile it and look at what this became. It is gone from the parameter — s is an ordinary string parameter — and in its place are two [Extension] attributes, one on the method and one on the class:

.class public abstract sealed auto ansi beforefieldinit StringExtensions
    extends [System.Runtime]System.Object
{
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.ExtensionAttribute::.ctor() = ( 01 00 00 00 )

    .method public hidebysig static int32 WordCount(string s) cil managed
    {
        .custom instance void [System.Runtime]System.Runtime.CompilerServices.ExtensionAttribute::.ctor() = ( 01 00 00 00 )
        // ... ldarg.0; call String::Split(...); ldlen; ...
    }
}

That is the entire difference between an extension method and a static helper. The method is public static, the first parameter is a normal parameter of a normal type, there is no special calling convention. The attribute on the method is what lets a decompiler render the first parameter as this s; the attribute on the class is what tells a consuming compiler the class is worth scanning for extensions in the first place. Strip both and you have StringExtensions.WordCount(x) and nothing else; add them and x.WordCount() becomes legal too.

The call site: byte-identical to a static call

Now call it two ways and compare the IL:

int a = "the quick brown fox".WordCount();         // fluent
int b = StringExtensions.WordCount("the quick brown fox");   // explicit static

Both compile to the same three instructions — load the string, call the static method, store:

ldstr      "the quick brown fox"
call       int32 StringExtensions::WordCount(string)
stloc.0

There is no second form. The CLR has no concept of an extension call, so the this is resolved and discarded at compile time, and the call site keeps no record of which syntax the author used. This is the crux of the whole problem: a decompiler cannot learn from the call whether the source was fluent. It can only look at the method being called, see [Extension] on it, and choose to print the call as a member access on its first argument — "the quick brown fox".WordCount() — because that is the idiomatic form and almost always the original. Both renderings are legal and compile identically, so the choice is readability, not correctness. Glass.NET makes it, which is why the output reads like C# a human wrote rather than like a macro expansion.

The chain: one rule, applied outward

The reason the dot matters is LINQ, where reading the IL literally produces something correct and unreadable. Take a pipeline:

var top = people.Where(p => p.Active).Select(p => p.Name).OrderBy(n => n).ToList();

Every one of Where, Select, OrderBy, ToList is a static extension method on Enumerable, so the IL is a nest — the outermost call emitted last, each result feeding the next call's first argument:

call ...ToList( call ...OrderBy( call ...Select( call ...Where(people, <lambda>), <lambda>), <lambda>))

Read that literally and you get Enumerable.ToList(Enumerable.OrderBy(Enumerable.Select(Enumerable.Where(people, …), …), …)) — a four-deep nest you have to read inside-out. Because each method carries [Extension], Glass.NET applies the one rule repeatedly: print each static call as a member access on its first argument. The innermost Where(people, …) becomes people.Where(…); that whole expression is the first argument of Select, so it reads people.Where(…).Select(…); and so on outward until the nest has unrolled into the original chain. The precedence has to be exact — a lambda body with a conditional, or a cast inserted mid-chain, needs the right parentheses or the meaning shifts — but the shape falls straight out of applying "member access on the first argument" from the innermost call out.

Why the attribute, not the call, is the source of truth

It is worth being precise about what Glass trusts. The call site is ambiguous by construction — it is the same IL for both syntaxes — so it carries no signal. The method's metadata is unambiguous: [Extension] is present or it is not. So Glass keys its decision on the method:

• Target method has [Extension] → render the call as arg0.Method(rest).
• Target method does not → render it as Type.Method(args).

This also handles the awkward real cases correctly. If someone deliberately wrote Enumerable.Where(list, p) in explicit static form, Glass still prints list.Where(p) — which is fine, because it compiles back to the same IL and reads better. And a generic extension method like Select<TSource, TResult> carries the attribute just the same; Glass renders src.Select(f) and lets C#'s type inference recover the type arguments at recompile, only spelling them out when inference cannot. The attribute is a reliable, local signal on the method being called, which is exactly what a decompiler wants — no global analysis, no guessing from surrounding using directives that are not even in the IL.

The C# 14 extension-block shape

Newer code may use extension blocks, which group members under one receiver and, for the first time, allow extension properties:

public static class StringExtensions
{
    extension(string s)
    {
        public int  WordCount => s.Split((char[]?)null, StringSplitOptions.RemoveEmptyEntries).Length;
        public bool IsBlank()  => string.IsNullOrWhiteSpace(s);
    }
}

This is new syntax, not new runtime. The members still lower to static methods on the enclosing static class, marked so a consumer's compiler can route name.WordCount and name.IsBlank() to them — an extension property becomes a static accessor method, an extension method a static method with the receiver as its first parameter, plus grouping metadata tying several members to one receiver. A decompiler reading such an assembly sees static methods with marker metadata and a receiver parameter, much as before. Glass.NET reconstructs them as extensions; a plain extension method can be shown either as the classic this-parameter form or inside a block, but an extension property has no classic spelling, so it comes back as a block. The semantics are identical either way, because the lowered static methods are identical — the skin changed, not the IL.

The takeaway

An extension method leaves exactly one trace in metadata: the [Extension] attribute, on the method so the first parameter can wear this, and on the class so a compiler knows to look there. The call site keeps no trace at all — text.WordCount() and StringExtensions.WordCount(text) are byte-identical IL — so a decompiler cannot learn the fluent form from the call and must read it off the method instead. Glass.NET does exactly that: it prints any static call whose target carries [Extension] as a member access on the first argument, applies that one rule from the innermost call outward to unroll a LINQ nest back into a chain, and recognises the C# 14 extension-block lowering as the same static methods under a newer syntax. The result reads like the pipeline that was written, not the nest the compiler left — because the decompiler trusted the attribute, which is the only thing that survived.

Free — evaluate and protect small projects

The Free edition is fully functional for trying Nebula.NET and protecting small or hobby projects. You get identifier renaming, a couple of encrypted strings, a couple of control-flow-protected methods, and both the CLI and desktop GUI.

Choose Free if: you're evaluating the tool, or shipping a small/non-commercial project and basic renaming is enough.

You'll outgrow it when: you need full string encryption, control-flow flattening on more than a couple of methods, anti-tamper, or the ability to read back crash stack traces.

Licensed — the full suite for professionals and teams

Licensed removes all caps and unlocks the complete standard suite: unlimited string encryption and control-flow flattening, method encryption, anti-tamper & anti-debug, resource and metadata hardening, Authenticode signing, stack-trace de-obfuscation, and MSBuild/CI integration — plus priority email support.

It's available two ways:

• Annual — $599 per seat/year (always-current updates).
• Perpetual — $1,499 per seat, one-time, never expires (includes 1 year of updates and priority support). Best value if you'll use it long-term.

Choose Licensed if: you sell or distribute commercial .NET software and want real, complete protection with support. This is the right fit for most teams.

Enterprise — protection and control at scale

Enterprise includes everything in Licensed, plus capabilities larger organizations need:

• Per-customer watermarking — trace a leaked or cracked binary back to the exact customer.
• Aggressive control-flow tier for your most sensitive assemblies.
• Floating CI-server licenses — protect on build agents without using developer seats.
• On-prem / air-gapped activation for secure environments.
• Volume & site licensing, purchase orders and invoicing.
• Priority support with an SLA and onboarding.

Choose Enterprise if: you distribute widely and want leak tracing, you have strict CI or security requirements, or you need volume licensing and a formal procurement process.

Quick decision guide

See the full edition comparison, pricing, or request an Enterprise quote. Not ready to buy? Start free — you can upgrade any time by registering a license key; no reinstall required.