#
How to Protect a .NET Single-File Application
For single-file publishing, we recommend the official .NET publishing workflow using <PublishSingleFile>true</PublishSingleFile>. After publishing, open the resulting single-file executable directly in .NET Reactor. .NET Reactor protects the selected assemblies inside the bundle and creates a new bundle containing the protected output.
.NET Reactor also provides its own .NET Bundling option as an alternative. These are two different ways to create a single-file application. You do not need to enable .NET Bundling to protect an existing .NET SDK single-file bundle.
#
Recommended workflow: Publish with .NET, then protect
Combining single-file publishing with ReadyToRun
If ReadyToRun is also required, follow the ReadyToRun workflow rather than applying this publish-then-protect sequence unchanged. Protection must run before ReadyToRun generation. Configure the required protection timing and settings, then test the final combined output.
Trimmed single-file applications
If your application uses trimming, add and configure Eziriz.Reactor.TrimHelper in the relevant project before publishing the single-file application. Follow the package installation and project configuration instructions in Troubleshooting → Trimming Problems.
This workflow trims first and protects afterwards. The helper ensures that trimming preserves the classes, members, and references required by the protection code that .NET Reactor injects later.
#
1. Publish the single-file application
Enable single-file publishing in your application project:
<PropertyGroup>
<PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>
Publish the application using the .NET SDK or your IDE's publish workflow. Verify that the published executable works before applying protection.
#
2. Open the published executable in .NET Reactor
On the Files page, open the published single-file executable as the Main Assembly.
.NET Reactor treats a single-file bundle as a virtual directory. The main assembly is therefore displayed using a path such as:
C:\Publish\AppName.exe\Main.dll
In this example, AppName.exe is the single-file bundle and Main.dll is the application's managed entry assembly inside it. The actual names depend on your application.
This path identifies an assembly inside the bundle. It does not refer to a physical folder named AppName.exe, and you do not need to extract the bundle manually.
#
3. Select additional assemblies inside the bundle
To protect additional assemblies contained in the bundle, go to Additional Assemblies, click the menu button, and choose Scan Main Assembly Dependencies.
.NET Reactor lists the referenced dependencies that are contained in the bundle. Review the detected entries and select the additional assemblies you want to protect.
An assembly is not automatically protected merely because it is part of the single-file bundle. Include the required dependencies in your protection selection.
#
4. Protect the selected assemblies and create the new bundle
Configure the required protection options, then click Protect.
.NET Reactor protects the main assembly and the selected additional assemblies inside the bundle. It then creates a new single-file bundle containing the protected assemblies.
Use the newly created bundle as your protected application output, not the original executable produced by publishing. Test that new bundle with the external files and runtime prerequisites your application requires.
#
Protected output and inspection
In addition to the new bundle, .NET Reactor creates subfolders containing the individual protected assemblies. These files are primarily provided so that you can inspect and analyze the protected assemblies separately, without first extracting them from the bundle.
The separate assembly outputs do not replace the single-file result: the selected protected assemblies are also included in the newly created bundle.
#
Anti ILDASM and bundle inspection
When Anti ILDASM is enabled, common decompilers can no longer inspect the protected bundle to browse and analyze its contained assemblies. This is expected behavior.
The per-assembly output folders provide direct access to the protected files independently of bundle browsing. The configured protection features still apply to those individual files. Their availability outside the bundle does not disable Anti ILDASM or otherwise remove protection.
#
Release files and symbols
Deploy the new protected bundle and the external files required by the application. Do not add the per-assembly inspection copies as separate runtime dependencies.
Keep PDB files private unless they are genuinely required in the customer deployment. Also review embedded debugging information rather than checking only for loose .pdb files. Follow Publishing for symbol handling, release staging, and final verification.
#
Alternative: Create the single file with .NET Reactor
.NET Reactor can also create a single-file application itself using .NET Bundling.
For this approach, start with the application's main assembly and its dependencies from a regular build or publish output rather than an existing single-file bundle. In .NET Reactor, enable:
1. General Settings → .NET Bundling
Configure the assemblies to protect and the desired protection options, then click Protect. .NET Reactor collects the application's assemblies and packages them into a single file at the end of the process.
#
Which approach should you choose?
We recommend the official .NET single-file publishing workflow. Depending on the application and publishing settings, it can produce a more efficient bundle because unnecessary files may be excluded rather than included in the single file.
If .NET Reactor's .NET Bundling option does not produce the desired result, use the official workflow instead: publish with <PublishSingleFile>true</PublishSingleFile>, open the resulting bundle in .NET Reactor, select the assemblies to protect, and create the protected bundle as described above.
#
Related topics
Publishing · ReadyToRun · Verify Protected Output · dotPeek Shows Original Source Code