Is it OK to use Reset in release builds?

Our license check flow is as follows:

1. In our app we check if the user has an activated license (IsLicenseGenuine).
2. If not, we fall back to any trial the user had activated before (IsTrialGenuine).
3. If the trial has expired too, or if there is an error with the trial, or if no trial has been started yet, then we run our app in demo mode.

However, what to do if the user has started a trial, activated his license halfway that trial, then updated his hardware, and then deactivates his license? In that case IsTrialGenuine returns LA_E_MACHINE_FINGERPRINT. Right now we automatically fall back to demo mode (option 3) above since it’s an error, but we find this undesirable. We’re deliberating if we’d rather reset the trial in that case for a better user experience – I know that the worst thing that could happen is that users will be able to reactivate trials over and over by updating their hardware. Or maybe we could first read out / remember the remaining trial days and start a new trial with that many days left.

I could use LexActivator’s Reset function for this, but:

• This also resets any license state, which doesn’t matter since we’re in a trial state anyway.
• Reset is labeled for development builds only. Is it safe to use in release builds in this way?

Hi Carl,

It is safe to use Reset() but I would recommend that whenever you get fingerprint error you should treat the machine as a new machine and use the flow which you would have used in case of the new machine. In this case you will simply call ActivateTrial() again.

Hi Adnan,

Thanks for the suggestion!

I had a testing machine on my hands which had a year-old expired trial and some major hardware changes since then, so I added an ActivateTrial into the mix after I got LA_E_MACHINE_FINGERPRINT back from IsTrialGenuine. The result is that a new trial has been started, and all meta data of the previous trial have been copied over automatically too, which is a very nice bonus!

However, one part of the meta data we track is the original trial start date. In our dialogs we show the trial’s length, which is basically GetTrialExpiryDate() - GetTrialActivationMetadata('startDate'). This way we can always change the trial length for new trials while still showing the correct historical length for already started trials. But: calling ActivateTrial in this situation starts a genuine new full-length trial but with the old start date, so the reported trial length is waaay high :slight_smile:

I’d like to know if I could start a trial with a forced trial length (preferably also negative), so that I can make the new trial a proper continuation of the previous one.

If not then I guess the next best thing is to first update the trial start date in the meta data (set it to Now) before calling ActivateTrial again, so that the user effectively starts a true new trial period without any weirdness in our GUI.

This will however make it possible for malicious users to restart trials indefinitely, but for virtual machines this is already possible I guess, and I hope that changing the hardware fingerprint enough when running on real hardware entails too much effort so that most would not bother with it?

Hi Carl,

ActivateTrial() would only consider the length in your trial policy.

I’d like to know if I could start a trial with a forced trial length (preferably also negative), so that I can make the new trial a proper continuation of the previous one.

That won’t be possible.