ThinkGeo.com    |     Documentation    |     Premium Support

Mismatch processor architecture with FileGDB Nuget

#1

I tried installing the ThinkGeo.FileGeoDatabase Nuget Package. 14.4.0 Beta005
I get following warning:

There was a mismatch between the processor architecture of the project being built “MSIL” and the processor architecture of the reference “.nuget\packages\thinkgeo.dependency.filegeodatabase\14.0.0\lib\net462\Esri.FileGDBAPI.dll”, “AMD64”. This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

When trying to run the project, I get following FusionLog:

=== State information before binding ===
LOG: DisplayName = Esri.FileGDBAPI, Version=1.5.2.308, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86
(Fully-specified)
LOG: Appbase = file://bin/Debug/
LOG: Original PrivatePath = NULL
LOG: DynamicBase = NULL
LOG: CacheBase = NULL
LOG: AppName = Viewer.exe
Call of Assembly : ThinkGeo.FileGeoDatabase, Version=14.0.0.0, Culture=neutral, PublicKeyToken=0828af5241fb4207.

LOG: This binding starts in the default load context.
LOG: The application configuration file is used: \bin\Debug\Agk_Viewer.exe.Config
LOG: The host configuration file is used:
LOG: The computer configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config is used.
LOG: Reference according to the policy: Esri.FileGDBAPI, Version=1.5.2.308, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86
LOG: The search in the GAC was not successful.
LOG: Download from new URL file:file://bin/Debug/Esri.FileGDBAPI.DLL.
LOG: The assembly download has been performed. File setup is started: \bin\Debug\Esri.FileGDBAPI.dll.
LOG: The setup phase executed by the source begins.
LOG: The assembly name is: Esri.FileGDBAPI, Version=1.5.2.308, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86.
ERR: Invalid assembly platform or ContentType in file (hr = 0x8007000b).
ERR: The setup phase executed by the source failed with hr = 0x8007000b.
ERR: The assembly setup could not be completed (hr = 0x8007000b).

Do you have any idea how to handle this?
Thank you!

#2

It’s because the ThinkGeo FileGDB is x64 only, change the build platform from “Any CPU” to “x64” will get rid of the warning. Even it’s “Any CPU”, it will not have the runtime error if it’s built in x64.

So did you build the project in x86? any chance you can use x64 to build your application?

#3

Hi Ben, thanks, our application sadly needs to run on x32 and x64 Windows Systems. Any chance we can get an Any CPU runtime of ThinkGeo FileGDB?

If I am mistaken please let me know, this is not my forte :slight_smile:

#4

OK Julian, I’ve added to the Todo list, aiming for the release v14.3.2.

1 Like
#5

Hi Ben, to plan our work can you confirm whether this change is included in 14.3.2 this month?

#6

Hi Julian,

I’m afraid a true “AnyCPU” build against Esri.FileGDBAPI.dll (the entry dll in ThinkGeo.Dependency.FileGeoDatabase) isn’t possible because that assembly is a mixed‑mode (C++/CLI) DLL, so it must be loaded into a matching‑bitness process (either x86 or x64). Here’s the detail:

  1. Mixed‑mode constraint
  • Esri.FileGDBAPI.dll can’t run in an MSIL (“AnyCPU”) process—you’ll always get the MSB3270 warning (and eventually a FileNotFound/BadImageFormat at runtime) unless your EXE is explicitly built for x86 or x64.
  1. What’s in 14.3.2
  • In the upcoming 14.3.2 release we’ve added an x86 version of the native DLL and improved our NuGet targets so that when you do build for x86 or x64, the warning disappears and the correct native DLL is automatically deployed.
  1. Why we can’t hide it
  • We could swap in a P/Invoke‑only loader to choose the right native DLL at runtime, but that would require re‑writing every API signature and incur a performance hit.
  1. If you must stay AnyCPU
  • As an alternative you might evaluate our ThinkGeo.Gdal package + GdalFeatureLayer . It uses GDAL’s FileGDB driver via P/Invoke and will load in both 32‑ and 64‑bit processes, though it is somewhat slower than the Esri API.

I hope that helps—let me know if you have any other questions.

Thanks,
Ben

#7

Hi Julian,

Here is a quick update: as we approach the v14.3.2 release, we’ve decided not to include x86 support for Esri.FileGDBAPI.dll because:

  1. Esri no longer distributes an x86 version of FileGDBAPI.dll in recent releases. Supporting x86 would require reverting to a version that is over eight years old, which carries compatibility and security risks.
  2. As mentioned above, even with an x86 binary, it will have issues under AnyCPU anyway as an inherent limitation of C++/CLI assemblies.

Please use GDAL’s FileGDB driver if you want to support “Any CPU”, or just set it to X64 to remove the warnings.

Thanks,
Ben

#8

Hi Ben, thanks, that makes sense, I will try the GDAL FileGDB

#9

Thanks for the understanding! Here is the FileGDB SDK from ESRI, https://github.com/Esri/file-geodatabase-api, we will integrate the x86 if they do support it in the future versions.