ThinkGeo.com    |     Documentation    |     Premium Support

Modernizing our static map image service

#1

Currently we are using Map Suite 7.0 and would like to modernize our service. The service is currently hosted in “classic” Azure infrastructure that is being deprecated after 9 years or so. I would like to upgrade our service to run in Azure Functions or preferably in a docker container.

I have been trying to evaluate version 13 by running it in a docker image and have had several hurdles. Firstly, I kept getting SkiaSharp dependency errors and was disappointed to find out your software dependencies are not self contained in NuGet. To fix this issue I had to install a couple libraries directly into the docker image.

My current stopper is that I cannot seem to get around is how the licensing works.

Your Product Center CLI tooling is woefully out of date and is not a self contained app, so I had to hunt down and find the now unsupported docker image for .NET Core 3.1 to even run the tool. My prototype application is using .NET 7.0 with intentions to moving it to 8.0 once it is released in a couple months. Running the service on an antiquated docker image is out of the question.

After registering for the evaluation license on the .NET Core 3.1 container I found that the license file is stored as /root/.local/share/ThinkGeo/Map Suite 13.0/MapSuiteDevelopment.lic Whenever I move this file over to the .NET 7.0 docker image I continue to get the following exception.

System.InvalidOperationException: Welcome to ThinkGeo components! Please sign up at https://helpdesk.thinkgeo.com/register, download Product Center, and start your evaluation for free. If you are doing non-map-related development, please contact your map developer to get a runtime license, which will allow you to continue development with blank maps.

   at ThinkGeo.Core.ValidatorHelper.CheckStatus()
   at ThinkGeo.Core.ValidatorHelper.CheckInputValueIsLargerThanZero(Double value, String parameterName)
   at ThinkGeo.Core.Projection.GetProjStringByEpsgSrid(Int32 srid)
   at ThinkGeo.Core.Projection.ConvertEpsgToProjString(Int32 srid)
   at ThinkGeo.Core.Projection..ctor(Int32 srid)
   at ThinkGeo.Core.BingMapsLayer..ctor(String applicationId, BingMapsMapType mapType)
   at RavenSlingshot.MapImage.Managers.MapImageManager.GetBaseLayer(String layerName)

Is it even possible to run your software in a docker container with your licensing implementation?

#2

Hi @Aaron_Harman,

Welcome to the forums and thanks for your questions. I can answer a few of your questions right off, and then I have a few more questions for you to get a better idea of your setup that will help me see the whole picture.

Regarding the issue when generating the license on one container and moving it to another container, this is not expected to work. Our licenses must be used on the machine they are generated on. So, the InvalidOperationException is expected.

Before I can answer your other questions, can you help me out by answering these questions:

  • Right now you’re trying to install a development evaluation license to do your development on the docker container? Or are you trying to deploy an existing application to the container?
  • Is the container Linux or Windows?
  • Can you give me details on the SkiaSharp error? Our ThinkGeo.Core nuget package should also pull in the SkiaSharp dependencies.

I will look into upgrading the CLI to .NET 7.0. We don’t get a lot of people using the CLI on a stripped down container and usually the 3.1 dependency is not an issue. But I can see in your case it will be and really our CLI needs updated anyway. I’ll let you know when we have a new build.

Thanks,
John

#3

We have an existing application that runs in an ancient Azure Cloud Service, and the Cloud Services are being depreciated by Azure. This means we have to move off of that platform. Since we have to move the service anyway, I thought I would upgrade it to the latest version of .NET and MapSuite. This would allow us to use newer serverless infrastructure. We are currently running v7.0 of MapSuite in production now and have been for the past 8 years maybe.

The licensing is different now than it used to be so I figure that will be a change (renew, etc). I was just using the evaluation to make sure I could upgrade our existing old version to the latest.

The container is Linux. mcr.microsoft.com/dotnet/aspnet:7.0

I discovered that I needed to install libfreetype6 and libfontconfig1 in order to get the library working in the docker container. I didn’t have any issues in windows.

System.TypeInitializationException: The type initializer for 'SkiaSharp.SKData' threw an exception.
---> System.DllNotFoundException: Unable to load shared library 'libSkiaSharp' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable: 
libfontconfig.so.1: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.10/libSkiaSharp.so: cannot open shared object file: No such file or directory
/app/bin/Debug/net7.0/libSkiaSharp.so: cannot open shared object file: No such file or directory
/app/bin/Debug/net7.0/runtimes/linux-x64/native/liblibSkiaSharp.so: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.10/liblibSkiaSharp.so: cannot open shared object file: No such file or directory
/app/bin/Debug/net7.0/liblibSkiaSharp.so: cannot open shared object file: No such file or directory
/app/bin/Debug/net7.0/runtimes/linux-x64/native/libSkiaSharp: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.10/libSkiaSharp: cannot open shared object file: No such file or directory
/app/bin/Debug/net7.0/libSkiaSharp: cannot open shared object file: No such file or directory
/app/bin/Debug/net7.0/runtimes/linux-x64/native/liblibSkiaSharp: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.10/liblibSkiaSharp: cannot open shared object file: No such file or directory
/app/bin/Debug/net7.0/liblibSkiaSharp: cannot open shared object file: No such file or directory

   at SkiaSharp.SkiaApi.sk_data_new_empty()
   at SkiaSharp.SKData..cctor()
   --- End of inner exception stack trace ---
   at SkiaSharp.SKData.Create(IntPtr address, Int32 length)
   at SkiaSharp.SKBitmap.Decode(ReadOnlySpan`1 buffer)
   at SkiaSharp.SKBitmap.Decode(Byte[] buffer)
   at EhU=.OhU=.OxU=(Byte[] bytes)
   at ThinkGeo.Core.GeoImage..ctor(Byte[] bytes)
   at ThinkGeo.Core.BingMapsLayer..ctor(String applicationId, BingMapsMapType mapType)
   ....

I hope this answers your questions.
Thank you for the reply,
Aaron

#4

Thanks @Aaron_Harman,

Those details help a lot and I’m glad you figured out the SkiaSharp dependencies on linux. It’s a little different than Windows.

Regarding the licensing, you’re correct - we have had some changes. We no longer charge for deployment or server licenses. We only have a subscription for each developer seat.

The CLI certainly should work on Azure and Docker. You can view this page for more details.

Can you give me details on which CLI command you’re running on the docker container? Are you using the /activatetestdeploymentlicense command?

Thanks,
John

#5

I was using /startevaluation since we don’t have a real license for the new version. Also I wasn’t copying the .lic file into the app directory like your docs instruct. I was copying the .lic file to the same directory where I had found it… /root/.local/share/ThinkGeo/Map Suite 13.0/MapSuiteDevelopment.lic

#6

I found this other forum post, but it’s exactly what I want to avoid. If we have to run the CLI to run on every container startup, that means every time we need to scale out to meet demand, we’ll be reliant on your license service. If we have to run the CLI at build time in our pipeline, that’s totally acceptable though.

Thanks for the link to the docs, I didn’t see that. I will continue to play with getting the .lic file working.

#7

I have downloaded the cli into the directory /thinkgeo and the dotnet 3.1 runtime into the directory /thinkgeo/dotnet

When I run the command below, the CLI just spits out and error and the help text.

/thinkgeo/dotnet/dotnet /thinkgeo/ThinkGeo.ProductCenter.CLI.dll /activatetestdeploymentlicense /username:[redacted] /password:[redacted]
Object reference not set to an instance of an object.

Show a list with product name and id.
/getproductids

Start evaluation for a product.
/startevaluation /username:[name] /password:[password] /productid:[id]
  [name]      Specifies user name.
  [password]  Specifies user password.
  [id]        Specifies product id.

[...CUT FOR BREVITY...]

When I run the /startevaluation option, it works fine

/thinkgeo/dotnet/dotnet /thinkgeo/ThinkGeo.ProductCenter.CLI.dll /startevaluation /username:[redacted] /password:[redacted] /productid:f4d1f27e-761e-4ada-82d7-53e7b20d2c2e
You already have an evaluation license for this product. It will expire in 24 days.
#8

Hi @Aaron_Harman,

Thanks for the additional details. Please see my feedback below.

I’m sorry, but the server license must be generated on the server or container that it will be deployed to. Each license is paired to the deployed instance. There is no workaround for this requirement.

We’ll make a change to add user-friendly text, but the error is expected. During an evaluation, deployment licenses(test or production) are not allowed. Once you have an active developer license, then unlimited server deployments are allowed.

Under the current license structure, we no longer charge for deployments and there are never any royalties or per-seat end user charges. We only license the developer machine and any active subscription allows unlimited deployment licenses to be generated. And even if your subscription expires, all previously generated deployment licenses will continue to function, you just won’t be able to generate new ones without an active developer subscription.

You can find more details under the ‘Licensing’ section of our FAQs.

I hope this answers most of your questions, but please let me know if you have any others.

Thanks,
John

#9

So, if you’re going to make me get a new license on every docker container that I spin up, what happens if your license service is down? Does your license service have an SLA? We would be spinning up and down containers multiple times per hour to meet workload demands.

#10

Hi Aaron,

We do not have a formal SLA for this service, but the license service is redundant and has active monitoring that notifies us of any outages. That being said, the service is very simple and it has not had outages in the past.

Thanks,
John