PLUSManaged: Deploying Protected Applications

Review the system requirements for details on what is required to run PLUSManaged. If your application also uses PLUSManagedGui, be sure to read about deploying applications that use PLUSManagedGui.

Distributing the PLUSManaged Library

The PLUSManaged library should be installed in the same directory as your application (or .exe file). This greatly simplifies deployment and also prevents your application from using other versions the library that may not be compatible with your application (which could be installed by other applications that use PLUSManaged).


Although installing the PLUSManaged library to the application directory is strongly recommended, it is possible to install the assembly to the Global Assembly Cache (GAC) if required by your application.

If your application requires you to install dependencies in the GAC, make sure your application's reference to any Protection PLUS 5 SDK libraries (such as PLUSManaged or PLUSManagedGui) has the Specified Version property set to true.

Serialization Assemblies

PLUSManaged does include an XML serialization assembly, named PLUSManaged.XmlSerializers.dll.  Although you are not required to ship this assembly with your application, doing so is strongly recommended, as it can significantly increase your application's performance during start-up. If this assembly is not distributed with your application, then .NET will automatically compile a serialization assembly each time your application starts-up (which can cause some delay).


PLUSManaged for .NET Standard 2.0 is in beta and is not included in the current release. It is available upon request by contacting SoftwareKey.

This does not apply nor is it needed for PLUSManaged for .NET Standard 2.0 as it does not include an XML serialization assembly.



The Protection PLUS 5 SDK .NET libraries (such as PLUSManaged and PLUSManagedGui) are obfuscated, but this alone cannot prevent a hacker from modifying your application's source code. When your .NET application is compiled, it is compiled to what is called Microsoft Intermediate Language (MSIL - pronounced like "missile") code. There are tools that can be used to translate and reverse engineer MSIL code, so it is imperative that you select and use an obfuscation tool to further protect your application and your investments in it. Microsoft offers a good summary of this subject.

Assembly Embedding

It is possible to obfuscate your application in a way which embeds the Protection PLUS 5 SDK libraries with your application. This is recommended where possible, as it works with PLUSManaged and PLUSManagedGui, provides some extra security with most obfuscation tools, and can help simplify your deployment (as won't be necessary to distribute the library once it is embedded in your application).

Installation Requirements

Protection PLUS 5 SDK license files are generally not distributed with an application. When using read-only license files, they must be issued by SOLO Server during activation. When using writable license files, such as for unmanaged evaluations/trials that do not require activation, the license files are generated the first time the application runs. Depending on where you choose to store your application's license files, you may need to set permissions on these locations during installation so that your application has write access and can save it's license files when it runs or is activated. Permissions can be set on the directory or file level. If you desire to set permissions on the file level, you can install a blank (empty) license file as a placeholder during installation.

Writable Licenses

When using writable licenses, PLUSManaged automatically attempts to set permissions on the license file and the aliases when they are saved. You can use this to your advantage by creating a separate helper application creates and saves the initial the license file and aliases, or add a custom command-line switch to your application that allows it to do this silently. This would enable you to call the helper application or your main application (with the command-line switch) from your installer.


Microsoft Office applications (such as Word, Excel, Access, etc...) may run in a ClickToRun environment.  This environment has known limitations that make it problematic for licensed Office add-ins and macros to use global locations. Consequently, licensed add-ins and macros that target these environments should only use user-specific locations for licenses and aliases. See this knowledge-base article for more details.

Using .NET to Set Permissions in Windows

PLUSManaged includes a IOHelper.GrantControlToWorld method that can be used to grant everyone permissions to a file. However, you may wish to write your own application that initializes permissions for other things as well. The .NET Framework offers a number of classes which may be used to set permissions on files, folders, and registry keys. You can use these objects to create a separate helper application, which may be called by your installer. The easiest way to do this is to give "Everyone" access to read and write to the license file and aliases.  To do this you can begin by calling the IOHelper.GetEveryoneAccountNameString method in PLUSManaged, or by using code similar to the example below to get the appropriate account name (which can vary depending on the computer's regional settings). Note that, to use the example code provided here, you may need to add a reference to the System.Security .NET assembly to your project, and add a using or Imports statement for the System.Security.AccessControl, System.Security.Principal, and Microsoft.Win32 namespaces at the top of your source file.

SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
NTAccount acct = sid.Translate(typeof(NTAccount)) as NTAccount;
string everyoneAccountName = acct.ToString();
Dim sid As New SecurityIdentifier(WellKnownSidType.WorldSid, Nothing)
Dim acct As NTAccount = CType(sid.Translate(Type.GetType("System.Security.Principal.NTAccount")), NTAccount)
Dim everyoneAccountName As String = acct.ToString()

Once you have the appropriate account name (in everyoneAccountName), you can use it to set permissions on a file or registry key as shown in the examples below.

Setting Permissions on a File

FileSecurity sec = File.GetAccessControl("[Path to File]");
sec.AddAccessRule(new FileSystemAccessRule(everyoneAccountName, FileSystemRights.FullControl, AccessControlType.Allow));
File.SetAccessControl("[Path to File]", sec);
Dim sec As FileSecurity = File.GetAccessControl("[Path to File]")
sec.AddAccessRule(new FileSystemAccessRule(everyoneAccountName, FileSystemRights.FullControl, AccessControlType.Allow))
File.SetAccessControl("[Path to File]", sec)

Setting Permissions on a Registry Key

RegistryKey key = Registry.LocalMachine.OpenSubKey("[Path to Registry Key]", true);
RegistrySecurity sec = new RegistrySecurity();
sec.GetAccessRules(true, true, typeof(System.Security.Principal.SecurityIdentifier));
sec.AddAccessRule(new RegistryAccessRule(everyoneAccountName, RegistryRights.FullControl, AccessControlType.Allow));
Dim key As RegistryKey = Registry.LocalMachine.OpenSubKey("[Path to Registry Key]", True)
Dim sec As New RegistrySecurity()
sec.GetAccessRules(True, True, Type.GetType("System.Security.Principal.SecurityIdentifier"))
sec.AddAccessRule(New RegistryAccessRule(everyoneAccountName, RegistryRights.FullControl, AccessControlType.Allow))