File Geodatabase dependency missing

5387
1
Jump to solution
01-26-2016 02:20 AM
umarshahid
New Contributor

I am using **File Geodatabase AP**I into my own MFC C++ application (which only reads data from .gdb folders). I have include all the headers and libraries required for the api in the project Properties section. (except **FileGDBAPI.dll** and **FileGDBAPID.dll** files because i don't know the the including directory for them). there is no compile time error but when i create any object from FileGDBAPI (e.g `GeoDatabase geodatabase;`) then i am getting an error **"the appliaction was unable to start correctly (0xc000007b). Click OK to close the application"**

Can someone please tell me what i am ignoring or anything that can make this error go away.

How can i add *.dll files related to File Geodatabase API?

0 Kudos
1 Solution

Accepted Solutions
VinceAngelo
Esri Esteemed Contributor

This doesn't have to do with the FileGDB API so much as Visual Studio/Windows software development.  Esri ships two libraries, the link library in lib, and the runtime library in bin.  The link library is just a set of stubs so the compiler knows the DLL function signatures, and the runtime library contains the actual file geodatabase functions.

Actually, it's a bit more complicated than that, because Esri ships three different API implementations for Windows, for Visual Studio 2010, 2012, and 2013, and each of them have both 32-bit and 64-bit libraries, and each of those have DEBUG and NDEBUG builds.  And then there's the C# library, Esri.FileGDBAPI.dll, with one wrapper library per application word-size per compiler environment.  And the matching PDB files, of course. (And there's 32-bit and 64 bit Linux releases, and GCC and CLANG MacOS releases.)

As a software developer, you should not ever need to ship FileGDBAPID.dll, since the larger, slower debug libraries aren't of much use in production environments, so only FileGDBAPI.dll needs to be copied into the bin folder of your application (from bin or bin64, depending on which way you've compiled your application).  For local testing purposes, you can include the runtime distribution folder in your local PATH, but it's best practice to test out of your application's bin folder, so you don't have to deal with runtime link issues later in the production chain.

The location for those libraries is dependent on the location to which you've extracted the API zipfile, so we can't help you on that score.  I would recommend that you set an environment variable for the File Geodatabase API home (e.g. FGDBAPI_HOME), so that you can use that environment variable in your VS projects -- in this way subsequent releases don't require rewriting all your project parameters. 

fgdbapi1.jpg

Visual Studio allows for command execution after successful compile (the "Post-Build" event in "Build Events"), so you can even automate the process of copying both your compiled binary and the runtime DLL into a BAT script if you choose (the details for that are off-topic here).

- V

BTW: GeoNet doesn't use gis.stackexchange.com formatting techniques, so duplicate cross-posts are not going to look the same.

View solution in original post

1 Reply
VinceAngelo
Esri Esteemed Contributor

This doesn't have to do with the FileGDB API so much as Visual Studio/Windows software development.  Esri ships two libraries, the link library in lib, and the runtime library in bin.  The link library is just a set of stubs so the compiler knows the DLL function signatures, and the runtime library contains the actual file geodatabase functions.

Actually, it's a bit more complicated than that, because Esri ships three different API implementations for Windows, for Visual Studio 2010, 2012, and 2013, and each of them have both 32-bit and 64-bit libraries, and each of those have DEBUG and NDEBUG builds.  And then there's the C# library, Esri.FileGDBAPI.dll, with one wrapper library per application word-size per compiler environment.  And the matching PDB files, of course. (And there's 32-bit and 64 bit Linux releases, and GCC and CLANG MacOS releases.)

As a software developer, you should not ever need to ship FileGDBAPID.dll, since the larger, slower debug libraries aren't of much use in production environments, so only FileGDBAPI.dll needs to be copied into the bin folder of your application (from bin or bin64, depending on which way you've compiled your application).  For local testing purposes, you can include the runtime distribution folder in your local PATH, but it's best practice to test out of your application's bin folder, so you don't have to deal with runtime link issues later in the production chain.

The location for those libraries is dependent on the location to which you've extracted the API zipfile, so we can't help you on that score.  I would recommend that you set an environment variable for the File Geodatabase API home (e.g. FGDBAPI_HOME), so that you can use that environment variable in your VS projects -- in this way subsequent releases don't require rewriting all your project parameters. 

fgdbapi1.jpg

Visual Studio allows for command execution after successful compile (the "Post-Build" event in "Build Events"), so you can even automate the process of copying both your compiled binary and the runtime DLL into a BAT script if you choose (the details for that are off-topic here).

- V

BTW: GeoNet doesn't use gis.stackexchange.com formatting techniques, so duplicate cross-posts are not going to look the same.