ThinkGeo.com    |     Documentation    |     Premium Support

Gdal dependency runtime files

#1

Hi,

The ThinkGeo.Gdal.Dependency.Windows package (14.0.0), when added to a .NET Framework 4.8 project using a “new” SDK-style project file will dump all it’s runtime files into the application folder, in addition to the expected “runtime” folder. This is causing me issues with the different versions of DLLs it drops being favoured based on their proximity to my application.

Is there a way to stop it doing this?

Cheers

#2

Hi Kev,

Not very sure if we recreated the issue. Attached is a quick sample referencing ThinkGeo.Gdal package, and the image below is what’s in the bin folder. This is as expected as there’re managed assemblies in the bin, while all the native gdal files only exists under the runtimes folder.
SdkStyleRepro.zip (5.5 KB)

image
image1258×862 36.6 KB

ThinkGeo.Gdal.Dependency.Windows only includes the unmanaged dlls in the runtimes folder, the gdal related dlls you see in the above image comes from GDAL(3.9.1), maybe that’s where the conflicts are from? Are you using GDAL package, can you upgrade it to 3.9.1 as well?

Thanks,
Ben

#3

Hi Ben,
Thanks for the response. Sorry I should have been clearer, this was a WPF project. I thought I could reshuffle my dependencies to use a class library, but if I reference that class library in an application then I see the same issue as when I reference the package directly.

I’ve added a minimal WPF app to your sample that should illustrate the issue.

Cheers
SdkStyleReproWithApp.zip (15.6 KB)

#4

Hi Kev,

Thanks! We’ve recreated this issue and we are woking on it.

Thanks
Ben

#5

Hi Kev,

Finaly it’s been fixed in the latest beta040, please pull the latest and have a try.

Thanks,
Ben