Development Time Licenses for Map Suite Desktop Edition

[Richard_Styer]

Not too long ago, we upgraded our application from Map Suite Desktop Edition 9.0.0 to Map Suite Desktop Edition 10.3.0. We have noticed that there are significant changes to the licensing and for the most part we have made the appropriate changes to our application. We have generated “runtime Licenses” and include them in our application when we distribute it and this appears to be working, However, we have question about the “Development rime” license. We have developers on our project that do not do any development on the Map Suite code. With 9.0.0, they were able to run the application and if they ran a portion application which displayed any windows with a Map Suite control. the window would be white and display a watermark of “Map not licensed for development”. With the 10.3.0 code, these developer are now getting exceptions from the code even if they aren’t displaying a window with a Map control. According to the web page on the ThinkGeo site titled “Map Suite 10.0 License Strategy”, the map developer can generate a runtime license that is given to the non-licensed developer to avoid the exception and get a "blank white map with a watermark “not licensed for map development”. We have generated the runtime license and we add it to the bin folder but the exceptions are still occurring. Does anyone know how to prevent these exceptions?

Thanks in advance

R Styer

[Ethan]

Hi Richard,

I tested your scenario today, it looks it just works well for 10.3.0.

And here is the test project: TestWithoutLicense.zip (105.6 KB)

I build the runtime license for the application: Map Suite Desktop for WinForms App1.exe

You can found the file Map Suite Desktop for WinForms App1.exe.mapsuitelicense in the debug folder (Same folder with the exe file).

And you can test it in a new machine with VS but not installed mapsuite, the developer can modify and debug the code not related with map, everything goes well.

Regards,

Ethan

[Richard_Styer]

Thanks Ethan
Would it matter that we do all of our development in a local network not connected to the internet in anyway. We have to do all the activation and runtime license generation on a different network connection and then do offline activation with the generated activation files for offline activation. We have to load the “exe” on to the network with internet connection, generate the runtime license and then move both back to the network without internet connection. The exception I am getting is a “NullreferenceException: Object reference not set to an instance of an object” The top of the stack is in ThinkGeo.MapSuite.ProductCenter.GlobalSettings.d__64.MoveNext()

R Styer

[Ethan]

Hi Richard,

You need to generate the license file after you login your account, so the network need be connected then.

After that you can copy the files into a offline environment and it also will works.

Could you please let us know when you get this exception, from my test sample or your application after move to the network without internet?

Regards,

Ethan

[Richard_Styer]

Ethan

Thanks for the response.

I’m sorry I didn’t make it more clear in my last message. I was logged into my account on my externally connected computer (with the internet connection) when I generated the “runtime license file” for our application executable. I then moved the mapSuiteLicense file back to our isolated offline network to try the debugger in Visual Studio.

The exception that I sent was the exception from our application when we run through the debugger for the user who does not have an activated ThinkGeo developers license on their computer. I should probably give you a few more details about the architecture of our application. We have developed a “map control” which uses the ThinkGeo Map Suite Winforms Desktop libraries. This “map Control” is entirely contained within a DLL which makes all the calls to the ThinkGeo libraries. This map control is then incorporated into an application (exe) which is basically a winforms window which instantiate the map control. This exe can be run as an independent application (but we usually only do this for testing now). The Map Control application (exe) is then referenced by another DLL which defines two interface classes to make calls to the Map Control itself. These interfaces are implemented through delegate functions and the functions are implemented for the interfaces in the Map Control application (exe). Then we have another separate application which does a lot of other analyses work and implements a user interface to run the main application. This application uses the map control via the interfaces to display the map window and draw various objects on the map (markers, lines, polygons, etc.). There is no code or references in the main application that directly calls any ThinkGeo libraries. All the calls are through the interfaces to the Interface DLL which calls the Map Control application, which calls the Map Control DLL which calls the ThinkGeo libraries. I am the primary developer for the Map Control code and I am the only one that debugs or needs to debug into any of the code below the interface DLL. The other developers work within the main application and do not need to debug into the interfaces, or the Map control application, or the Map control DLL. We have in fact disabled debug into this code by not providing the “pdb” file for the map control in the solution for the “non Map developers”. We prebuild the Map Control DLL, Exe, and Interface DLL and reference only the prebuilt DLLs in the main application projects. If they debug in the main application to any call in the interfaces, the debugger will not allow them to step into the interface methods because they are treated as “Not my code” by Visual Studio. The call is executed silently in Visual Studio and the debugger advances to the next line of code. However, when the code is executed it is throwing exceptions such as the one reported In the previous message. So the debugger can’t step into the code or step through it but the ThinkGeo license is preventing it from being executed.

That is the main question that we have "what does it mean to be a “non map developer” and can the non-map developer makes call to a separate “dll” while in debugger mode?

Thanks for the help

R Styer

[Ethan]

Hi Richard,

Thanks for your description, I only have one question about the architecture, please view this image:

If I misunderstand about your architecture please let me know.

Here I want to double check, you build license for Form B or Form D, for our file license, you need to build license file for Form B here. If you build for Form D it will throw exception.

And I want to build a simple sample to reproduced your exception.

But I don’t know what’s the way you wrap our map and APIs, so it’s not complete. If you still have problem about it, could you please build a really simple sample like it and sent us? The sample can remove all unnecessary logic and just render simple a shape on map.

Regards,

Ethan

[Richard_Styer]

Ethan

You did a good job of drawing the architecture. This is exactly how we have it implemented. “DLL C” is really just a static class with a bunch of delegates defined to call the interfaces Form B. We used this intermediate DLL to avoid the instantiation of any of the classes in Form B from within our main application Form D and to avoid circular references that we had when we tried to build.

You did however give us the clue to solve our problem. Form B was built in our architecture as an “exe” not as a “dll”. It is referenced and used in the main application as you would a “dll”. We had generated runtime licenses for both the Form B and Form D exes but because we are debugging from Form D it was only using the Form D “mapSuiteLicense” to check for the activation. It is ignoring the “mapSuiteLicense” that we included for Form B.

Our solution is to change the “Form B” project to generate a “dll” not the “exe”. We can then reference that Form B dll in the main project. Now it uses the “Form D” mapsuitelicense and our exceptions go away and we get the map window with the watermark “not licensed for Map Development”.

We need to implement these changes and do further testing but I think this is the answer to our problem.

Thanks for all your support.

R Styer

[Ethan]

Hi Richard,

Thanks for your update, any question please let us know.

Regards,

Ethan

[Richard_Styer]

Ethan

You helped us before on this issue so I was wondering if you might have some further input for us. Back in November we stumbled through getting the Visual Studio debugger to allow non-ThinkGeo MapSuite licensed users to be able to run our application in the debugger. In the end, we found that our problem was having an exe calling ThinkGeo that was being called like a “dll” from the exe file for our application.

Well, it just popped it head back up again and for the last week our developmer has not been able to debug our application. We were getting the same exception that we had back in November from the ThinkGeo Product Center that we were not licensed and it would abort the application so that we could not debug anything after that.

Now just a few minutes and trying everything we could imagine, we discovered the source of the problem. We had generated a runtime “mapsuitelicense” file for our application back in November. This allowed us to run the application outside of Visual Studio and it still allows us to do that. However, inside Visual Studio debugger this “runtime” license no longer works. We had to re-generate the mapsuitelicense file in order to get the debugger to run for the unlicensed ThinkGeo developer. We had changed both the dlls that reference ThinkGeo and also the main application between November and the current problem but it didn’t manifest as the debugger issue until last week.

So our question is when and how often do we need to re-generate the runtime mapsuitelicense file for our application. What are the changes that we should be aware of in order to trigger us to get a new runtime license? Do we need to generate a new one every time we change the main application exe? Do we need to generate a new one anytime we change the dll which references the ThinkGeo libraries?

Any help you can give us would be greatly appreciated. We can not afford to loose the better part of three days of development time when issue like this come up.

Thanks for your help

R Styer

[Ethan]

Hi Richard,

I want to know what’s the mapsuite dll version between last November and now at first.

Then I want to know what’s the change this time of your project, in fact if you hadn’t modify your exe name(Form B), the license file won’t get expired.

So could you double check your architecture to see whether it get changed anywhere? That should be helpful for us to thinking about where is the problem.

And here is our detail license guide, you can read it and see whether any situation is changed in your scenario.
http://wiki.thinkgeo.com/wiki/map_suite_license_guide

Regards,

Ethan

[Richard_Styer]

Ethan

Thanks so much for getting back to us so quickly. I will try to answer your questions.

We have not changed any of the ThinkGeo MapSuite dlls between Nov 8 2018 and Jan 15 2019 in our builds. So we were using the version 10.3.0 for nearly all the ThinkGeo dlls and specifically the following:
ThinkGeo.MapSuite.ProductCenter.exe 10.3.0
ThinkGeo.MapSuite.dll 10.3.3
ThinkGeo.MapSuite.Winforms.dll 10.3.3

We have not changed the name of the exe for our main application. It was UI.exe on Nov 8th and is still UI.exe on Jan 15th.

We have not changed the architecture between Nov 8th and Jan 15th. We are building exactly the same dlls and exes in our solution. The last architecture change was on Nov 8th when we changed from building the GUI wrapper (FormB in the diagram above) for the Maps from an exe to a dll to get the Visual Studio debugger to work.

We have changed the code in the MapControl dll which wraps the ThinkGeo libraries to fix some minor bugs. We have also updated the version information in the assemblyinfo.cs files for all the dlls that are involved in the Map generation and we have done complete “Rebuild” on this code in Visual Studio. The minor fixes did not involve any new calls to the ThinkGeo libraries.

We have also changed code in the UI.exe of the main application and we have done complete “Rebuild” on the main application many times (we do nightly builds on this). We have changed the version in the assemblyinfo.cs many times (we are currently on build 41 so the version has changed around 40 times). We did not change any of the interfaces to the Map dlls wrapping the ThinkGeo dll but we have modified some code which calls the interfaces. Our main application does not have any references in the project files to any ThinkGeo dlls but it does have references to the MapControl dlls with version numbers.

I hope this answered your questions.

Thanks for your help

R Styer

What

[Ethan]

Hi Richard,

It looks the biggest change for our license is you change the FormB from exe to dll. You can see our license is related with this exe file, after you modify it the license file don’t works, because it have to related with exe file.

So if other part in the architecture hadn’t get changed, the license should generated to the FormD now.

You can view the link I posted, it shows detail work conditions for license file.

For simple, the directly exe file have to be generated license file.

Now the ABC is dll, only D is execute file, so the license need to be generated to it.

If you want to compatible your old code and new code, please try this solution, keep old license file for FormB, then build a new license file for FormD. I hadn’t tested it because but I think it should works.

And at the same time, you need to check your expired time of your online license in Product center to make sure it’s valid.

Regards,

Ethan

[Richard_Styer]

Ethan

Yes I agree with everything you have said. I have read the “detail work conditions for the license file” on the link the ThinkGeo web page and as far as I can determine we are in compliance with the license information.

Yes we did change the “Form B” for our application from an exe to dll. But we did this before we regenerated the mapsuiteLicencse file on Nov 8th. So since Nov 8th the only exe and the only runtime mapsuitelicense is the one for the “form D” and that “Form D” has not changed its name it was and still is “UI.exe.mapsuitelicense”.

After we had changed the “Form B” from an exe to a dll on Nov 8th. ProductCenter would not allow us to generate a mmapsuitelicense for the dll and since the old runtime license for “Form B” was for the “exe”, we removed it from our build . I could retrieve this old license file from our CM but not having it was not a problem for six weeks so I am not sure having it would make any difference.

Our problem is that for more than six weeks this runtime license enabled our non-ThinkGeo developers to run our application in the Visual Studio debugger. But for some reason during the first week of Jan 2019, this stopped and the runtime license we generated on Nov 8th would no longer work to allow our non-ThinkGeo developer to debug our application in Visual Studio debugger. We re-generated the license “UI.exe.mapsuiteLicense” on Jan 14th and now the non-ThinkGeo developer can debug the application in Visual Studio debugger. We did not change the architecture as far as dlls and exes in the six week time period.

So we are wondering why the mapsuitelicense for the UI.exe has to be re-generated. It could be date related since it stopped working sometime around the change of 2018 to 2019. Our license service agreement should be good until around Sept 2019.

Thanks

R Styer

[Ethan]

Hi Richard,

Thanks for your detail description, I don’t know you modify the exe to dll before generate the license file. It looks that maybe have problem here, could you please zip your two license files(not work and work one) for the same UI.exe (the exe file is optional) and I can sent it to our developer to see whether they can make sure whether there is any problem about the cross-year from the license information. In fact we hadn’t met that before, the conditions are just like our guide listed.

Regards,

Ethan

[Richard_Styer]

Ethan

Here is my attempt to upload a zip file for you. I have not included the exe for the application as it is proprietary and I will need special permission to upload it.

Rich Styer

[Richard_Styer]

UI.exe.zip (2.8 KB)

[Ethan]

Hi Richard,

Thanks for your information, it looks that’s different, I am not sure whether it can be decrypted, but I will sent it to our developer, if they can find any information from it I will let you know.

And I think it should be a special situation in certain scenario, so you should don’t worry about re-generate the license many times.

Regards,

Ethan

[Ethan]

Hi Richard,

Our developer read your license file, it looks you have a WPF eval is expired, it looks maybe that’s the reason of your problem. But in our test that won’t effect the result because our logic handle this scenario.

So could you please test the simple sample I built in your machine?

As below is a simple sample which for reproduce your scenario, I build a Winform project, then modify it to a dll, and after that I build a new Winform project named UI.exe which reference it and call it.

Map Suite Desktop for WinForms App1.zip (117.2 KB)

Before test, please deactive your product(winforms edition) in your product center. And copy one of the license file between the 201901 license file and 201811 license file into Map Suite Desktop for WinForms App1\Form1\bin\Debug folder. And you can try to run the project without the license file, it will throw exception.

In my machine, the two license file works the same.

If you can reproduce this issue based on the test project please let me know, we will find some other solution for you.

If you found anything is missed in test sample could you please modify it and sent it back? So we can double check where is the problem.

Regards,

Ethan

[Richard_Styer]

Ethan

We have been watching the License issue for some time now. It appears to be consistent that we need to regenerate the license file at exactly 60 days after the previous one was generated or the non-ThinkGeo developer will not be able to use the debugger for the rest of the code in the application. As long as we go through the ProductCenter and generate the Mapsuite license file over again for the exe of the application and then add this updated to our bin folder, the non-ThinkGeo developer can run in the debugger (but the window still shows the “Not licensed text” as expected). It would be nice if we didn’t have to do this every 60 days but we will live with it as long as we have to.

Richard Styer

[Ethan]

Hi Richard,

Our developer is looking into this problem.

Could you please upload a expired “.filelicense” file, so we can did some test based on it?

Regards,

Ethan