search

judero01col / GMap.NET

GMap.NET Windows Forms & Presentation is an excellent open source, powerful, free and cross-platform .NET control. Allows the use of routing, geocoding, directions and maps from Google, Yahoo!, Bing, OpenStreetMap, ArcGIS, Pergo, SigPac, Yendux, Mapy.cz, Maps.lt, iKarte.lv, NearMap, HereMap, CloudMade, WikiMapia, MapQuest and many more.
Other
458 stars 201 forks source link

new GMap.NET.WindowsForms.GMapControl()' threw an exception of type 'System.TypeInitializationException #167

Closed g0d closed 2 years ago

g0d commented 2 years ago

After running a newly created app I get that... I have all final libs installed and made sure I am not missing any dependencies.

This happens somehow randomly. I get it to work in certain applications and in others not!

***** Exception Text ** System.TypeInitializationException: The type initializer for 'GMap.NET.WindowsForms.GMapControl' threw an exception. ---> System.EntryPointNotFoundException: Unable to find an entry point named 'SIf36d68994f8a3dbc' in DLL 'SQLite.Interop.dll'. at System.Data.SQLite.UnsafeNativeMethods.sqlite3_libversion() at GMap.NET.CacheProviders.SQLitePureImageCache.Ping() at GMap.NET.GMaps.SQLitePing() at GMap.NET.WindowsForms.GMapControl..cctor() --- End of inner exception stack trace ---

Please trace the issue with the SQL entry in the DLL...

Capture

zgabi commented 2 years ago

Do you use any other package which also needs SQLite?

Can you reproduce the problem in a small aplication which using only the GMap.NET package?

g0d commented 2 years ago

GMap.NET is the only package that uses SQLite. I triple checked.

The app that runs only GMap does not crash. However, if I use GMap in an app that uses a few more forms but nothing crazy, regardless of other libs it sometimes crashes, which makes no sense to me!

There must be a deeper logic behind this issue I guess....

zgabi commented 2 years ago

Please compare the *sqlite* files in the build output folders of the 2 projects. are the the same?

Maybe a package has an embedded sqlite dll.

Is it possible to share the list of the nuget packages that you use?

g0d commented 2 years ago

Yes, the files are the same. Look in the image. C2

Also these are the packages. The same in all projects, same revisions, same updates... Capture

zgabi commented 2 years ago

I think the problem is the Stub.System.Data.SQLite.Core.NetFramework.. is that needed? It contains another SQLite dll. You can download the nuget package from nuget.org, rename it to a zib, and you can see that the dll is inside...

So I'm sure that you have anotrher SQLite dll... when I asked you to compare the SQLite files, I ment to compare the size and content, too... I bet the are different in the 2 projects. (In that case when the 2nd project is wrong.. maybe sometimes it is using the good dll vesrion)

g0d commented 2 years ago

Unable to uninstall 'Stub.System.Data.SQLite.Core.NetFramework.1.0.116' because 'System.Data.SQLite.Core.1.0.116' depends on it.

Which in turn the GMap relies on System.Data.SQLite.

How could this be an issue? GMap automatically installs those dependencies...

I think that a team of experts should assemble to give this a more thorough look. It is serious and many many projects might fail due to this annoying, yet interesting "bug/effect/you name it..."

Cheers!

zgabi commented 2 years ago

Yes, it is a dependency of GMap.NET, too.. but is it a dependency of your project directly, too? Because GMap.NET is referencing 1.0.115.5 and in your screenshot I can see 1.0.116... however it should not be a problem.

Since your screenshot shows SQLite *,116, the following can happened:

But anyway GMap.NET should work with *.116, too.

This bigger problem is the fiel date of the SQLite.Interop.dll.... for verion *.116 it should be 1-Jun-2022. And the file size should be bigger. About 1700 kB for 64 bit and about 1400 kW for 32 bit. So it seems that it comes from another package.

You should check from where does this old file come.

g0d commented 2 years ago

I just updated to *.116 like you said, I am not refencing this packages from anywhere else nor I use anything with SQLite. I double checked....

The DLL files in all the projects that I created are the same and I did a size and content comparison.

I am pretty sure something is wrong with the library or one of the dependencies. Otherwise, it makes no sense (unless a Windows update or so did it again... :P)

Can you please check for any strange behavior with projects that are complicated and have many forms, etc.?

zgabi commented 2 years ago

We are using it in a quite big projevt (about 6000 classes and a lot of dialog windows, at least 100).. however we are using only the Core project to download the tile images and it is a WPF project.

If you download the following package and unzip it, you can see that the file date is from 1-June: https://www.nuget.org/packages/Stub.System.Data.SQLite.Core.NetFramework

I don't understand why is it 11-March for you.

Please check your C:\Users\user.nuget\packages\stub.system.data.sqlite.core.netframework\1.0.116 folder.. it should contain a newer SQLite.Interop.dll with a different file size.

zgabi commented 2 years ago

Also try to clean and rebuild the project.

g0d commented 2 years ago

Hi again,

I always clean and build because I had many issues with partially compiled sources in the past. So, trust me I do that a lot!

No the path you indicated does not seem to exist and I searched around to find it but no.

I downloaded the NuGet package but in there I only see available DLLs for .NET framework prior to 4.8 that I am using. Maybe this is the issue?

Yet again, I have built successfully against 4.8 already another project, so now I am terribly confused!

g0d commented 2 years ago

I have added the SQLite Interop DLL of the v4.0 .NET and worked! :S

This is sooo crazy!

zgabi commented 2 years ago

A backslash was missing from the path. Correct path is: C:\Users\yourusername.nuget\packages\stub.system.data.sqlite.core.netframework\1.0.116

Is this folder exists? C:\Users\yourusername.nuget (there is a dot before nuget)

zgabi commented 2 years ago

Ahh... Github remove it. Yourusername \ .nuget

g0d commented 2 years ago

Yes now I see all the same files in the NuGet package. But, which one is the correct to use? Like I said a few comments before, it worked with 4.0 .NET. Which one is the most optimal and why does it work?

g0d commented 2 years ago

Actually I found it!

It's VS's fault! It didn't clear all the files and kept seeing an older version of interop. The system did not copy the new DLL and I was keep referencing the older one. I noticed the difference by compiling side by side the two projects.

I had to remove the DLLs by hand and voila! The problem is gone, Now two new folders are being created (x64 and x86), because i am compiling for Any CPU.

Now at run time, the loader references the right DLL.

Sorry for the hard time but in the end I guess this is a lesson for others too. The whole thing is due to a messed up cleaning of the VS!

Thanks a lot @zgabi!

zgabi commented 2 years ago

Yes now I see all the same files in the NuGet package. But, which one is the correct to use? Like I said a few comments before, it worked with 4.0 .NET. Which one is the most optimal and why does it work?

The latest version which is smaller or equal than your tagert version. Since you are using .NET 4.8, and the newest target is 4.6 in the package, you should use the 4.6 version. For example if you target 4.5.2, then version 4.5.1 should be used (since there is no 4.5.2 version in the package)

But you should not copy this manually... hopefully VS copies the right version.

There is a bigger mess with the netstandard and netcoreapp version.. but fortunately all of them will be deprecated in 4 months. (netcore 3.1 is the only one which is still suppoted until 13-dec-2022).