Activating the same product with different keys on the same pc/account

Hey Hubert,

You can use 2 separate product keys on the same computer so long as 2 conditions have been met:

1. You use TA_USER for CheckAndSavePKey() and for UseTrial() if youi're using the trial functionality
2. The product keys are used under different user accounts on the computer.

Also, if you ever use TA_SYSTEM (or use the TurboActivate wizard without using the --userlevel flag) then that sets the system to *always* use system-level product keys (and/or trials). Meaning after you use TA_SYSTEM on a computer, and it succeeds, then it will always use TA_SYSTEM from that point on.

Does that make sense?

Hi,

Yes I understand what you mean.

Just to clarify. It is not possible to install the same product on the same account multiple times with different keys.

If so, is there a plan to change this behavior in the near future?

Hubert

It is not possible to install the same product on the same account multiple times with different keys.

Well, it is possible (using the SetCustomActDataPath() function).

The question is, why do you want to do this? What are you trying to accomplish? Maybe I can give you better solution to the problem.

I tried to use the SetCustomActDataPath, but did not get it to work.

Well the primary reason that I want this is because it is in our requirements. We need to be able to install multiple versions of the same product on the same user account.

The customer does not want top have many different products so we managed to cut is down to just 2 products. However there are multiple profiles defined in those products.

For example. We have a profile that has the complete product, that can be used by our customer to create files for factory workers. We also have a profile for factory users that can only load these files and execute them. These profiles are loaded by the license that is used, to activate them.

To make sure that the file that is created for the factory users is valid, the person who created the file can test it in the factory tool. Therefor it needs to have the same product installed multiple times with different keys

I tried to use the SetCustomActDataPath, but did not get it to work.

What happened? What error code did you get? Did you call it before you called any other function (you must)? Did you read the details of the function:

This function allows you to set a custom folder to store the activationdata files. For normal use we do not recommend you use this function.


Only use this function if you absolutely must store data into a separatefolder. For example if your application runs on a USB drive and can't writeany files to the main disk, then you can use this function to save the activationdata files to a directory on the USB disk.


If you are using this function (which we only recommend for very special use-cases)then you must call this function on every start of your program at the very top ofyour app before any other functions are called.


The directory you pass in must already exist. And the process using TurboActivatemust have permission to create, write, and delete files in that directory.




Returns: TA_OK on success. Handle all other return codes as failures.


Possible return codes: TA_OK, TA_FAIL, TA_E_PDETS

But it sounds like you're creating 2 separate products (or 2 build of a product). In which case just create 2 products in LimeLM, and use the separate TurboActivate.dat for each separate product.

For example. We have a profile that has the complete product, that can be used by our customer to create files for factory workers. We also have a profile for factory users that can only load these files and execute them. These profiles are loaded by the license that is used, to activate them.

This still sounds like it would be best if you used a single product key for your app. The reason why is that this could be solved much easier by the administrator that will be installing your software. Or by your software itself.

As it is now you have some way to identify "regular users" and "workers", correct? That is, how do you know which group has access to which part of your app?

I read the comments on the code that it needed to be called before any other calls were made to the dll. I did this. However the code does not have return codes as you mentioned. It only has the exceptions ProductDetailsException and TurboActivateException.

Since neither of these errors are thrown I assume everything went fine.

However activating with different keys still changes it for all installations. Is this related to the TA_SYSTEM and TA_USER?

(Also i noticed if you call the PDetsFromPath after SetCustomActDataPath the dll crashes )

I know it sounds that there are two products, but still you start the same program. We just limit the functionality.

>>As it is now you have some way to identify "regular users" and "workers", correct? That is, how do you know >>which group has access to which part of your app?

At the moment we just use build flags in our code (rather ugly but it works). We then just send multiple app.exe to the customer. We want to remove the build flags and with licensing this could be solved if we just get it to work 😀

(Also i noticed if you call the PDetsFromPath after SetCustomActDataPath the dll crashes )

We can't reproduce that here. What's the exact crash? What language are you using (Java, C#, C, C++)? Can you give a snippet of code that reproduces the crash?

I know it sounds that there are two products, but still you start the same program. We just limit the functionality.

Right, you don't need to have separate exes to have separate products or versions in LimeLM.

So you have a few ways of solving this problem:

Solution 1:

1. Create separate products and/or versions inside LimeLM. For example YourApp Worker Edition & YourApp Admin Edition (or whatever you want to call them).
2. Download the TurboActivate.dat for each separate version.
3. In your app use PDetsFromPath("C:\\Location\\To\\TurboActivate.dat") to distinguish between "Worker Edition" and "Admin Edition".

Solution 2:

1. Have a single product version for your app (with a single TurboActivate.dat).
2. Make any calls to PDetsFromPath() if you need to.
3. Create the folder that will store the activatin data
4. Use SetCustomActDataPath("C:\\Location\\To\\Your\\Activation\\Data")
5. Normal activation workflow.

In Solution 2 you cannot use the TurboActivate wizard (TurboActivate.exe) because it doesn't support custom activation paths, and thus will try to write user-wide or system-wide. This means you'll have to implement your own form that asks for the product key and activates.

I'm using C#, when I execute this, then the program will crash with a TurboActivateException with the message (The TurboActivate.dat file has already been loaded. You must call this function only once and before any other TurboActivate function.)

        internal TurboActivateAdapter(string versionGuid, PrivilegesBase decoratedPrivileges, string licenseLocation)            : base(decoratedPrivileges)        {            //TurboActivate.PDetsFromPath(Path.Combine(licenseLocation, "TurboActivate.dat"));            TurboActivate.SetCustomActDataPath(licenseLocation);            TurboActivate.PDetsFromPath(Path.Combine(licenseLocation, "TurboActivate.dat"));            TurboActivate.VersionGUID = versionGuid;            Initialize();        }

Also we got out product owner to drop the requirement of the original issue