How to protect non-visual components and services

Managing a license for a desktop application is straightforward because you always have a user interface where the user can enter a license key, activate, and see status messages. That is not the case when the software you need to protect is a component, a DLL, or a Windows service that has no user interface of its own. This article explains how to license and protect non-visual software, and how to give your customers a reliable way to provide and manage their license even when your protected code never shows a window.

What counts as non-visual software

Non-visual software is any code that runs without presenting its own user interface to the person installing or activating it. Common examples include:

• Class libraries, components, and DLLs that are consumed by another application or by a developer's own code.
• Windows services and background daemons that start automatically and run without a logged-in user.
• Plug-ins, add-ins, and extensions that load inside a host application you do not control.
• Command-line tools, build-time components, and server-side modules.

In each of these cases the protected code still needs to read a license, verify that it is valid, and (where applicable) activate against SOLO Server. The challenge is that there is no obvious place for the end user to type a license key or click an Activate button.

The core principle: separate licensing from the user interface

The key to licensing non-visual software is to recognize that the license itself does not depend on a user interface. With Protection PLUS 5 SDK, the license is stored in a license file that your protected code reads at runtime. Loading the license, checking that it is valid, and enforcing the result are all operations your component or service can perform silently in code.

What a non-visual component cannot easily do on its own is collect the license key, run the activation, or report problems to a human. So the recommended pattern is to split the job into two parts:

1. The protected component or service reads and validates the license silently at runtime.
2. A separate, visible piece of software handles the human-facing tasks of entering the license, activating, deactivating, and showing status.

This separation lets you protect code that has no interface while still giving customers a clear way to manage their license.

Recommended approaches

1. Provide a separate license manager application

Ship a small companion application (a setup utility, configuration tool, or dedicated license manager) that presents the user interface your component lacks. This application collects the license key or activation credentials, performs the online or manual activation, and writes the resulting license file to a shared location. Your non-visual component or service then reads that same license file at runtime.

This is the most common and most flexible approach. The companion tool can be installed alongside the component, run once during setup, and re-run later whenever the customer needs to re-activate, move the license to a new machine, or check status.

2. Activate during installation

If your component is delivered through an installer, you can perform activation as part of the install process. The installer (or a custom action it runs) collects the license key, activates against SOLO Server, and places the license file where the component expects it. The component then starts already licensed, with no further interaction required from the user.

This works well when the license is known at install time and the machine has network access during installation.

3. Pre-deliver the license file

For some distribution models you can generate the license on SOLO Server and deliver the license file directly to the customer or embed it in the deployment. The non-visual component reads the pre-delivered license file at startup. This avoids any interactive activation step, which is useful for unattended or automated deployments.

Special considerations for Windows services

Windows services need extra attention because they typically run under a service account, not the interactive user's account, and they start before anyone logs in.

• Store the license file in a location both the service account and your management tool can access. A machine-wide path under ProgramData is usually a better choice than a per-user location, because a per-user path may not be readable by the service account.
• Make sure the account the service runs under has read access to the license file, and that the tool used to activate has write access to the same path.
• Do the licensing check when the service starts, and decide in advance how the service should behave if the license is missing, expired, or invalid (for example, refuse to start, run in a limited mode, or log an error). Because there is no user to notify, write a clear message to the event log or your own log file so the problem can be diagnosed.

Handling activation and status without a UI

Even though the component itself is silent, plan for the full license lifecycle:

• Activation and deactivation: provide these through the companion application or installer so customers can move a license between machines.
• Renewal and re-validation: if you use subscriptions or trials, decide how and when the component re-checks the license and how the customer is prompted to renew (typically through the companion tool, not the silent component).
• Error reporting: log licensing failures somewhere a human or an administrator can find them, since the component cannot show a dialog.

Summary

Protecting non-visual software comes down to keeping the silent runtime license check separate from the human-facing license management. Let your component, DLL, or service read and validate the license file quietly at runtime, and provide a companion application, an installer step, or a pre-delivered license file to handle entering the key, activating, and reporting status. With that pattern you can protect code that has no user interface of its own while still giving customers a reliable way to manage their license.

For implementation details, see the Protection PLUS 5 SDK manual at https://www.softwarekey.com/help/plus5/ and the SOLO Server manual at https://secure.softwarekey.com/solo/authors/manual/.