Dependency management

[John_Gibb]

I’ve noticed on the more recent version of some packages that dependencies are being placed at the root level of the output directory when compiling (the same directory as the exe).

In my app using ThinkGeo.Gdal (13.0.0-beta319) as well as Spatialite causes a conflict due to both libraries being dependant on different versions of zlib1.dll.

I am currently able to work around this using a post-build step to delete the zlib placed by the thinkgeo dependency, which seems to function for my purposes (although this remains to be fully tested).

Is there a better way that this could be handled?

Cheers,
John

[Ben]

Hi John,

To avoid conflicts, ThinkGeo’s GDAL dependencies are put under the subfolder runtimes{environment}\native, for example: zlib1.dll should locate under bin\Debug\runtimes\win-x64\native instead the root folder. Can you check if there’s any customized actions (postbuild events for example) moving them to the sub folder? If not, can you send me a screenshot of your bin folder?

Thanks,
Ben

[John_Gibb]

Hi Ben,

Here are the screenshots of the bind folder of a test app I made. I created a new WPF app targeting net48 - x64.

I added only the ThinkGeo.Gdal 13.0.0-beta322 package and its dependencies.

I’ve also included the test app see bellow.

ThinkGeoDependencies.zip (79.2 KB)

Cheers,
John

[Leo_Liu]

hi John,

Thanks for your sample, I can easily reproduce this issue on my local.

Also I tried to create a pure simple project and install ThinkGeo.Gdal via nuget like yours, zlib1 stayed runtimes{environment}\native folder and wasn’t in the root folder like what Ben said. I believe there’s something different in your project.

Anyway, I’ll keep digging and will let you know what I find.

Thanks,
Leo

[Leo_Liu]

hi John,

I tried to compare your project file and mine, and found they’re totally different. As you can see below, the left one is yours, it’s really simple and has no much content, the right one is mine, and it was created by visual studio 2019. I’m curious about how did you create this ThinkGeoDependencies project.

Thanks,
Leo

[John_Gibb]

Hi Leo,

The project was created using Visual studio 2022. I created a project using the net5 ‘WPF Application’ template, then re-targeted it to net48 on a x64 platform.

I have also been able to replicate the same behaviour with the HowDoI sample WPF app (https://github.com/ThinkGeo/Desktop-Maps/tree/master/samples/wpf) by settings the target platform to x64 with target framework at net472 (this was with the latest beta nuget packages).

Thanks,
John.

[Ben]

Hi John,

I created a new net5 WPF application in VS 2022 and added ThinkGeo.Gdal Nuget package, it works fine. zlib1.dll was copied to runtime\native folder as expected.

I created a new net4.8 WPF application and added ThinkGeo.Gdal Nuget package, it works fine. zlib1.dll was also copied to runtime\native folder as expected.

I created a new net5 WPF application and tried to convert it to dotnet framework 4.8 in its project property:

First I got the following issue:

After fixing the issue by removing " enable" from the project file, and rebuild the project, I can now recreate your problem.

So it turned out a .net framework project is not the same if you create a .net core project and then convert it to .net framework. I think it’s a bug from Microsoft as it’s unexpected.

Anyway, recreating a .NET Framework Project should be able to fix this issue.

Thanks,
Ben

[John_Gibb]

Hi Ben,

Unfortunately the project I’m working on (which I’m upgrading from version 11 of MapSuite) uses SDK-style projects, so I am unable to switch to a .NET Framework Project.

Is there anything that can be done about this on your side?

Cheers,
John

[Ben]

Just for anyone who happens to encounter the same issue: this issue was resolved within ThinkGeo’s package in March 2022.