Some environments, including ones like remote locations (such as in a field or on the road), do not offer any Internet connectivity. Meanwhile, others are highly restrictive with Internet connectivity (often places such as hospitals, government and military offices, etc...). In these types of environments, it can be difficult or impractical to require Internet connectivity. Additionally, there might be other reasons why your application would need to be able to write to its license files freely as well (depending on your licensing requirements). In these situations, it is possible to use writable license files, which are license files that are encrypted and signed by your application (read more about license files). Although this means all key data needed to write license files is known to your application (which is less secure than using read-only licenses issued by SOLO Server), this affords you extra flexibility when needed.
Keep in mind that you need to make the best choices about what type of license file your application should use, and when it should use it. Our sample applications show you how you can use read-only licenses, writable licenses, and even a hybrid of both.
When creating your license implementation class, the one major thing you need to do differently is to inherit from the WritableLicense class (instead of License, which is for read-only licenses signed by SOLO Server). Your class would be defined using code similar to that which is shown below.
Aliases are hidden copies of your application's license file, which are designed to prevent your license file from being arbitrarily written to or deleted. Using aliases is necessary when using writable license files, as this prevents users from being able to easily restore the license file to a prior state simply by restoring backup copy of the file.
Although it is critical to use license file aliases to protect your writable licenses, they cannot prevent your application from being returned to a prior state when the entire system is restored to a snapshot or image (using something like Norton Ghost, for example). Using periodic background checking with SOLO Server whenever possible is best for preventing the license from being compromised in this manner.
The first step is to add some code to your license implementation class constructor. The code added will vary depending on what locations you use for your aliases.
The example code below and in any sample application code shows locations that are only meant to provide some guidance on selecting your application's alias locations. Your application must use different alias names and/or locations than any of the examples given by this documentation and any of the sample applications.
Additionally, it is equally important that any two applications (which do not share a license) use separate license file and alias locations.
More information on possible license and alias locations can be found in the Where should I store the license file and alias files? support article.
User-specific alias and license file locations are convenient because they can help you to avoid problems that need to be addressed when users with limited access to a system try to use your software. More specifically, if your application were to use user-specific locations exclusively, the primary benefit would be that users would never need elevated access to run and activate your application. However, the significant drawback is that because the locations used are unique to each user which signs-on to a system, each user will have his or her own license file and aliases, meaning each user will need to activate to be able to use the application. Some example code is provided below to show how you can configure some user-specific alias locations.
The steganography feature is presently a beta, and changes may be applied which could require minor source code modifications to be made in order to use a future release. Please keep in mind that your testing should be very thorough. Also, use your own images distributed with your application such as a splash screen image. Do not use an existing image such as the desktop wallpaper since another product could share that license location.
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.
Global alias and license file locations are locations which are shared by all users on a system. The advantage to using global locations is that the application only needs to be activated once on a given system. However, the drawback to this is that you typically need to consider setting permissions on these locations when deploying your application. Some examples on how you can configure some global alias locations is provided in the code below.
The steganography feature is presently a beta, and changes may be applied which could require minor source code modifications to be made in order to use a future release. Please keep in mind that your testing should be very thorough. Also, use your own images distributed with your application such as a splash screen image. Do not use an existing image such as the desktop wallpaper since another product could share that license location.
When storing license data, you will need to be mindful of the platform's data storage guidelines.
When using writable license files, you may need to store the licenses in a location where they will be retained even when the application is uninstalled.
Adding logic to your application to validate its configured aliases is pivotal to using aliases properly. The code below illustrates how you can validate aliases in your license implementation class.
Your license validation logic also needs to verify the system clock when using aliases to help ensure you can trust the time the system clock reports to your application.
Evaluations are one of the most common license models, and it is often convenient (if not necessary) to allow your application to automatically issue evaluation periods for your prospective customers (learn more).
If your application uses a writable license for all types of licenses, then it needs to be able to distinguish evaluations from other types of licenses. Since all other types of licenses will generally require activation with SOLO Server, the easiest way to identify self-issued evaluations is to check for an empty string value in the InstallationID property (as an Installation ID would be present for any licenses activated with SOLO Server). Otherwise, if your application only uses writable licenses for evaluations, then this can easily be determined by which license implementation is being used.
When your application is run on a computer for the first time, it is common practice to automatically issue a fresh evaluation period. You can implement this functionality in your license implementation class using a method similar to the one shown below.
Then, you can update your application to check to see whether or not the license file exists. When no license file is present (or when the LoadFile method inherited from WritableLicense fails), you can then call the new CreateFreshEvaluation method.
If your application uses writable license files exclusively (and not a hybrid of writable and read-only license files), then there may be some cases where you need to create an expired evaluation. This can include situations such as when a customer deactivates a license that was previously activated, or when a background check finds that the License ID or the Installation ID is no longer valid (or has been deactivated or revoked). Below is an example showing how you can create a method that creates an expired evaluation license, which you can then have your application call under these kinds of circumstances.