How to Secure My ActiveX Control (OCX) Using License

[evry1falls]

Hello,
I have created a custom ActiveX control for sale and i want to secure it b4 deploying it using license.
I have noticed that in the (Project Properties) of the ActiveX Control Project there is an Option button called (Require a License) but i have no idea how to use it.
any suggestions ?!

[dilettante]

Have you cracked open the manual yet? It has a discussion of this subject in the section Licensing Issues for Controls.

[evry1falls]

I have read it, but it doesn't mention how to do it !
i could do it by code, but i really need the license method

[dilettante]

Hmm...

To add licensing support to your control project

On the Project menu, click <MyProject> Properties to open the Project Properties dialog box. Select the General tab, check Require License Key, then click OK.

When you make the .ocx file, Visual Basic will create a .vbl file containing the registry key for licensing your control component. When you use the Package and Deployment wizard to create a setup for your .ocx, the .vbl file is automatically included in the setup procedure.

[evry1falls]

Ok, now you want to provide the buyer with the license, how to accomplish that ?!

[IanS]

You could do it yourself something like this:-

During installation on the developer's (your customer's) computer write some data such as trial period start/end dates to the registry.

In UserControl_Initialize() Check the following:-
(a) is it installed using your installer? (Does the reg data exist?)
and then
(b) use UserControl.Ambient.UserMode to decide if the ocx is being used in an IDE (Will be false if the ocx is being used in an IDE)

If it's in the IDE and it wasn't installed using your installer then display a message and limit functionality.
If it's in the IDE and it was installed with with your installer but the trial has expired then display a message and limit functionality.

In the OCX add an 'About' form which the user can open via the properties window in the IDE. That about form can display some copyright information and also accept an activation code which you send to your customer once he's purchased your OCX. You store the activation code in the registry.

So, as well as (a) and (b) above you also check (c) does a full activation code exist in the registry and if it does you don't display any messages at all.

because all this is dependent on Ambient.UserMode being false none of this will ever execute on an end user's computer. All you're interested in is making sure that developers pay for your OCX when they use it in the IDE. You don't want to bother end users of the OCX.

Also note that I said 'Limit functionality'. Don't refuse to run completely because it can clogg up the IDE preventing the developer from opening the project at all and he'll be jolly angry indeed.

Also, don't spend too long worrying about protecting it from hackers. if it's a good OCX it will be hacked no matter how good your protection is and it will appear on all those crack sites. If that causes you sleepless nights then change your job.

[IanS]

You posted this in the VB6 forum so I assume your OCX is written in VB6 so also bear in mind that your OCX has VB6 dependencies. If your developer/customer is NOT using VB6 to develop his own product, maybe he's using C or Delphi, then he will have problems when he comes to deploy his product unless he also deploys the VB6 runtimes or 'his' customer already has the VB6 runtime installed.

[dilettante]

Ok, now you want to provide the buyer with the license, how to accomplish that ?!

The license is included in the setup package. You only provide the setup package to paying customers.

But some paying customers are not honest, and many non-paying customers even less so. This means that without additional precautions your setup package will find its way to warez-land.

Protecting against theft of licensed software is a game with limitations. Given enough effort people will find a way around any scheme you devise, so the most you can do is expend enough effort on a scheme to discourage easy theft.


The only mechanism available using the PDW itself is to create a customized version of Setup1.exe that prompts for and verifies something like a "product key" that you provide to paying customers. Setup1 is written in VB6 and you have the source for the standard version on your development machine already. Usually it is someplace like:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Setup1

Alternatively you could use the Visual Studio 6.0 Installer 1.1 which Microsoft provided as a replacement for the PDW back in 1999.

VSI 1.1 has a installation dialog that can request a "serial number" or "product key" during installation of your product. You need to write a custom action (C DLL, VBScript, etc. but not VB6) to validate this key and include that in the package.

How To Validate a Serial Number During an Installation Created with VSI covers this topic.

It turns out that you can tweak the .MSI package produced by VSI 1.1 so that it can run a VB6 program to validate the product key though. I wrote about that back in 2005 in: Eureka?


You can also shop around for a 3rd party packaging tool that provides for product keys. I don't think there are any free ones that do this though.

Some people also wrap up their setup package in a self-extracting archive that accepts passwords or product keys. Some of these are simple: one password fits all customers. Others are more complex and may accept a list of possible passwords you can give out, and others still will do fancy "phone home" network conversations with a server somewhere to make sure a key can only be used once.

[dilettante]

You posted this in the VB6 forum so I assume your OCX is written in VB6 so also bear in mind that your OCX has VB6 dependencies. If your developer/customer is NOT using VB6 to develop his own product, maybe he's using C or Delphi, then he will have problems when he comes to deploy his product unless he also deploys the VB6 runtimes or 'his' customer already has the VB6 runtime installed.

VB6 runtimes are a preinstalled part of the OS from Windows 2000 SP3 onward. I have also recently determined that a fresh install of Windows 95 OSR2 even has the VB6 runtimes preinstalled.

You can esily package current versions for deployment if necessary.

This is a red herring.

[IanS]

I just mentioned the runtimes because I used to deploy a couple of OCXs that required the VB6 runtimes and even now, years later, I still get the odd developer shouting at me that 'his' product doesn't work because he deployed his product to somebody who didn't have the VB6 runtimes and it's all my fault. (even though my ocx documentation explains as clear as can be what the dependencies are).

[dilettante]

Pretty bizarre then.

I haven't found a Windows version other than Windows 95A & B and Windows 98 (not 98SE) that do not already have the VB6 runtimes. I suppose there might be a few out there, but as I said the runtimes are deployable and free to anyone.

Hard to picture a C program being able to use an OCX created in VB6. Delphi people can suck wind for all I care.