Dependency problems moving to 14.4.1

[Kev_French]

Hi
I’m trying to update to 14.4.1 but am running into troubles.

First, I have a (separate to ThinkGeo) dependency on ‘sqlite3.dll’. Since upgrading to 14.x this file is being removed from my bin folder whenever I build. If I manually place the file and make it read-only I get an error and a failed build:
“MSB3021: Unable to copy file “E:.packages\thinkgeo.gdal.dependency.windows\14.0.1\runtimes\win-x64\native\sqlite3.dll” to “bin\x64\Debug\sqlite3.dll”. Access to the path ‘bin\x64\Debug\sqlite3.dll’ is denied.”
This suggests it’s trying to copy the file - all good. Except when the file isn’t present, or read-only, nothing gets copied into my bin folder and the file is removed. I’ve verified the source file is there in the package and clearly the target folder is correct.

Secondly whenever I try and instantiate a GdalProjectionConverter I get an eventual exception

“Unable to load DLL ‘gdal_wrap’: The specified procedure could not be found.”

The file ‘gdal_wrap.dll’ is in bin/runtimes/win-x64/native - I don’t know if that’s where it’s meant to be or if the code is looking in the wrong place. Is there any path magic I need to perform before I can use it?

For reference I’m working in net48 with an SDK-style csproj

Cheers

[Ben]

Hi,

I’ve seen this before. On .NET 5+ it’s fine, but on .NET Framework the build can sometimes remove or conflict with sqlite3.dll. Can you right-click the project in Visual Studio → Clean, then run the project, that often fixes the issue.

For the gdal_wrap.dll error — the file should be in runtimes\win-x64\native, so that part’s fine. Our updated HowDoI sample (using v14.4.1, support both net framwork48 and dotnet 8) works fine with GDAL layers, can you try building and running it on your end see if it works? Here is the sample: samples/wpf/HowDoISample · master · ThinkGeo / Public / Desktop Maps · GitLab

Thanks,
Ben

[Kev_French]

Hi

Cloned the sample and it does exactly the same thing with a ‘sqlite3.dll’ in the output folder. Removes it if it’s there and breaks the build if its read only.

I did observe that when the build fails, there’s a bunch of files in the bin folder that aren’t usually there - a bunch of .gfs, .csv files, etc. I can’t find these files anywhere when the build succeeds - is it possible these are added temporarily then removed which could explain where my sqlite3.dll is going?

A clean clone and build of the sample in NET48/x64 throws the same “Unable to load DLL ‘gdal_wrap’” exception when accessing the “Display a GDAL File” page. It does work in net8.0-windows/x64, which I can’t use anyway, but it still removes the sqlite3.dll file if present, or fails the build when it can’t overwrite it.

Cheers

[Ben]

I see the issue. For some reason the gdal dlls/files are not copied to the right spot when building in dotnet framework.

We will start to work on it. Before the fix is ready, you can work it around by coping the missing dlls/files to runtimes\win-x64\native, the missing files look like following, I’d suggest you build the project in net80, and then copy the corresponding files form net8.0-windows\runtimes\win-x64\native to net48\runtimes\win-x64\native

We’ll keep you posted.

[Ben]

Can you right click your project and change Platform target to x64, as following:

Rebuild and the gdal files will then copy to runtimes\win-x64\native. By default in dotnet framework, they are only copied to runtimes\win-x86\native

We are still on it see if any place we can improve.

[Ben]

All right, it’s now been fixed. Can you pull ThinkGeo.Gdal [14.5.0-beta012] and have another try?

[Kev_French]

Hi Ben

To confirm, 15.5.0-beta12 has resolved both issues, thanks for the quick resolution.

Cheers

[Ben]

Awesome! This change will also be available in the next stable version of ThinkGeo.Gdal.