ThinkGeo.com    |     Documentation    |     Premium Support

Issues generating License file?

Hi support.

We have been using WmsServer for a few years now and for “reasons” we are still using v10.6.1.
We deploy our software in offline environments, and we “license” the app at install time, generating the license file from an MSI install via cmd line.

Recently we have encountered a scenario where, in some machines, the installation of our product is producing a thinkGeo license file which seems to be invalid.

To be specific: the lic file is created, and it has similar contents when compared to other machines “which work” (string with some 3700+ chars).

Still, these problematic machines produce white tiles with the waterMark “not license for runtime”

The creation of the lic file returns no errors.
Looking through the docos just now, I same across an API to check the license status

https://docs.thinkgeo.com/products/thinkgeo-core/ThinkGeo.Core/ThinkGeo.Core.ThinkGeoProductLicense/#thinkgeoproductlicense_1

From a console App I am calling all methods in that API now and even in “working systems” the APi returns “None” as in the output below:

C:\Users\Administrator\Desktop\Tool\net80>LicenseStatusValidator.exe
Hello, World!
GetCoreLicenseStatus: 'None'
GetWinformsLicenseStatus: 'None'
GetWpfLicenseStatus: 'None'
GetBlazorLicenseStatus: 'None'
GetBlazorServerLicenseStatus: 'None'
GetWebApiLicenseStatus: 'None'
GetWebApiServerLicenseStatus: 'None'
GetiOSLicenseStatus: 'None'
GetAndroidLicenseStatus: 'None'
GetXamarinFormsLicenseStatus: 'None'

C:\Users\Administrator\Desktop\Tool\net80>

We are seeking help to understand 2 things:

  1. What could be going wrong when we create the license file? In one of the broken systems we ended up installing an old .NET version (4.6.2) and after that the lic file seems to be generated with contents which do not produce the watermark. If a missing framework was the issue I’d expect an exception being thrown but instead I still get a file with some 3700+ chars which I cannot tell if it is “good” or “bad”.

  2. Why are we always getting LicenseStatus: 'None' even from systems which are working as intended? I must be missing something obvious.This is the line calling the API to get the status:

Console.WriteLine($"GetCoreLicenseStatus: '{ThinkGeo.Core.ThinkGeoProductLicense.GetCoreLicenseStatus()}'");

Thanks for your help,
Ed.

Hi Ed,

I got some questions for you:

  1. How is the ThinkGeo runtime license file created? Is this by a customized offline license generator we sent over to you before?
  2. Can you send me a lic file that doesn’t work, as well as a working lic? You can either upload them here or send over to support@thinkgeo.com
  3. It is a surprise to me that installing .net 4.6.2 would fix the issue. We didn’t require any specific version of .NET framework in the code, chances are there’re some functional breaking changes between .NET versions.
  4. Regarding GetCoreLicenseStatus() is returning ‘None’, it could be a bug, or we treated WMSServer in a different way. I can get a better idea after having your lic files.

Thanks,
Ben

Hi Ben,

Thanks for the quick reply.
I’ve sent the files via email to “support@thinkgeo.com

  1. How is the ThinkGeo runtime license file created? Is this by a customized offline license generator we sent over to you before?

Yes. There is a DLL we use, ServerDeploymentInstaller.dll.
Decompiling gives me the file “ServerInstaller.cs” as an entry point, sent via email.
Seems to be the entry point of it all.

  1. Can you send me a lic file that doesn’t work, as well as a working lic? You can either upload them here or send over to support@thinkgeo.com

Yep. Sent via email

  1. It is a surprise to me that installing .net 4.6.2 would fix the issue. We didn’t require any specific version of .NET framework in the code, chances are there’re some functional breaking changes between .NET versions.

We did more tests yesterday after I posted it here and there is more to it… We got to the point of writing a console app to simply call the ServerInstaller code and ran that in a bunch of systems.
We ended up running it fresh deployments with OS images only as well.
This was an attempt to rule out other software running on the various systems we tested against.

The conclusion of these tests was that there was either something environmental or in the OS image we were using for win 2025 which was causing the issue.

This morning (a few minutes ago) we ruled out the OS image by installing the same image on a new Test environment which was now available and the issue did NOT happen.
So we are down to an environmental issue at the moment.

This test environment, which has the issue, is in a domain with some stringent policies of all sorts.
There are things applied even to files copied from the network. Gets overcomplicated…
Still a mystery why installing .NET4.6.2 sorts it out.

  1. Regarding GetCoreLicenseStatus() is returning ‘None’, it could be a bug, or we treated WMSServer in a different way. I can get a better idea after having your lic files.

This could be very handy if we get it working as we could log the output at install time.
I have a feeling the code might not be there yet as we are still using v10?

Hi Ed,

I got the files you sent over, and it seems MapSuiteDeployment_works.lic works fine but MapSuiteDeployment_broken.lic is illegal.

My question:

  1. MapSuiteDeployment_broken.lic (3k) is 2k less than MapSuiteDeployment_works.lic (5k), but they are supposed to have the same size, right?
  2. It seems something environmental prevents the .lic from being created successfully. It might be complicated but I’m afraid you guys need to find out what exactly causes that issue. The tool was created years ago so maybe some software (or even a newer version of .net framework?) brought in this issue.
    3.In the latest versions, you can enable ThinkGeoDebugger and log the internal messages, including the license information, to the output window or a file. It’s not available in v10 though.

Anyway, let us know if you guys find out that environmental setting/soft causing that issue, and we can keep digging in.

Thanks,
Ben