Problem generating custom license keys

[mctozzy]

Hi,

Currently trialling latest version 16.5 at Enterprise level and having some issues with the registration license key features.

Using your C# test application (under VS2019), all works fine for simpler scenarios, such as serial numbers. Also works with user specific customised license, but only to a point. As soon as we add the Expiration date field to the license, the reg key is no longer accepted, even with a future expiry date. We also set the "Release Date" in the options field to an explicit value of "today" rather than leaving it at default of build date but that made no diff.

I should mention I am testing this is a dev environment by manually copying the trial.dll into place from the AI build, but otherwise not using the actual setup package generated by AI.

A couple of questions:

1. In what circumstances does a new trial.dll have to be transferred to the dev environment when testing the app? So far we determined whenever the library key changes (obviously) or the license format changes, this is necessary. But what other cases?

2. How does trial.dll determine the release date anyway? Or does that end up being baked into trial.dll itself? Or is AI modifying the exe at pkg build time to set a custom property that the dll looks at? Or are there entries being coded into the registry at setup time? (Which means that to fully test this you HAVE to run the setup package.

3. In the online help it says this: when the license is generated, text license elements (the license %ID% and any other user defined license element) will not be able to contain the character that follows them into the license template
Respectfully this does not make a lot of sense, could you explain in a different way including with an example?

Thanks and Kind regards, MT

[mctozzy]

Searched your forum a bit more and found this one. Sounds kind of similar...?

viewtopic.php?f=2&t=40834

[mctozzy]

Just some further info on this problem. I think it was occurring because in dev environment I had not actually used the setup package to install it. Once I used the installer, it must have reset some things in the registry relating to the trial and it then worked correctly, inc installation of the key.

[Catalin]

Hello MT,

First of all, thank you for your followup on this. I am glad you got this working.

Please allow me to answer your questions below:

1. In what circumstances does a new trial.dll have to be transferred to the dev environment when testing the app? So far we determined whenever the library key changes (obviously) or the license format changes, this is necessary. But what other cases?

Answer: Every time an option from the Licencing > Display and Licensing > Registration are changed.

2. How does trial.dll determine the release date anyway? Or does that end up being baked into trial.dll itself? Or is AI modifying the exe at pkg build time to set a custom property that the dll looks at? Or are there entries being coded into the registry at setup time? (Which means that to fully test this you HAVE to run the setup package.

Answer: It is baked into the trial.dll at build time

3. In the online help it says this: when the license is generated, text license elements (the license %ID% and any other user defined license element) will not be able to contain the character that follows them into the license template
Respectfully this does not make a lot of sense, could you explain in a different way including with an example?

Answer: Sure, I can explain this. Let's assume we have the following license format:

Code: Select all

License: %ID% Signature: %SIGN%

In the above sample, the ID element can not contain the space character (the space character is what follows the %ID% element). This is how our algorithm extracts the ID value from the readable license, e.g.:

Code: Select all

ID: John Signature:...

==> ID=John

For instance, in the above sample, an ID such as "John Doe" could not be supported (because it contains a space). However, by default, the character is "new line", therefore in most of the scenarios, this is not an issue. E.g.:

Code: Select all

License: %ID%
Signature: %SIGN%

Now the ID=John Doe is supported.

Hope things are clearer for you now.

Best regards,
Catalin

[mctozzy]

Many thanks for explaining those points. A few followups:

So in fact a sppcific trial.dll is something that gets generated and is associated with every individual release version of a product. If the only thing that effectively had changed was the release date, there's not really anything that actually "locks" that particular "version" of the trial.dll to the version of the app, assuming the licensing library key has not changed.

I guess this feels a bit circular - to properly test the behavior of the expiry stuff in code, you would need to build the app ... generate the install package... copy the new trial.dll back to dev environment ... test it to double check the behavior relating to expiry dates ... and if all good, re-generate the final install package for release?

I believe I saw a reference to AI having a mechanism to detect whether the user was fiddling the clock to defeat the licensing behavior. Is this also a problem in a dev environment, where you may want to genuinely test code paths relating to expiry dates by manipulating the clock date?

Cheers MT

[Catalin]

Hello MT,

First of all, please accept my apologies for the delayed reply.

I guess this feels a bit circular - to properly test the behavior of the expiry stuff in code, you would need to build the app ... generate the install package... copy the new trial.dll back to dev environment ... test it to double check the behavior relating to expiry dates ... and if all good, re-generate the final install package for release?

Indeed, you are right. The process is indeed cumbersome. What can be done here to ease the process would be the automation of the .DLL copy. For instance, you can create a little script which you can schedule as a post-build event ("Builds" page --> "Build Events" tab) which will copy the .DLL file.

I believe I saw a reference to AI having a mechanism to detect whether the user was fiddling the clock to defeat the licensing behavior. Is this also a problem in a dev environment, where you may want to genuinely test code paths relating to expiry dates by manipulating the clock date?

Here, if you want to reset the data, you can launch Advanced Installer elevated --> "Licensing" page --> right click on your trial --> "Testing" --> "Remove Trial Info".

Hope this helps.

Best regards,
Catalin