# Protect .NET Libraries and NuGet Packages

You can protect a .NET library while keeping its public types and members available to other applications. The steps below also show how to include the protected DLL in a NuGet package.

Build your library in Release configuration. In .NET Reactor, go to the Files page, choose Library, and open the compiled .dll as the main assembly.

Leave Obfuscate Public Types and Internalization disabled. This keeps the public names and access levels that other applications depend on.

You can still enable Obfuscation to rename private and internal types and members, and use other protection features to protect the implementation. Keep implementation details internal where possible instead of making every class public.

Names used by reflection, serialization, or friend assemblies may also need to remain unchanged, even when they are not public. Do not enable Ignore InternalsVisibleTo if another assembly relies on access to the library's internal members.

If the library is only used by your own application, you can protect the related assemblies together and also rename public types. See Public Type Obfuscation.

Choose the protection options you want to use, save the .nrproj project, and click Protect.

Use the protected DLL from the output directory created by .NET Reactor, together with its required dependencies. Do not accidentally use the original DLL from the build directory instead.

For a strong-named library, configure the signing key as described in Code Signing.

Make sure the package contains the protected DLL, not the original build output.

For a standard SDK-style project, copy the protected DLL back into the Release output folder used for packaging, keeping its original filename. Then run this command from the library's project directory:

dotnet pack -c Release --no-build

The --no-build option prevents another build from replacing the protected DLL with an unprotected one. If your package uses custom input paths, use the protected DLL at those locations instead.

For packages targeting multiple frameworks, protect each framework's DLL separately. Do not reuse one protected DLL for every target.

Keep .NET Reactor project files, master keys, and mapping files out of the package. Do not include debug symbol files (.pdb) by default. Distribute symbols only for a specific diagnostic requirement, and verify that they are usable with the protected library. Do not include outdated PDBs from the unprotected build. Review symbol packages, embedded symbols, and source information as described in Publishing.

Use a separate test application that references the protected DLL. For NuGet, install the generated package rather than using a project reference to the library's source.

Check that the application builds and that the library's functions work as expected, including any reflection or serialization. When updating an existing library, also test an already compiled application with the new protected DLL. Repeat the test for the frameworks and platforms you support.

You can open a .nupkg as a ZIP archive to check which DLLs it contains. Check the actual runtime implementations, not just reference assemblies that describe the public API. For inspecting the protection itself, see Verify Protected Output.

Reflection Problems · Serialization · Choosing Protection Settings

Publishing · Debugging