ThinkGeo.MapSuite.Wpf.dll V10.5.6 Causing Network issues

Dennis · August 4, 2019, 11:31pm

MapSuite Team,

I have an application that is nearly eight years old, which incorporates the MapSuite SDK for rendering a map and another 3rd party SDK for other real-time information. Up until now these two SDK’s have not interfered with each other.

I recently upgraded this application from MapSuite V10.0 to V10.5 and now find that ThinkGeo.MapSuite.Wpf.dll V10.5.6 is interfering with the other 3rd party SDK.

The other SDK acts as a client that connects to its server. When ThinkGeo.MapSuite.Wpf.dll V10.5.6 is used the other SDK is unable to connect to its server. The prior version I’ve been using is ThinkGeo.MapSuite.Wpf.dll V11.0.0-beta044. When this version is used the other SDK has no problem connecting to its server.

It would appear that there is something in ThinkGeo.MapSuite.Wpf.dll V10.5.6 that is ‘interfering’ with the network. The other SDK is using network port 5500 for its initial communication between client and server. The behavior of the other SDK is suggestive of something blocking/preventing communication on port 5500.

I have another application which uses a small number of MapSuite DLL’s, which does not render a map. It is only used to build SQLite Feature Layers. This application also incorporates the other 3rd party SDK. The following MapSuite DLL’s are referenced:
NetTopologySuite.dll
ThinkGeo.MapSuite.dll
ThinkGeo.MapSuite.Layers.ShapeFile.dll
ThinkGeo.MapSuite.Layers.Sqlite.dll
MapSuiteDependency-UnmanagedProj4Projection.dll
ThinkGeo.MapSuite.Wpf.dll

When referencing the V10.0 DLL’s and ThinkGeo.MapSuite.Wpf.dll V11.0.0-beta044 the other SDK is able to connect to it’s server.

After upgrading this application from MapSuite V10.0 to V10.5 and ThinkGeo.MapSuite.Wpf.dll V10.5.6 the other SDK is unable to connect to its server.

This application actually does not require ThinkGeo.MapSuite.Wpf.dll since it does not render a map. So I removed the reference to this DLL and the vestigial using ThinkGeo.MapSuite.Wpf statements. After removing the reference and rebuilding the application the other SDK can now connect to its server.

The mere reference to ThinkGeo.MapSuite.Wpf.dll V10.5.6 in this application ‘interferes’ with the other SDK.

So the question is “what is inside ThinkGeo.MapSuite.Wpf.dll V10.5.6 that is causing this interference” ?

I realize this is a lot to absorb, but please read over and give it some thought.

Regards,
Dennis

P.S.

For my application that uses both SDK’s I reverted back to these two DLL’s and now the application works with the other SDK connecting to its server:
ThinkGeo.MapSuite.Wpf.dll V11.0.0-beta044
ThinkGeo.MapSuite.dll V11.0.0-beta057

Ethan · August 5, 2019, 10:02am

Hi Dennis,

Thanks for your detail description, that’s very strange, because by default our WPF map don’t have the logic to open network port, unless your layer require that.

And the ThinkGeo.MapSuite.Wpf.dll V11.0.0-beta044 is built in 1/29/2018, it have so many changes after that, so if you make sure beta044 works but beta045 don’t works, we can compare the changes between them and see what’s the change about that. In fact I found the changes around that version, it looks nothing is related with network.

The only possible I think about your scenario is the port 5500 you mentioned been occupied, follow this thinking I tried to view our layers which need to require network, but hadn’t found any layer need to open port 5500.

I think you should want to use some utility to watch the port usage status, then you can test to render a blank map, if you found any version open target port 5500 please let us know, we can double check the logic to make sure what’s the reason about it.

Regards,

Ethan

Dennis · August 5, 2019, 3:47pm

hi Ethan,

I’ve further experimented with the application that does not render a map, but which merely creates an SQLiteFeatureLayer.

Keep in mind that this application neither defines nor instantiates a WpfMap. It merely has a Visual Studio reference to ThinkGeo.MapSuite.Wpf.dll.

I’ve confirmed the following versions of ThinkGeo.MapSuite.Wpf.dll do not cause ‘interference’:

V11.0.0-beta044
V11.0.0-beta045
V11.0.0-beta080
V11.0.0-beta090

I’ve confirmed the following versions of ThinkGeo.MapSuite.Wpf.dll do cause ‘interference’:

V11.0.0-beta091
V11.0.0-beta092
V11.0.0-beta093
V11.0.0-beta094
V11.0.0-beta095
V11.0.0-beta096
V11.0.0-beta097
V11.0.0-beta098
V11.0.0-beta099
V11.0.0-beta100

So it would appear that something from beta090 to beta091 is causing the issue to surface. It is perplexing that having a mere Reference is causing this issue.

Out of curiosity, which beta version is V10.5.6 equivalent to?

Regards,
Dennis

Ethan · August 6, 2019, 9:28am

Hi Dennis,

In fact you can view the upload date in NuGet page for each version.

For example:
11.0.0-beta090 2019-03-26
11.0.0-beta091 2019-04-02

10.4.5 2019-03-19
10.5.0 2019-04-01
10.5.6 2019-07-19

For same branch, the later version contains the earlier version changes.
For different branch, the later development version contains the earlier release version changes, but the later release version not always contains the earlier development changes.

Our developer checked the update logs, we hadn’t found any code change about that.

We have some guess and want to make sure some items:

Does add reference cause your other SDK cannot connect to server or add packages from Nuget into project cause that? They are different, if you add this package from NuGet, some script will be execute to copy some necessary dlls to your project.
You mentioned the SQLiteFeatureLayer, do you means you instantiates this class in code after the dll is referenced?
Could you please let us know what’s the other SDK so we can see whether we can build a test project to reproduce that.

Our guess is our map reference the same dll with other SDK, after our upgrade, the other SDK don’t works. Because our code don’t have any part works for the network port especially port 5500.

Any further information please let us know, we want to find the reason and solve it.

Regards,

Ethan

Dennis · August 6, 2019, 3:27pm

hi Ethan,

Thanks for the explanation on release vs beta.

One thing I want to make sure you understand is my use of the word “reference”. When I use this word I am referring to Visual Studio Project References. It does not refer to reference of a class in the actual code. In the application we’ve been discussing ThinkGeo.MapSuite.Wpf.dll is not referenced in any way in the actual code. It merely exists as a Visual Studio Project Reference. Refer to screen-capture below.

Responses to your questions–>>

A reference is added to the project. Nuget is not being used for this application.

2.ThinkGeo.MapSuite.Wpf.dll is not referenced in the actual code. The instantiation of SQLiteFeatureLayer is performed only after the other SDK connects to its server.

3.The other SDK would not be available to you as a license and encrypted key is required as well as a server.

Based on your question regarding use of Nuget I’ve done more investigation–>

I’ve done a comparison of the …\bin\debug directory contents when a Rebuild is performed using V10.5.6 and V11.0.0beta090. Refer to screen capture below. As you can see when V10.5.6 is used ThinkGeo.Cloud.Client.dll exists in …\bin\debug. When V11.0.0beta090 is used ThinkGeo.Cloud.Client.dll does not exist in …\bin\debug.

The inclusion of the Cloud is a huge hint as to where this issue resides. The Cloud requires the Internet, which requires use of the network!!! This has to be what is causing the ‘interference’.

Another noticeable difference is in the size of V10.5.6 versus V11.0.0beta090. V10.5.6 is over twice as large as V11.0.0beta090. That amounts to an awful lot of code. With this amount of additional code it may be wise to look at the actual code changes as opposed to the Update Logs.

Regards,
Dennis

Ethan · August 7, 2019, 9:00am

Hi Dennis,

Thanks for your reply.

In fact the MapSuite 10.5.0 introduce big changes related with CloudLayer and many inner style, the changed size mainly is the inner style.

It looks we cannot build a sample to test it because we cannot use this 3rd part SDK, we need your help to do some test so we can locate which code change caused that.

Please did some test follow this table, so we can locate which changes maybe related with this problem, and we did further test based on the test result.

A. You should want to create a clean project, it only add the other SDK, don’t install any of ThinkGeo packages(It’s important), then you can download target package from Nuget page, then unzip it, and add reference by the way you mentioned(Right click on “References” button in project), please don’t write any ThinkGeo map code in your project.

B. You can did a quickly test based on the project from step 1, if you still found the beta091 block other SDK connect to server but beta090 don’t, we can go on next step. If now both beta090 and beta091 don’t block other SDK, which means not only add reference introduce that. We need to redesign the test step, go back to step 1, add code first, then add dll via NuGet plugin and watch the dll changes to make sure which part introduce this problem.

C. If we did this step, which means only add dll introduce this problem, so we want to locate it’s location of both branch and whether it’s in WPF dll or MapSuite dll(Because from your screen shot, it reference at least 4 dlls). You can just reference one dll at first, if one dll don’t have problem, then test both two dlls, this table as below is for test both WPF and MapSuite dlls.

Please let us know the test result, at the same time our developer will go on try to locate the possibility change about that.

Regards,

Ethan

Dennis · August 8, 2019, 3:00am

hi Ethan,

For your request I started with yet another application that I have that only ever used the other SDK.

I used Visual Studio Add Reference to add the following:

ThinkGeo.MapSuite.dll V10.5.3
ThinkGeo.MapSuite.Wpf V11.0.0beta090

In this case the other SDK connected to its server.

ThinkGeo.MapSuite.dll V10.5.3
ThinkGeo.MapSuite.Wpf V11.0.0beta091

In this case the other SDK did not connect to its server.

This application has additional logging and so I noticed the following error immediately after the attempt was made to connect to the other SDK server:

Exception Loading TheAssembly
ItemToResolve=Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
Path=C:\Program Files (x86)\TheOtherSDK\Newtonsoft.Json.dll
Message=Could not load file or assembly ‘file:///C:\Program Files (x86)\TheOtherSDK\Newtonsoft.Json.dll’ or one of its dependencies.
The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The application makes use of

AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;

Upon the application invoking a System.Reflection.Assembly.LoadFrom the above error was encountered. I believe because the other SDK is incompatible with the version of Newtonsoft.Json that MapSuite now uses…

At this point I began investigating this and did no more of your tests as they no longer seem necessary to me, but will continue if you want.

Versions of ThinkGeo.MapSuite.Wpf greater thanV11.0.0beta091 make use of Newtonsoft.Json V12.0.1.22727, which has a date of 11/27/2018.

The other SDK makes use of Newtonsoft.Json V7.0.1.18622, which has a date of 01/23/2017.

I added the following to the exe.config file:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-12.0.1.227270" newVersion="7.0.1.18622" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

With the above in the exe.config and the AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve; Newtonsoft.Json V7.0.1.18622 is successfully loaded and the other SDK connects successfully to its server.

I also added this to the application that renders a MapSuite map and uses the other SDK and it also now works. The map appears to be functioning properly.

The question now for me is what is going to happen when ThinkGeo.MapSuite.Wpf.dll attempts to use Newtonsoft.Json V7.0.1.18622 in my applications?

What functionality in MapSuite makes use of Newtonsoft.Json?

I have reached out to the company of the other SDK to get their input. Sometime in the next few months I will be upgrading to their latest SDK version so I imagine they will be using a more current version of Newtonsoft.Json.

What are your thoughts?

Regards,
Dennis

Ethan · August 8, 2019, 5:39am

Hi Dennis,

Thanks to your research and locate the problem reason, thanks also for your share about how to handle it.

Our new Cloud function require Newtonsoft.Json to parse JsonStyle, if you don’t use CloudOverlay and CloudLayer, I think this setting don’t have any effect for using our map.

We also found reference to 3rd part library maybe introduce the compatibility issues, so we plan to remove dependency for part of the 3rd part library in our new coming ThinkGeo Map, the Newtonsoft.Json is in this plan.

Regards,

Ethan

Dennis · August 8, 2019, 10:05pm

hi Ethan,

Glad this was solved and happy to share the solution.

At some point I may start using the Cloud and hopefully the Newtonsoft.Json versioning will match by then.

Dennis

Ethan · August 9, 2019, 2:43am

Hi Dennis,

Any question please let us know.

Regards,

Ethan