Which file should an EXE obfuscator receive?
| Published output | What to check |
|---|---|
| Managed .NET Framework EXE | The EXE may contain the managed assembly. Inspect it rather than relying on its extension. |
| Modern framework-dependent app with apphost | Upload the managed application DLL, then retain the launcher, dependencies and runtime configuration. |
| Native C/C++ or NativeAOT EXE | Native machine code is not the managed input this service rewrites. |
| Single-file or specialized publishing | Validate the publish workflow separately; this example does not cover those modes. |
The presence of .exe does not prove the file contains managed code. Microsoft describes the apphost and portable DLL publishing layout; NativeAOT instead compiles IL to native code.
Reproducible application case: one DLL, two launch paths
On October 23, 2026, we published a self-authored .NET 8 invoice-checking console application on Windows. It is a demonstration, not a customer project. Its published folder contains:
InvoiceConsumer.exe native Windows apphost
InvoiceConsumer.dll managed application, with an entry point
InvoiceLibrary.dll library dependency
InvoiceConsumer.deps.json dependency manifest
InvoiceConsumer.runtimeconfig.json runtime configuration- We uploaded
InvoiceConsumer.exeto the public Free endpoint. It returned the valid-.NET-assembly error, with no protected attachment. - We uploaded
InvoiceConsumer.dllwithrenamePublic=true. It returned a rewritten managed application. - In a separate copy of the published folder, we replaced only
InvoiceConsumer.dllunder its expected name. The original build stayed intact. - We ran the original and protected folders with both
dotnet InvoiceConsumer.dllandInvoiceConsumer.exe.
| Launch | Observed result |
|---|---|
| Original, dotnet host | 10 checks pass |
| Protected, dotnet host | 10 checks pass; identical output |
| Original, Windows apphost | 10 checks pass |
| Protected, same Windows apphost | 10 checks pass; identical output |
The checks cover known invoice totals, JSON, events, state and invalid input. The apphost, library dependency, runtime configuration and dependency manifest were byte-identical between folders. The explicit InvoiceApplication class and its public ExpectedInvoiceCount helper were renamed; Main remains the managed entry point. Compiler-generated types may be skipped, so inspect representative code rather than assuming every name changes. ILSpy listings are included. Different hashes identify artifacts; they do not measure protection strength.
Download the application launch case Read the four-launch report
The bundle includes source, original/protected publish folders, the Windows apphost and reproduction instructions. This validates one framework-dependent .NET 8 example. It does not validate .NET Framework EXEs, other operating systems, self-contained or single-file apps, signing, or arbitrary UI applications. No Pro transforms were enabled.
Public renaming depends on an entry point
An application can live in a DLL. FreeObfuscator checks for a managed entry point to distinguish applications from class libraries. Public renaming is optional for applications; it is not automatically safe just because the assembly launches. Reflection, XAML, serializers and external plugin callers may still depend on names. Test those paths before enabling it.
For a DLL used by other assemblies, see the public-contract comparison and unchanged-consumer test.
How to verify your protected application
- Build and publish in Release. Keep a known-good original publish folder.
- Identify and upload the managed application assembly, not a native launcher.
- Place the downloaded assembly into a separate staging folder under the filename expected by the launcher. Keep dependencies and configuration alongside it.
- Compare normal output, failure cases, saved data and integrations through the launch path you ship. Do more than check that the process starts.
- Inspect selected methods with ILSpy to confirm the requested transformations. Keep secrets off the client.
If the download does not launch
- Valid-.NET-assembly error during upload: inspect whether the selected EXE is a native launcher or already protected. Use the managed DLL when appropriate.
- Assembly or configuration missing: compare the complete staging folder with the original. A downloaded
.obfuscated.dllis not a complete published application. - Name-based lookup fails: retest reflection, bindings and serialization, and review public-renaming choices. See the compatibility guide.
Frequently asked about EXE obfuscation
Can I obfuscate any EXE file?
No. The input must be managed .NET code. Native C/C++ and NativeAOT output are not supported. In the modern .NET case above, the EXE is an apphost and the application code lives in the DLL.
Can an application DLL rename public names?
Yes, optionally, when it has a managed entry point. The extension is not the deciding factor. Test all name-dependent integrations first; class libraries retain their public API.
Is the online EXE obfuscator free?
Free supports one managed file up to 1 MB with no account. Pro adds deeper transforms, larger files, batch processing and API access. Compare current plans.
Renaming changes selected names, not the fact that code can be decompiled. See the measured verification guide, C# code example and .NET protection overview.