PC Guard for .NET was the first available software copy protection wrapper for .NET framework applications!

General Protection Workflow for .NET Applications

Depending on the development platform, architecture, and version of the Microsoft runtime environment used to build your software, PC Guard offers tailored protection mechanisms to guarantee the highest level of anti-piracy security.

Supported .NET Application Types

PC Guard is fully capable of protecting and licensing almost all types of managed applications across the entire Microsoft .NET ecosystem, including:

Windows Forms Applications (.exe)
WPF (Windows Presentation Foundation) Applications (.exe)
Console Applications (.exe)
Windows Services (.exe)
Class Libraries (.dll components)

1. Legacy .NET Framework Applications (Versions 1.0 to 4.8.x)

When protecting legacy .NET Framework applications, PC Guard processes the files through a native compilation and injection pipeline:

The Injection Process: PC Guard injects specialized unmanaged, native Win32/Win64 loader code directly into the target managed .NET application.

Encapsulation & Encryption: The original .NET assembly (along with its Intermediate Language (IL) bytecode and metadata) is heavily encrypted, and securely embedded within the native loader container.

Runtime Execution: When an end-user launches the protected application, the native loader executes first. It performs all cryptographic integrity checks and handles the hardware-locked license validation. Only after successful validation does the loader securely decrypt and execute the original .NET application directly in the system memory.

The Security Benefit: The managed .NET assembly never touches the physical disk in decrypted form, completely neutralizing standard IL decompilers.

Supported .NET Framework applications

- Fully managed .NET Framework desktop (EXE) applications and .NET services.

- Mixed mode C++ .NET Framework (EXE) applications.

- Fully managed .NET Framework dynamic link libraries (DLL modules) can be encrypted as long as main .NET framework application (EXE) which uses these modules is also encrypted. Only encrypted .NET Framework EXE applications can load encrypted .NET Framework .DLL modules.

.NET Framework services can be encrypted but since InstallUtil will refuse to install encrypted .NET service application installation or un-installation process has to be done directly from service. Please see the following KB article for more information.

Not supported .NET Framework applications

The following .NET applications are currently not supported:

- .NET Framework Active X controls

- .NET Framework WEB applications

- standalone .NET DLL's and some mixed .NET .DLL applications.

NOTE: Although these application can not be encrypted with PC Guard their source code can be obfuscated with SourceArmor .NET!

Additional notes

- Please see the following KB article about deploying protected .NET Framework application with ClickOnce

- Strong name signature verification should be turned off in compiler settings when compiling .NET Framework applications since signature will be invalidate during encryption process. Protected application can be digitally signed after protection.

- RTE - Runtime encryption system is not available for .NET Framework applications.

Protected program will perform the following .NET Framework specific checks during loading of protected application into memory:

1. Check installed operating system.

If Windows 95 (not supported by .NET) is installed "This program can not be run under Windows 95!" error message will be displayed.

2. Check the presence of .NET framework.

If .NET framework is not installed on target machine ".NET framework is not installed on this computer!" error message will be displayed.

3. Check if required version of .NET framework is installed.

Above error messages can be changed in language editor.

2. .NET Core Applications (Versions 1.0 - 3.1)

The introduction of .NET Core marked Microsoft’s shift to a modular, cross-platform architecture. Applications built on these versions require specific deployment handling:

Deployment Structure: Unlike legacy frameworks, .NET Core apps compile into platform-independent .dll files, which are run via a platform-specific host executable (.exe on Windows).

Core Protection Strategy: PC Guard targets and fully encrypts the core managed .dll assembly containing your intellectual property. The application is secured against reverse engineering, ensuring that the intermediate bytecode cannot be extracted or modified before the runtime environment authorizes execution through your custom licensing rules.

Supported .NET Core applications

Supported target .NET Core frameworks:

Supported output type:

Windows application
Windows console application
Windows class library

Supported platforms:

x86 (PC Guard for .NET)
x64 (PC Guard for .NET64)

Supported target runtime:

win-x86 (PC Guard for .NET)
win-x64 (PC Guard for .NET64)

NOTE: Protected x86 .NET Core Windows application (.dll module) can be run by bootstrap application (.exe) only and can not be run with dotnet command. Bootstrap application can also be encrypted.

This is not mandatory for x64 .NET Core applications. Protected module will work just fine run if from command line with dotnet command.

3. .NET 5.0 & 6.0 Applications (The Unified Platform)

With .NET 5 and .NET 6, Microsoft dropped the "Core" branding and unified their development platforms into a single framework.

Supported .NET 5 and .NET 6 applications

Supported output type:

- Windows application
- Windows console application
- Windows class library

Supported platforms:

- x86 (PC Guard for .NET)
- x64 (PC Guard for .NET64)

Supported target runtime:

- win-x86 (PC Guard for .NET)
- win-x64 (PC Guard for .NET64)

TIP: In case of REMOTE protection where license handling is done via default activation dialog license activation and management (like license removal, extension or transfer) should be handled by bootstrap EXE and not by appropriate .DLL module.

Only bootstrap EXE will display activation dialog which will be used for activation or license removal, extension or transfer, Bootstrap EXE should also be used for starting application.

Both bootstrap EXE and appropriate .DLL module should be protected with same settings. In this way bootstrap EXE and .DLL module will share the same license data

.NET applications published with "Produce single file" option are not supported!

4. Next-Gen .NET Applications with Native AOT (Versions 7.0 to 11.0)

With .NET 10 now established as the enterprise baseline and .NET 11 preview builds in active deployment, developers are heavily adopting Native AOT (Ahead-Of-Time) compilation—a feature that originally debuted in .NET 7/8:

No Intermediate IL Bytecode: Native AOT bypasses the Common Language Runtime (CLR) and compiles C# code directly into machine-specific native code (PE binaries for Windows).
The PC Guard Protection Shift: Because Native AOT applications do not contain IL bytecode, standard .NET injection and decryption mechanisms do not apply. Instead, PC Guard automatically treats these files as standard unmanaged, native Windows applications.
Anti-Tamper & Anti-Debugging Armor: PC Guard wraps the native AOT executable in a hardware-locked anti-tamper shield. It injects powerful anti-debugging heuristics and anti-memory-dumping code. This prevents advanced reverse engineering tools from reconstructing your compiled function maps, extracting plain-text string assets, or altering your application’s execution paths.

Crucial Implementation Notes for All .NET Developers

To ensure a seamless protection process and flawless execution, please follow these deployment prerequisites:

Obfuscate before encryption: If you plan to use SourceArmor .NET or any third-party code obfuscator alongside PC Guard, always apply code-level obfuscation before passing the final binary to PC Guard. PC Guard’s external binary wrapper must always be the final layer of your security build pipeline.

Keep Assemblies Valid: The target .NET Framework, .NET Core, or modern .NET application must be fully functional and properly compiled before protection. PC Guard requires valid PE structures to correctly map the encryption boundaries.

Strong name signature verification should be turned off in compiler settings: Sign protected native output executable using standard Microsoft signing utilities post-protection.