Deactivation can occur one of two ways: you may allow customers to deactivate from your application, or you can remotely deactivate a license or an activation using SOLO Server's administrative interface.
It is very important to rely on background checking and refreshing when allowing users to deactivate your application! Automated background checking helps prevent users from licensing more systems than intended by restoring the entire system/computer from an image or snapshot taken before deactivation occurred.
In either case, when your application deactivates its license, or runs a background check or refreshes its license and detects that it has been deactivated, it can then disable access to the application or certain features.
Be mindful about whether or not disabling access to your application is appropriate. For example, if your application requires high availability (such as a web application or service) and/or your application serves some mission-critical function, it may be more appropriate to have your application display nag messages and/or disable only non-critical features so as to avoid disrupting your customers' business or operation.
Allowing your customers to deactivate individual activations online is a convenience to them that also reduces your support overhead. Since deactivating allows users to activate a new system, this is a very simple and convenient way for your customers to essentially migrate (or transfer) the license from one system to another. An example of when a customer would want to use this functionality would be when he or she is upgrading from one computer to another.
Note how this example code deletes the license when the deactivation is successful. This is because the license should be considered invalid when the application has been deactivated. Deleting the license file is an appropriate response to these result codes for read-only License implementations. However, when using WritableLicense implementations, you should alter the local license file in-code as appropriate for your licensing requirements, and save it and its aliases.
There may be cases where a user does not have direct access to the Internet, yet there is a requirement to allow license deactivations. In these cases, a manual deactivation can be performed. To perform a deactivation, it’s nearly identical to doing manual activations, except you’ll use GetDeactivateInstallationRequest to generate the request data the user will copy to a system with Internet access, then use ProcessDeactivateInstallationResponse to process the response data.
Manual deactivations are not recommended as there is no guarantee a user will return the response data to the client. This would allow them to free up an activation in SOLO Server without deactivating the local client license.