Testing Protected Applications

Any time you ship your application or make it available to customers and prospects, it is pivotal to test everything thoroughly. The licensing logic added to your application should be included with this testing to help prevent unforeseen issues from arising.  This topic will help guide you through this process, and may even serve as a helpful 'checklist' for you to print-out to keep track of what test has been done for new and updated applications.

Exercise Caution

Oftentimes, testing on computers that are used regularly and/or used for development can be less than ideal, can even result in unintended side effects. In general, we strongly advise you to avoid such problems by using virtualization software as described in the next section. A good example of where things can go awry when testing on development computers is the negative impacts that are possible from altering your system clock (which you might try to do when testing time-limited licenses). Some examples of how this could affect your development systems includes (but is not limited to):

If you cannot avoid these issues by using virtualization software, then the next best thing to do is to have a dedicated test machine which is backed-up with a complete image/snap-shot regularly.

General Testing Practices and Tools

As with any task, it is important to ensure you have the right set of tools to help ensure the task is completed well and efficiently. Here are some types of tools that we can recommend for your consideration.

Virtualization Software

Although this is not required, using virtualization software to run virtual machines is very helpful for a wide variety of reasons.

Keep in mind that if your licensing requirements call for the detection of virtual machine guest environments to alter the way your licensing logic behaves (or even to prevent the application from running in these environments entirely), you may need to make additional considerations and adjustments for your testing procedures. These adjustments can include creating special test builds which are never publicly released, and could include testing on physical computers in place of or in addition to testing in virtual machine guests.

Helpful Information

Microsoft provides for free many Windows versions installed for many different virtual machine players/hosts. These virtual machines are setup with a 90 day evaluation of Windows.

Build and Test Automation Scripts

There are many free and commercial tools available for automating your build and testing processes.  Some free tools include, but are not limited to, Power Shell scripts or batch files, shell scripts, home-grown scripts and applications you might already have in place. Having scripts related to building and testing helps avoid missing crucial steps to building applications properly, and also helps automate any mundane building and testing tasks. Additionally, unit testing can also help identify potential issues during development, and is a particularly convenient way of testing all possible execution paths in your code. Most integrated development environments (IDEs) have built-in features for assisting with unit testing, and many also have various code analysis features that can also help identify areas of code that could be problematic or be adjusted to follow best practices.

Establish a Testing Checklist

Since every application is different, each will have a different set of tests that should be run before releasing a new build to customers and prospects.  Below is a list designed to help you get started on a checklist for testing the licensing features (and potentially other features) in your applications.

Verify your Installer




Activation and Electronic License Management

When testing activation and Electronic License Management (ELM) features in your application, it is important to test each possible means of performing the tasks that users are allowed/able to perform.

Using SOLO Server

You should perform the tests below with a test system that has a direct Internet connection if you allow activating online. If you allow activation through another system's Internet connection, make sure you test with manual request files while the test system lacks Internet connectivity. Furthermore, if your application supports several different types of licenses (such as full/non-expiring, time-limited, network floating, etc...), make sure you also run the tests below for each type of license.

Using Trigger Codes

Activation is also possible using a numeric challenge-response mechanism called trigger codes.  Trigger codes afford your customers the convenience of being able to activate systems which lack Internet connectivity (especially systems in remote locations) by manually exchanging numeric codes with you or your customer service representatives via phone or fax.


Trigger codes should only be used when absolutely necessary!

Trigger codes require the use of writable license files, which can be less secure than read-only license files when not using time-limited licenses.

Like any other challenge/response scheme, allowing activation via trigger codes introduces the potential to be exploited by hackers to make key generators (which are programs that issue unauthorized activations for your application) available. If the customer is able to activate using another computer or device's Internet connection, or by email, then using the manual request file is strongly recommended, as this is a much more robust and secure approach for activating disconnected devices or systems.

By definition, a trigger code is essentially just an encrypted value which gets decoded to a numeric value between 1 and 50 (which is the trigger code number). When processing the activation codes, the resulting trigger code number is used to then identify which actions should be taken in your program to alter the state of the application's license. The Protection PLUS 5 SDK sample applications include some basic trigger code implementations for the most common types of licenses. Make sure you run the following tests:

Copy Protection

Your application can identify a system which has been activated to ensure its license is only used on the system on which it was activated.  Each application can use a different combination of algorithms and requirements for this purpose, so here are some generalized tests for you to consider for each identifier algorithm being used:

Time-Limited Licenses

If your application uses time-limited licenses (which are licenses that are only valid for a limited amount of time), then you should test your application's behavior thoroughly.


The safest approach for testing time-limited licenses is to utilize virtualzation software.  If virtualization software is not an option, then using another computer that is dedicated to testing is recommended. Examples of the potential issues you will avoid can be found in the "Exercise Caution" section at the beginning of this topic.

If your application supports multiple types of time-limited licenses (such as an evaluation and an activated, lease or subscription style license), run the tests for each type of license. Before you begin your testing, make sure your test system is not configured to synchronize with network/Internet time.  In Windows, you can change this setting in the Internet Time tab located in the same dialog where you can adjust your system's date/time.

Internet Connectivity

If your application requires checking its status or refreshing its license with SOLO Server, you will need to make sure you test this functionality with and without Internet connectivity. Here are some tests you can run:

Build Configurations

Sometimes it is necessary to use multiple build configurations of an application to produce different builds or releases for various reasons.  Reasons could include things like branding changes, using separate builds to omit certain features that are not easily enforced through licensing code alone (i.e. an evaluation build is sometimes necessary to omit unprotected content), etc... All tests should ideally be performed against all possible build configurations, especially when code is conditionally compiled for different build configurations (typically done via preprocessor directives).

Supported Environments

All tests should be repeated for each platform supported. So for example, if your application is supported on Windows 7 and later, you would typically test your application on the 32 bit and 64 bit versions of Windows 7, Windows Server 2008 R2, Windows 8, and Windows 8 Server.

Additionally, if your application supports multiple languages, all tests should be repeated with the typical regional settings expected with each language supported.

Load Testing

Many standard desktop applications exhibit their load on systems during normal use and testing.  However, if your application is expected to be run in an environment using terminal services or Citrix, or if your application includes a web application, service, or any multithreaded functionality, it is very important to test your applications performance under heavy use.  For example, with web applications, you would want to avoid checking the license status or refreshing the license file every time a page is hit.  Likewise, if your application were to be used by hundreds or thousands of users on a single machine via terminal services or Citrix, frequent license validation (especially validation with SOLO Server) could congest system and network resources. Furthermore, if your application supports network floating licensing via semaphore files, it is also very important to test load test this in a realistic simulation before deploying the application to a site.

Regression Testing

As you apply changes, updates, and fixes through its lifecycle, it is important to perform regression tests to ensure that recent changes do not introduce new issues. Although it may not be practical to test everything each time a new build is created, it is best to automate as many tests as possible (often done via unit tests) to help prevent the introduction of new issues.