ThinkGeo.com    |     Documentation    |     Premium Support

More struggles with migrating to V10

#1

As previously discussed on these threads, we previously tried to migrate to your V10 using your migration guide and found it overwhelmingly incomplete. I made several observations before we abandoned that effort, but now I’m working on getting this migration completed “in my spare time”. Turn around on support for this product (often necessary even for small progress) is far too slow to work on full time. Anyway, just to tie things together, these are the original threads.
V10 migration questions
Related OOM exception problems

My current issue stems from your suggestion to start with the “BareBones” Nuget package. I did so, and that seems to have dramatically improved the veritable explosion of dependencies that more than doubled the size of our application. Great!

That got most of my previous porting code compiling but was missing NativeImageRasterLayer. No big deal, you already told me how to find that as a standalone in ThinkGeo.MapSuite.Layers.NativeImage. As expected, I didn’t get very far until I ran headlong into another issue. That package has dependencies on IOS and Mono/Android. I thought the whole purpose of this massive headache was to let us get what we want? And for a desktop product I don’t want IOS dependencise OR Mono/Android. So, am I going to be stuck with these extraneous dependencies as a “cost of doing business” in order to display a simple Raster image?

#2

You also have a LOT of ambiguous type names. For example Style in both ThinkGeo.MapSuite.Core and ThinkGeo.MapSuite.Styles.Style. How is a person to differentiate when they port from the old unambiguous v9 Style? This makes it quite a pain to figure out what replaces what, requiring trial and error until you can get all the various types to play nice together.

Same thing happens with GeoColor (Core or Drawing), same thing with GeoBrush, similar with Core.BackgrounLayer can’t assign to Layers.Layer. Duplicates between DesktopEdition, Core, and WinForms.

cannot convert from ‘ThinkGeo.MapSuite.Shapes.RectangleShape’ to ‘ThinkGeo.MapSuite.Core.RectangleShape’
ambiguous reference between ‘ThinkGeo.MapSuite.Core.GeographyUnit’ and ‘ThinkGeo.MapSuite.GeographyUnit’
cannot convert from ‘ThinkGeo.MapSuite.Core.AdornmentLayer’ to ‘ThinkGeo.MapSuite.Layers.AdornmentLayer’

And there are others. The list goes on and on. And I can’t find any combination that works everywhere.

Who the hell defines that many classes with the same name and function again and again all over the place?

This v10 is (still) a huge mess. I’m beginning to wonder if I’m going to have to make the painful recommendation that we find a new map component. This is absolutely ridiculous.

#3

Oh, and I still don’t see missing samples for mini-map and scale overlay/adornment layers.like we used. If you guys can’t port your samples our implementation was based on, what hope do we have???

#4

Hi Russ,

  1. About the NuGet package organization, we split the package by function but not by platform. If we split the package for platform, the package number will be 5 times as it is now, for example, if you wan to find a feature, it will have ThisIsYourFeature-iOS, ThisIsYourFeature-Android, ThisIsYourFeature-Windows, ThisIsYourFeature-Mono, ThisIsYourFeature-Pcl, you may feel bad when try to reference dll. And by our research, there are more and more scenarios to use one project in different platform, this organization can reduce the workload when transfer.

  2. About the ambiguous type names, for V9 the MapSuite.Core is so heavy, we split it to Drawing, Layers, Styles, etc. for V10, it’s more reasonable for ThinkGeo MapSuite products. You can refer .NET Framework, when you try to create one simple WPF project, the VS will add about 14 namespace by default. By default for our product, you only need 5 namespace “ThinkGeo.MapSuite, ThinkGeo.MapSuite.Drawing, ThinkGeo.MapSuite.Layers, ThinkGeo.MapSuite.Shapes and ThinkGeo.MapSuite.Styles” to replace orignal “ThinkGeo.MapSuite.Core”. We think this way is more clearly about the APIs, and it improve our product.

  3. About the samples, we have a plan to move all samples from Wiki to GitHub, it’s a long-term task, our developer is still work on that. If you need a specified sample for V10, please let us know, we can handle that in higher priority.
    Now you can refer the Adornments samples for other platform in GitHub, they can be transfer to WPF platform easy. https://github.com/ThinkGeo?utf8=✓&q=adornment&type=&language=
    The mini-map adornment sample will be online GitHub soon. You can find it on GitHub in one or two days.

Regards,

Don

#5

I know there was a lot posted, but please read more carefully.

  1. But that’s exactly what you do for Barebone. So I install WinForms BareBone, (no iOS or Mono/Android) but then if I need ANYTHING else I have to include iOS and Mono/Android? I haven’t tried it, but does the latter even work with only Winforms BareBone? Having only winforms core, but then all 3 for NativeImage?
  2. Reread what I wrote. I’m not complaining about namespaces. I’m complaining about duplication of classes in those namespaces. How many different String classes are there in .net? Answer: 1. How many GeoColor classes in your BareBone winform library? Answer: 2. One in Core and the other in Drawing. They are very similar, but not the same. Look at the build errors I posted. There are many more, that is a tiny fraction of them.
  3. Mini-Map and Scale adornment like v9 would be a good start… But referencing #2 above, I would be very interested to see if they can provide a mini-map complete with WinForm map with raster background, shape-file, and InMemoryLayers. If he tries to do that, I think he will run into the same multi-definition incompatibility problems I have. But if you guys are having so much trouble porting your v9 samples that they have taken this long to get them done, what hope do ANY of your customers have?

Just for reference I’m uploading the build errors I’m looking at right at this moment. The details change in various ways depending on which namespaces I try to use for various things, but by the time I reference/use any of the specific types (not core) that I have to use, there is always a long list of incompatibilities going one way or the other. As you can see in the attached file, some things have an explicit cast provided, but others certainly don’t and converting from one to the other is in some cases a HUGE mess. So far I’ve found no way around this. And I can’t imagine why most of these couldn’t just use the Core versions, like GeographyUnit or GeoColor. By the time all the targeted NuGet packages are installed, just how many different GeoColor and GeographyUnit (and all the rest) types do we really need?

Errors.txt (8.8 KB)

#6

Hi Russ,

  1. The Barebone contains all basic functions, it have two parts, MapSuite namespace is the same for all Barebone and the namespace for each product for example ThinkGeo.MapSuite.Winforms is the different.

The other assemblys is the advanced functions, most of them can be used for all platform, some of them only works for special platform. That means, when you reference the Barbone for one product, you don’t need reference the other Barbone and the special assembly for other product, you only need reference the common ones and the special assembly for your product.

  1. I viewed your text file, that’s strange because we don’t have the ThinkGeo.MapSuite.Core namespace in V10, that means you hadn’t remove original 9.0 dll from your project. Please make sure that had been cleaned include your GAC and cache, then get 10.0 from NuGet. I think the duplication of classes problem should been solved. Because we only have one class in one assembly and one namespace now.

  2. Please refer my answer in question 2, I think we don’t have duplication classes now.

So it looks your currently main problem is about the class type, from your text file it shows something like this:
error CS0029: Cannot implicitly convert type ‘ThinkGeo.MapSuite.Drawing.PlatformGeoCanvas’ to ‘ThinkGeo.MapSuite.Core.GeoCanvas’
Core\DynamicMap.cs(691,34,691,60): error CS0030: Cannot convert type ‘ThinkGeo.MapSuite.Shapes.BaseShape’ to ‘ThinkGeo.MapSuite.Core.PolygonShape’

You can see all of them is try to convert a V10 calss to a V9 class, so please double check your reference of your project, clean all old references and cache, all necessary dll for V10 can be download from NuGet, you don’t need keep any old dlls now.

Wish that’s helpful.

Regards,

Don

#7

You found the truth of it. Thank you.

I didn’t realize it, but one of the times I decided to roll it back and start on a different tract I accidentally merged back the old v9 references in the project. And since I started with our current code base, those v9 assemblies were found, and as you noted, used. I knew it seemed like my latest passes things were getting worse and more confusing, but after all the other problems, I had blinders on and jumped to conclusions that were not correct.

I'll remove those and retrace my last few efforts on Monday. Hopefully I'll be able to find my way through it this time.

I’m still quite disappointed in the missing samples, some of which we used to provide necessary function in our product.
My concern is that if you guys are having that much trouble and delay getting the related sample working, then what hope does a consumer of your product like us have of sorting it out and making it work in a much more complicated scenario? So hopefully they will become available very soon.

#8

I couldn’t get it off my mind, so went ahead and started looking at this today. And I noticed that it may not have been my mistake in merging. In many cases VS/Resharper helpfully offers to add a reference to the old Core DLL. All it would take is one accidental choice and it would have produced the same outcome. I’m actually starting to think this is the likely cause due to not getting anything but Core added back to the project. But will likely never know which screw up caused my problem, but it is certainly easier to do than I realized.

By going back and starting over (again), I was able to get most of this resolved using your BareBone and some targeted extension packages. Still more to do, but I have already identified 2 types that I can’t figure out how to acquire.

BackgroundLayer
ValueItem

Both were previously in the Core namespace. I haven’t really spent much time looking yet, but I can’t find them in the WinForms BareBone package, and I see nothing to suggest where they might be found, or what they might now be named.

I also don’t see the MapEngine anywhere.

I’ve got to say I don’t find the search feature in NuGet particularly helpful. Searching for “thinkgeo mapsuite MapEngine” produces a lot of hits, apparently every package that has any words since none I checked actually mention MapEngine at all. So it would be nice if you docs/wiki/something showed what packages each type can be found within. Maybe that exists, but I haven’t been able to find it.

#9

Hi Russ,

Thanks for your update, as below is the minimap sample: https://github.com/ThinkGeo/MiniMapSample-ForWpf

Any other samples you need please let us know, so our developer can move that to V10 in higher priority.

About MapEngine, you can find the document here: http://wiki.thinkgeo.com/wiki/map_suite_10_upgrade_guide#how_to_use_mapengine_mapsuite_100

You can find the “How to use MapEngine MapSuite 10.0?” in this page.

As below is the BackgroundLayer: https://www.nuget.org/packages/ThinkGeo.MapSuite.Layers.Background/11.0.0-beta005

And this assembly contains ValueItem: https://www.nuget.org/packages/ThinkGeo.MapSuite.Styles.Value/11.0.0-beta005

Thanks for your suggestion, we maybe will build some pages to describe the relationship between class and assembly.

For now please just ask us if you met any class cannot be found.

Any question please let us know.

Regards,

Don

#10

Just to finish off this thread, it looks like we finally got our Map ported to your v10. That was much more difficult than expected based on your porting guide, but our maps are displaying. So it passed the initial smoke test, but we’ll have to see if there are any regressions once it moves into a full test pass.

#11

Hi Russ,

I am glad to hear your map display, and we will keep modify our guide pages to make it contains much more information.

Any question or problem please feel free to let us know.

Regards,

Don