Since AxProtector version 10.70, there is a new runtime library cprsrt.dll for .NET, which must be available at runtime.
This library is secured with certificates to enable encrypted communication and an integrity check.
For this AxProtector must use the "WPK certificate" of a FSB (Firm Security Box) for encryption.
For this, usually the certificate for the Firm Code of the license entry is used, for which the application is encrypted.
However, since no license entry is used when using IP Protection, you must explicitly enter a Firm Code here for which you have a valid FSB entry when encrypting, e.g.: -lfc6000010.
In AxProtector .NET v10.70, the new runtime library "CodeMeter Protection Suite Runtime Library (CPSRT)" has been added. This is required when executing the protected assembly with .NET Framework and is therefore copied to the output folder during encryption.
With the help of this CPSRT library, the support of 'AppDomain' is implemented. The '-appdomain' option previously required for these applications is no longer required.
A Firm Code specific certificate is required in your FSB to use the CPSRT-Dlls. This seems to be missing in your case. Therefore, the following message appears during encryption:
Error: No WPK certificate found in FSB. For protection, a certificate matching the Firm Code is required. This certificate is available free of charge from Wibu-Systems. Please send a context file for Firm Code 99 of your CodeMeter-FSB by e-mail to email@example.com with the subject "Certificate License Update".
The missing certificate can be requested from Wibu-Systems free of charge. To do this, please proceed as described in the error message and send a context file from the Firm Code 99 of your FSB by email with the subject "Certificate License Update" to firstname.lastname@example.org.
When using AxProtector .NET elements can be specifically excluded from obfuscation by using attributes.
For this purpose, the obfuscation attribute from the System.Reflection namespace can be used. This requires the parameter Exclude=true.
Since WPF/Xaml/Prism applications work a lot with reflection, it cannot be easily guaranteed that the obfuscated names of methods, fields, etc. will be entered everywhere instead of the original names.
If obfuscation is enabled and WPF applications are detected, encryption is aborted with an error message. Error: XPM6402
If you are sure that you still want to obfuscate, you can disable the error using -force:XPM6402.
Afterwards it is important that you test that everything still works correctly after the encryption.
This performance loss is a known issue. It occurs because your original code is "moved" to a secure place, and AxProtector code is placed at the original address when encrypting your assembly with AxProtector .NET.
If you now run your encrypted assembly and the method, which you encrypted, is called, only this AxProtector code is found. This AxProtector code redirects to the place at which the encrypted original code is stored. This code is then decrypted, and a dynamic method is created and executed.
As a result, the first calling-up of your encrypted method takes about 1.2 - 1.5 ms longer. This behavior also depends on the hardware setup of the PC on which the assembly is executed.
If your method is called a second time, this takes approx. 8 - 10 µs longer (generic methods take 30-60 µs longer), because the AxProtector code is executed again. However, AxProtector now checks, whether the method has been decrypted before. If this is the case, it redirects to the already encrypted code.
However, the performance loss is also largely determined by how often individual methods are called. For example calling a method 5,000,000 times adds up to 40 seconds, given 8 µs for each call.
Methods called this often typically hold no elementary code. You can regain performance, if you exclude such method from encryption. By default, we automatically exclude all methods smaller than 10 bytes. You can also customize the size of the excluded methods. This is done via the AxProtector option "-CMLn", which defines that only methods smaller than n bytes are encrypted.
In order to find out which methods are called frequently by an assembly, we recommend using a .NET profiling tool. These tools give detailed information on the methods called and the time required. Based on this data, you can decide which methods should be encrypted.
If you want to sign your assembly, you must do so after the encryption.
AxProtector .Net offers the possibility to specify the keys for the signing as parameters and to sign the assembly created during the encryption.
You have several options for signing:
Strong Name from a file
You can use Sn.exe -k WibuKeyFile.snk to write a key pair directly to a snk file.
Via the AxProtector .NET settings 'Strong Name from file' (option -snkf) you can now specify the file 'WibuKeyFile.snk' for signing.
Please note that the use of a password protected file (*.pfx) is not supported here. However, you can use it as described below.
When you perform a delayed signing, you first need a snk file that contains the PublicKey and then later a snk file with your key pair.
Then please proceed as follows:
1. Have assembly generated by compiler, specifying a snk file with public key along with the "delay signing only" option.
2. Let AxProtector .NET encrypt generated assembly, do not specify a snk-file!
3. Sign the encrypted assembly or have it signed.
Strong Name from a container
A file created with sn.exe -k WibuKeyFile.snk or *.pfx file can be installed into a container:
sn.exe -i WibuKeyFile[.snk|pfx] WibuContainer
Via the AxProtector .NET settings 'Strong Name from Container' (option -snkn) you can now specify 'WibuContainer' for the signing.