SharpProj for platform target x64

[torbjornd]

Hi.
I'm trying to use this library in an ArcGIS Pro Add-in. The ArcGIS Pro SDK supports only x64, and I'm not able to use this library now. I first got the FileNotFoundException mentioned in #25 and after adding

<ItemGroup> <Content Include="$(NetCoreTargetingPackRoot)\Microsoft.NETCore.App.Host.$(NETCoreSdkRuntimeIdentifier)\$(BundledNETCoreAppPackageVersion)\runtimes\$(NETCoreSdkRuntimeIdentifier)\native\ijwhost.dll" Link="ijwhost.dll"> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </Content> </ItemGroup>

and

<PropertyGroup> <UseIJWHost Condition="'$(TargetFramework)' == 'net8.0'">true</UseIJWHost> </PropertyGroup>

I now get an error saying

System.BadImageFormatException: Could not load file or assembly 'C:...\net8.0\runtimes\win-x64\lib\netcoreapp\SharpProj.dll'. Format of the executable (.exe) or library (.dll) is invalid.

Does SharpProj support x64, or are you going to add this support any time soon?

[silsoe]

I believe the reason why it does not support x64 is because this configuration is missing from the project file:
SharpProj.NetTopologySuite.csproj
This project only has the "any CPU". If the x64 configuration is added, the package runs fine on an x64 only project I have created. My project is only running net6.0, so I do not know if there are other net8.0 issues.
It will be really nice it this gets fixed, and a new version of the nuget package is release. This makes maintenance a lot easier in the future.

[matthewsheeran]

Same problem here! I wrote my own x64 wrapper around Proj to transform geocoded points from OsGeo4Wx64 working so I'll stick with it instead!

I don't see any easy way to list available ESPG codes out of proj.db either - assuming that given any two codes in the DB Proi one can always transform between them! - so I may stick with my own solution for now even though this API is nicer as I have to DllImport handling Proj at a lower level instead (and there is a trick to fixing X and Y coords getting swapped)!

[rhuijben]

I use the library myself in an x64 project without issues. The problem is that there is no clean way to handle ijwhost.dll as a library. This always comes down to the final project in the chain.

See the tests on how to get all the epsg codes for CRSes.

Note that it is not always possible to convert between every other epsg code. There are independent groups of codes without intermediate transforms.

[matthewsheeran]

.NET 8.0 LTS x64 only windows builds and NO it is broke OOTB: Differerent compiler warning than above either MSIL or something perhaps because the library is built as AnyCPU only supporting dynamic x86 or x64 JIT at runtime.

I believe ChatGPT lied and you are right some transformations will fail BUT I/You can only get most of the proj.db EPSGs suppported through this library IFF it worked for me or else my own wrapper around OSGeo4W x64 Proj bin libs and share which only needs to list EPSGs and transform points for a Geocoder Service. I don't care for x86 for Geodata anymore because of the memory contraints nor should anyone else either or for AnyCPU (as you never know how it is going to actually load which always gives grief).

So SharpProj needs to be explicitly built for both x86 and x64 (as well as AnyCPU if you must). I am sticking with x64 only from here on in as AnyCPU only ever delivers headaches so any library which doesn't comply without incompatible warnings and the consequent runtime failures for x64 is history for me: ESRI and GDAL runtimes both build and work for x64 me but neither delivers the full list of EPSGs from proj.db.l which I desire.

If somebody wants to fix this I will retest for x64 me otherwise like I say: SharpProj is history! And I will pass on the exact compiler warning. I am no expert but my experieced gut tells me that x86 and AnyCPU both need to die a deserved death! Unfortunatley AnyCPU is still MS's default for new Projects - for now!

[matthewsheeran]

At least something seems to not be quite right but it doesn't appear to be my end: cf ESRI Runtime and GDAL .NET link just fine here and I tested the former..

Could even be a .NET 8.0 issue (if it hasn't been tested..).