ThinkGeo.com    |     Documentation    |     Premium Support

ThinkGeo UI for DeskTop 13 and Sqlite

#1

For a .NET 4.8 app, exactly what nuget packages are required to add Sqlite support to a ThinkGeo WPF 13 app. A minimum sample project with the recommended Sqlite packages and versions would be appreciated.

Thanks!

libSkiaSharp.dll not copied to bin\Debug
#2

hi, @Daniel_Schuessler

There’s something wrong with SqliteFeatureLayer under .net framework 4.8, and we’re working on it. It works well with .net 6, you could try it if it’s an alternative for you.

Thanks,
Leo

#3

This is an issue in the ThinkGeo Dependecy Microsoft.Data.Sqlite. Here is how to work it around in case anyone need it:

Copy the dlls (one for x86 and one for x64) from e_sqlite3.zip (1.6 MB) to the following folders respectively:

\bin\Debug\net48\runtimes\win-x86\native
and
\bin\Debug\net48\runtimes\win-x64\native

Ben

#4

In case it’s helpful to anyone, this turns out to be a limitation of using the new NuGet package in an old-style project. After updating the project to SDK-style (introduced in Visual Studio 2019), everything works as expected. We mentioned this in the following post: SqlServerFeatureLayer issues - ThinkGeo UI for Desktop / WPF, and I’m copying the relevant part here for convenience:

You can think of it as a limitation of the .NET Framework runtime, that the newer Microsoft.Data.SqlClient package isn’t fully compatible with the legacy project system.

Reason:
The package includes several native DLLs that .NET Framework doesn’t correctly resolve under AnyCPU .

How to Fix:

  1. Use the modern SDK-style project format (available since VS2019).
    This format brings in the modern NuGet restore pipeline, which correctly handles the native dlls and fixes the issue. ThinkGeo’s Desktop HowDoI is an example, it uses this new SDK-style, and its SQL Server sample works fine with .NET Framework 4.8 under AnyCPU .
    samples/wpf/HowDoISample · develop · ThinkGeo / Public / Desktop Maps · GitLab. This project supports both .NET 8 and .NET 4.8 . you can simply edit the .csproj to the following to make it net48 only
<TargetFrameworks>net48</TargetFrameworks>
  1. If you need to stay with the old (non-SDK) project format , explicitly target a platform — either x64 or x86 — instead of AnyCPU .
    That will also prevent the incorrect native DLLs from being loaded.

I’ve run into similar issues with other packages too. Realistically, we’ll probably need to migrate away from .NET Framework at some point in the future.