Install an application ONCE ONLY 2

[amwprogg]

Hi all.
I have an application written in VFP9 and it is installed using the Windows Installer and InstallShield. What I would like to do is make it so you can successfully install the application ONCE ONLY. After successful install the software doesn't install anymore. Is there a code or error sequence I can check for that will give me this info?
Thanks. Andy.

 

[Mike Lewis]

Andy,

Do you mean you want to install it once only on a given computer? Or that there will only be one installed copy anywhere?

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[amwprogg]

Hi Mike.
What I mean is just install the copy ONCE on ANY computer.
Andy.

 

[Mike Lewis]

Andy,

As far as I know, there's no way that you can achieve that via InstallShield. You might need to write a little program that checks to see if the application is already installed, and, if it is, launches InstallShield; if it isn't, it would exit with a polite message.

To check that the application is already installed, the program could check for the presence of the EXE file. Alternatively, you could get InstallShield to create a Registry entry when it has finished, and your program could check that entry is present.

However, this wouldn't prevent a savvy user from deleting the entry, or bypassing your program. Does that matter?

Out of curiosoty, why do you want to do this?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[craigber]

The only way you could do that would be to have some sort of CD key that gets validated on the Internet during install. If that key was already used, don't allow the install to continue. However, there are drawbacks to this scheme. What happens if the user needs to reformat the drive and then reinstall? Restrictive licensing of this type is not in the best interest of your customer.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[amwprogg]

Thanks Mike, Craig.
I'll have to think about this one.
It is true that the customer might install the software and need to remove and reinstall again, for whatever reason, and that would just be a major hassle.
Thanks for your comments.
Andy.

 

[wgcs]

A suggestion: We take the customer's name, and generate a key that matches it.

If they want to share the software, their name goes along with the key they hand out, or else it doesn't work.

Installshield makes it fairly easy to create a DLL that validates the key the user enters during install against the provided username. If your DLL returns the right result, installation continues.. if not, Installshield exits.

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[amwprogg]

Thanks Bill.
Just in case you were wondering, the only reason I am thinking of doing this is to prevent the users from installing multiple copies of the software - you buy one license and you can use it once. I suppose if someone really wanted to make copies they would find some way of doing it.
Thanks for all your suggestions, but I am still not sure the best way to go about this. Still thinking.
Cheers.
Andy.

 

[JRB-Bldr]

There are a number of ways of enforcing License restrictions. None of the following are 100% restrictive, but they support the general idea.

1. Have the application keep a running count (via a table or other means) of the number of users concurrently logged in to the application and do not allow more than the license permits at any one time.

2. Have the application keep and use a Login table which restricts users to not only just a fixed number (#1 above) but also only to those specific users who have been entered by a user with Administrative rights. If you use this approach here is a suggestion - encrypt usernames & passwords so that it is more difficult to hack.

If you combine one of these suggestions with the above suggestion of using the Company Name-specific key you will get a reasonably decent license restriction.

Another suggestion, if you use the Company Name-specific key, make certain that the application displays the Company Name prominently on-screen and/or on reports. In that way, if it should be used elsewhere, it will be an persistent annoyance to the non-authorized user.

Good Luck,
JRB-Bldr

 

[craigber]

I can't recommned option 1 above. That's what SBT does and the administrator has to constantly reset the count because someone didn't log out properly.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[MdotButler]

In your application startup create a variable "_SCREEN.lDemo" and set it to True. Then you do a procedure to see if it should be set to False based on an unlock code (more on that later). In your "Add" button of one of your master tables you would check this variable "_SCREEN.lDemo" and if True the program prevents them from adding any more records. This basically disables the usefulness of the application and you can now send out your application and it workes as a demo.

Now to fully enable the application you need to create a scheme to flip the "_SCREEN.lDemo" variable. By unlock I mean that you create a private hash using the customer name and some machine specific criteria. Many use the NIC card MAC address or the machine name. The customer would call you to unlock the application supplying the company name and machine name if that is what you decide to use. You would provide an unlock key based on the customer name and machine name that they would enter and would be stored in a table in your application. Now all you have to do is rehash the customer name and the machine name and check it against the unlock code. If they match, set _SCREEN.lDemo to False and away you go. The customer just has to remember the unlock code you gave them and now it is machine specific.

Low tech but it works great.

HTH