It sounds like the end-result you're shooting for is to give a user new feature values. You don't need to generate a new product key to do that. You don't even need to deactivate the user. Just change the features in LimeLM, re-activate the user, the let TurboActivate handle the rest.
Deactivating by file UI
FelixHi,
We would like to give our users the possibility to change the product key / to reactivate the application with another key (to have other license features etc.)In an online environment this is working well with Deactivate(false) and reactivation afterwards.Our problem is that some clients absolutely dont have online access so the deactivation should be offline / file based.This leads to two problems --> - we will have to implement ourselves a UI for the file-deactivation. (writing the deactivation request file, accepting the deactivation request file)- quite complicated for the clients --> the have to deactivate file based and reactivate file based...
Now my questions to ease this up a bit:Is there another possibility to do something like revoking the key client side (without online deactivation) which lets the client fall back in the unactivated state --> he will be able to regenerate a new activation-request file with Turoactivate.exe? Or can TurboActivate.exe be called with parameters so it allows to change the product key? (now as the product is activated it just shows the "Product activated successfully" screen)
Thanks in advance.
Felix
Felixbut that means that in any way i cant reuse the TurboActivate.exe as UI?--> as long as the application is activated on the client i cant activate with another key (using turboactivate)
You can't re-activate using the TurboActivate wizard. Perhaps we should add that as an option. You'll have to implement the re-activation GUI in your app.
FelixOr would there be any way to remove the activation from the client PC (without deactivation)
- revoking client side over the API?- removing the registry key directly? <-- really not my preferred one but in worst case it has to be done.
I'm not quite sure why you would want to do that. Can you explain, more broadly, what you're trying to accomplish?
FelixGeneral idea:Customers can buy the app for some time (not the update possibility, the right to use the software)So we prepare him a key with a license feature (expiration date of his license)
He activates (online or offline) and everything works well.
Some time later his subscription runs out, the software realizes (based on the license feature), and locks itself (all menu's except activation) --> he should be able to reactivate the product using another key (or the same, after we changed the expiration date in LimeLM)--> in an online environment no problem as I can call Deactivate() and run TurboActivate to restart the whole activation process--> offline (on clients which will _never_ go online) I dont arrive to reactivate the software as TurboActivate tells me "Activation successful" which is true.
Now my possibilities:- I find an easy solutions to "reject" the activation when I find out that the subscription period ran out. --> Would be great as I could use TurboActivate in all cases- I implement the GUI for manual deactivation --> Low work load but absolutely uncomfortable for the client (2-way for deactivation, 2-way for activation)- I implement the GUI for - setting another product key - do the manual 2-way activation to overwrite the actual activation (will this work or will i have something like an AlreadyActivatedException?) --> Medium work load and finally the client has not the same GUI for first time activation (via TurboActivate) and second activation...- I implement the whole TurboActivate functionality myself with the possibility to Activate while its already activated -> Great, covered all possibilities, user has my UI style, but a lot to do...
Was that clear?Any propositions are highly welcome 🙂
Felix
--> in an online environment no problem as I can call Deactivate() and run TurboActivate to restart the whole activation process
No, in an online activation environment you just call Activate() again. No need to take unnecessary steps like deactivating first. TurboActivate is smart enough to know what you're doing.
We can add a switch to the TurboActivate wizard like "--reactivate" that let's the user reactivate using the regular UI. Would that work for you?