Open topic with navigation
PLUSManaged is an object oriented API, and is designed to make heavy use of features specific to object-oriented programming. The most important feature of object oriented programming used is inheritance, as PLUSManaged provides you with an abstract class from which your implementation will be derived. Of course, the first steps to using PLUSManaged in your assembly includes defining your licensing requirements and adding a reference to the PLUSManaged assembly.
Next, you will need to decide what to name your licensing implementation class. The name of your class can reflect the product being licensed (i.e. XyzProductLicense); the type of license file used (i.e. ReadOnlyLicense); or, in some more advanced implementations, the type of license (i.e. EvaluationLicense or NetworkFloatingLicense). It is ultimately up to you to make the best choice based on what is most appropriate for your application. For the purposes of this guide, we will name the implementation class SampleLicense.
The steps laid out in the common implementation sub-topics of this manual do not match exactly what is in the Protection PLUS 5 SDK sample projects. The manual topics are more simplified to make it easier to explain, while the sample projects have more complex organization, but the resulting functionality is similar in both cases.
Like most object oriented APIs, PLUSManaged groups its objects into categorically organized namespaces. Your license implementation class will need to specify that it uses/imports several namespaces as outlined in the code example below:
The System, System.Collections.Generic, and System.IO namespaces are part of the .NET Framework, and may already be in your source code. If they are, you will need to make sure there is only a single using/Imports statement at the top of your class file for each. The com.softwarekey.Client namespaces are the ones which contain objects in PLUSManaged. Although the namespaces are documented in the PLUSManaged API reference, here is a brief summary of the namespaces used here:
|com.softwarekey.Client.Licensing||Contains objects and data for licensing, including the base License (for read-only licenses) and WritableLicense (for writable, self-signed license files).|
|com.softwarekey.Client.Utils||Contains utility objects which are designed to help with a variety of common tasks. This includes things such as XML parsing and manipulation, file system functions, encryption data management, and more.|
|com.softwarekey.Client.WebService.XmlActivationService||Contains objects required to submit and process activation and other ELM functions.|
|com.softwarekey.Client.WebService.XmlLicenseFileService||Contains objects required to perform background checking and license file refreshing simultaneously.|
Adding the namespaces to your class file using the using/Imports statements allows you to reference the classes directly without the need to reference it using the full namespace. So for example, without the using/Imports statements, you would reference the com.softwarekey.Client.Utils.IOHelper class as shown here; however, you can simply reference it directly as IOHelper with these statements present. This helps make your application's code a little easier to read and maintain. Also keep in mind that it is possible that your application or an assembly it references and uses could use a class name which matches that of one of the classes used from PLUSManaged. When you encounter an ambiguous reference like this, your application will likely generate compiler errors or warnings, which can easily be resolved by referencing the class using the full name space (i.e. com.softwarekey.Client.Utils.IOHelper).
Next, the PLUSManaged API provides you with two abstract classes from which your license class should be derived. The class you will use will depend on the type of license files you intend to use. If you intend to use writable, self-signed license files, your class will need to inherit from WritableLicense. Otherwise, if you intend to use the more secure, read-only license files issued by SOLO Server, your class must inherit from the License class. Our example will use the latter, as shown in the example code excerpt below.
Now that the initial configuration of your class is established, you can begin implementing your licensing class. Before doing this, it is important to have already defined your licensing requirements, as well as how your application needs to identify a system. For the example used in this guide, we will use network interface cards (NICs), hard drive volume format serials, and the computer name to identify the system being licensed.
The first thing you must add to make your class usable is a constructor. The constructor is what gets called to create a new instance of your license implementation class. Below is an example excerpt of a constructor for the SampleLicense class, which passes required data to the base License constructor.
The code excerpts above are just examples, which must have several pieces of information populated!
Here is how to populate the required data in the example code excerpt above.
In the PLUSManaged samples and the PLUSManagedGui samples, these values are all defined in a LicenseConfiguration class for convenience. You can copy and modify this class as needed as an alternative to defining the values directly in your constructor.
The next step is to get a license validation method in place, which will be called by your application's code any time it needs to validate its license. This typically needs to be called any time your application is launched by a user, and when it performs some kind of important function. For example, if your application takes some input from a user and uses that to generate some kind of document as the output, then it is good practice to validate the license before generating the output. Here is a code excerpt that only gets the method in place (it is not a complete implementation!):
Before adding copy protection logic to this method, you need to add some code to activate and get a license file.