This article describes an easy approach to keeping track of each installation of an application. The intent of the example is to demonstrate the use of a simple web service to collect and store information about each user and machine running the application.
I was originally driven to coming up with something like this in response to working for an employer that operated strictly on the honor system. By that, I mean that the company would sell its software by the seat to individual clients, but with no licensing or other restrictions imposed or enforced by the software that might prevent the installation of additional copies of that software; for example, if a client purchased five seats of the product, it was assumed by the company that the client would only install it five times.
In one particular sale of the product, I felt that it was likely that the client would install additional copies beyond what they had purchased (given the magnitude of work they had to perform, five seats seemed woefully inadequate), and I had asked for approval to implement a licensing scheme in the code; the company declined to do this for whatever reason. They did agree for me to devise a method for tracking installations without requiring a license. The code in this project is a derivation of what I did there, mainly because, in the original approach, I was not permitted to terminate the application if it were not registered; I was only able to collect information on the installations. What we discovered was that the five purchased seats were installed over 100 times by the client (at about a $380,000 loss in revenue to the company in this one instance).
When I wrote this example version, I did it a little differently in that I create a bogus registry entry that is used to determine whether or not the application was installed and registered through the web service. If the product is not registered, I prevent the application from being used. When I terminate the application, I inform the user that the registration process is incomplete and that the process requires an active connection to the internet. This works much like what is seen when you are required to, for example, activate a copy of Microsoft Word through an internet connection. The registry key is checked each time the application is executed; if the registry key exists and its value indicates that the product is registered, then nothing else happens; if that is not the case, the application will not run until the registration occurs. If a person were to X-copy the application onto another machine, the application will still check for the key the first time it is executed, and therefore it will not run until it is also registered.
I did not use it in this example, but you could use the original installation date and allow the user to use the product for some set period of days prior to locking them out, which could be useful if you are authoring shareware with a time limited trial period. Here in this example, I just lock them out from the beginning. This approach does not prevent the client from over-installing the product; it merely forces each installation to be registered through the web service. You could easily modify the web service to check and see if an individual license has been registered and prevent additional installations of that license, but for the purposes of this example, I am only demonstrating the capture of each installation through the service.
As it stands, the example is not the be-all, end-all solution to securing your application against theft. It does, however, offer an approach for determining the extent of abuse you may be encountering with a release of custom software to a client company. That information may be useful in making an argument for building a more robust approach to licensing your distributions.
To get started, unzip the source code included with this project. In the code example, you will find a web service and a WinForms application. Open the Web Service up, and make any changes necessary to get it to operate on your machine. The project containing the web service has an MS Access database included, and the database contains a single table used to collect the installation information. In reality, you’d probably configure a database and table in SQL Server or Oracle to contain the data, but for the purposes of this demonstration, it was easier to pack it up in Access. Aside from the MS Access database, you will note that the web service project only contains a single service entitled, “RegisterInstallation”.
Once you’ve configured the web service, run it and check it with the proxy to validate that it is updating the database correctly:
Figure 1: Run the Web Service
With the web service running, select the link to “RegisterInstallation”:
Figure 2: Testing the “RegisterInstallation” Web Service
Once you’ve keyed in some sample values as indicated in Figure 2, click on the “Invoke” button and view the response; if successful, you should see something like what is shown in Figure 3:
Figure 3: The Web Service returns “true” if the installation information is saved to the database
Given the web service has returned a true, take a look at the database to confirm that the values entered have been stored in the table:
Figure 4: The AppInstallers table updated by the Web Service
Having confirmed that the web service is up and running, open the application solution in Visual Studio 2005. Examine the contents of the project in the Solution Explorer, you should see the following:
Figure 5: RegTest application solution content
Within the solution, note that the registration service has been added as a web reference; you will likely need to update this reference. The app.config file is the default version, and can be ignored here. The classes worthy of note are
RegistrationCheck. The main form class (
frmMain) represents your application, and the registration check class is used to capture information about the machine containing the application and package up for submittal to the registration web service.
Assuming that the web service and the project references check out, we can now take a look at the code.
Code: Web Service Project – Registration Service
Locate the RegistrationService.asmx file contained in the “RegistrationSvc” web service solution, and open it up in the IDE. You will note that this is a very simple service, and in general, all that it does is expose a function entitled “
RegisterInstallation”. This function receives a collection of arguments containing the information about the installer, and formats and executes an
INSERT query against the MS Access database used to contain the installer information.
The imports section of the code in this class has been amended to include the portions of the
System.Data library that pertain to the use of an OLEDB data source:
Public Class Service
The class declaration is cleverly called “Service”, and the attributes applied to the class are also in the default configuration, with the exception of the updated namespace. The only function in the service exposed as a web method is the
RegisterInstallation function; its code is as follows:
Public Function RegisterInstallation(ByVal strDomainAndUser As String, _
ByVal strComputerName As String, _
ByVal strApplication As String, _
ByVal strVersion As String, _
ByVal strAppID As String, _
ByVal strInstallDate As String) As
Dim conn As OleDbConnection = New _
OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=c:\inetpub\wwwroot\RegistrationSvc\Registration.mdb;" & _
Dim strBuilder As New System.Text.StringBuilder
strBuilder.Append("INSERT INTO AppInstallers ")
strBuilder.Append("(DomainAndUser, ComputerName, _
Application, Version, AppID, _
strBuilder.Append("'" & strDomainAndUser & "', ")
strBuilder.Append("'" & strComputerName & "', ")
strBuilder.Append("'" & strApplication & "', ")
strBuilder.Append("'" & strVersion & "', ")
strBuilder.Append("'" & strAppID & "', ")
strBuilder.Append("'" & strInstallDate & "')")
Dim sSQL As String = strBuilder.ToString()
Dim cmd As OleDbCommand = New OleDbCommand(sSQL, conn)
Catch ex As Exception
Catch ex As Exception
This function is pretty straightforward; the arguments detailing the installer’s information are passed as arguments to the function. The function then takes the arguments directly, and passes them to an
INSERT query against the MS Access database. Once the execution of the
INSERT statement has completed, the function returns a
Boolean set to
True if the data is passed to the database, or
False if the operation fails to update the database.
That is all there is to the web service; the calling application will gather the user’s information and, if appropriate, connect to the web service and post the data to the database used to house the installer information.
One point to make here is with regards to the setting of the installation date; in this example, the value is passed into the web method from the client. If you are interested in creating a grace period for using the application (e.g., allow the user to use the application for 30 days without registering it), you may wish to set this value on the server side instead of the client. This will prevent the user from changing the date on their machine to gain additional, free use of the application.
Next, open the “RegTest” solution in the IDE, and we can take a look at that.
Code: RegistrationCheck Class
First off, open the “
RegistrationCheck” class in the code window. You will note that the class contains two subroutines and one function. The
Imports statements and the class declaration are as follows:
Public Class RegistrationCheck
By importing the “
SystemInformation” library, we are able to capture the information used to identify the machine and the user running the application. This will provide us with the source for the arguments passed to the web service.
Now, take a look at the function, “
CheckProductRegistration”. This function is
Public, and is the means by which the application checks for prior registrations and then gathers and submits data to the web service during the initialization of an unregistered version of the application. The code for this function is as follows:
Public Function CheckProductRegistration() As Boolean
Dim blnIsRegistered As Boolean = False
Dim key As Microsoft.Win32.RegistryKey
key = _
If (Not key Is Nothing) Then
Dim intVal As Integer = _
If intVal = 0 Then
blnIsRegistered = False
ElseIf intVal = 1 Then
blnIsRegistered = True
blnIsRegistered = False
If blnIsRegistered = False Then
Dim strUser As String
strUser = _
Dim strDomain As String
strDomain = _
Dim strDomainAndUser As String = strDomain & "\" & strUser
Dim strComputerName As String
strComputerName = _
Dim ws As New RegistrationService.Service
Dim blnTest As Boolean = False
blnTest = _
"RegTest", "1.0", _
If blnTest = True Then
The first thing this function does is call a private subroutine used to check for the existence of the registry key used to check for prior registrations of the application. If the key does not exist (first use), the key will be created in the subroutine. The key used, "SOFTWARE\\DA\\SOMLA\\1.0", is just some nonsense used to throw someone off if they were to try to find and manually edit the key value used to determine whether or not the application has been registered. As I mention in the comments, SOMLA is an application dating back to the 1980’s; it was used to run analysis of the effects of a crash upon the human spine. “DA” is for district attorney. You can change these values to whatever you want, but you should make some effort to conceal the purpose of the key and its value.
Next, the function gets the value of the key used to mark the application as having successfully been submitted to the registration web service; if the value indicates that the application has not been registered or activated through the service, it sets a
Boolean is then tested, and if it is
False, the function will attempt to gather the user’s information and submit it to the web service for registration. If the product is then registered, the calling method is notified of the success, and the registry value is updated to indicate that the product has been activated through the service. If the
False, the user is booted out of the application, else the user is granted access to the application.
The two subroutines in this class are merely used to support the function by creating or confirming the existence of a registry key, and by allowing the function to set the key value associated with the registration of the application. The code for these two subroutines is as follows:
Private Sub CheckForOrMakeRegKey()
Dim regVersion As Microsoft.Win32.RegistryKey
regVersion = Microsoft.Win32.Registry.CurrentUser.OpenSubKey _
If regVersion Is Nothing Then
regVersion = _
Private Sub CreateKeyAndSetValue(ByVal intVal As Integer)
Dim regVersionKey As Microsoft.Win32.RegistryKey
regVersionKey = Microsoft.Win32.Registry.CurrentUser.OpenSubKey _
If (Not regVersionKey Is Nothing) Then
That concludes the discussion of the contents of this class. Next, open up the main form (frmMain.vb) class into the code window. The only item worthy of note in the main form’s code is the handler for the
Private Sub frmMain_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim rc As New RegistrationCheck
Dim bln As Boolean
bln = rc.CheckProductRegistration()
If bln = False Then
MessageBox.Show("You have not registered this " & _
"product. Registration requires " & _
"internet access.", "Registration Failed", _
This code is pretty simple; it merely creates an instance of the “
RegistrationCheck” class, sets a
Boolean variable to capture the results of the attempt to register the product, and then processes the evaluation of the returned
Boolean. If the
False, the user is notified that product activation requires an internet connection, and then the application is terminated if activation has not occurred. The user will continue to be met with this response until they permit the application to connect to the internet and subsequently activate the product.
Naturally, you can modify what occurs in response to a failed activation. For example, if you want to let the user use the product for thirty days after the original installation, you could amend the web service to return the initial installation date, and compare that date to today’s date and then decide whether or not to allow them to use the application.
The sample application and web service are meant to convey an approach to activating a product. This is not a particularly robust way of doing it, and it certainly is not foolproof. The approach could easily be compromised if the user were able to locate and manually edit the registry value. The approach does show you a general approach to product activation, and is a good way of collecting specific information about who is using the software, and determining which uniquely marked copy of the software the installer/user is running on a specific machine.