How To: Apply Command-Line Application Protection with SLP Code Protector (KB2)

SLP Code Protector has a command-line application protection feature that can be used to integrate the protection of an application as part of a build process.

For integration of protection into Visual Studio and automated builds this process has been superseed by that outlined in http://www.inishtech.com/KB12

Note: Command-line protection cannot be applied if a generic Permutation is used. You must first create a private Permutation. 

To Create an SLP Code Protector Configuration File 

  1. Open SLP Code Protector.
  2. Click the Project tab, and then click View.

Bb931692.SLPCodeProtector(en-us,MSDN.10).jpg

  1. Add the modules, and select the methods you wish to protect. Define all necessary settings for the methods.
  2. The settings apply to the entire project, the application, and the methods selected for protection. Settings are displayed in the right portion of the page in the Project view. For more information about selecting the settings, refer to the SLP Code Protector User Guide.
  3. Click File, and then click Save Project As…
  4. Enter a file name with a .SLMCfg extension, for example, ProductName.SLMCfg. Click Save. This creates a configuration file called ProductName.SLMCfg.

To Apply Command-Line Protection Options

Note: This step is NOT requried if you are following http://www.inishtech.com/KB12 on How to Integrate Protection into Visual Studio and Automated Builds

  1. To apply command-line protection options, you will run Microsoft.Licensing.ProtectCmd.exe with the configuration file you created earlier, as an argument. Microsoft.Licensing.ProtectCmd.exe is found at %programfiles%:\Program Files\Microsoft SLP Code Protector.

The default syntax for this command is:

Microsoft.Licensing.ProtectCmd.exe <Protection configuration file.SLMCfg>

 

  1. Type the following command at the prompt: 
“%programfiles%\InishTech SLP Code Protector\Microsoft.Licensing.ProtectCmd.exe” ProductName.SLMCfg

Important: In order for the protection to apply correctly, the location of the configuration file should not be changed relative to the protected and unprotected assemblies. If the configuration file is not stored on the same drive as the input assemblies, the complete physical path for the input as well as output directory is used within the configuration file, to reference these files.