Exception while using GDAL in C#

Question

I started to use gdal_csharp dll in my application and read a geotiff file. but it says:

The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.

it's my code

string fileName = @"/path to geotiff file";

OSGeo.GDAL.Dataset DS = 
    OSGeo.GDAL.Gdal.Open(fileName, OSGeo.GDAL.Access.GA_ReadOnly);

can anyone help?

Edit:

I have these dlls

enter image description here

This is the full error message:

enter image description here

It says that cannot load gdal_wrap. But when I'm going to add that dll to my application the below message is shown:

enter image description here

Is this code verbatim, or do you have a real path assigned to `fileName`? It also helps if you mention what you have done to try and solve this on your own. — Tieson T., Jan 16 '13 at 08:04
Since it is the type initializer it is not related to the fileName or the call to Open method. Check your dependencies first(.net/OS version/library) — Ventsyslav Raikov, Jan 16 '13 at 08:04
@Tieson T. Yes, a real path is assigned to the **fileName** variable. — Hossein Narimani Rad, Jan 16 '13 at 08:26
Most likely one or more dll (gdal is depended on) is missing. Can you post full stacktrace? — Leri, Jan 23 '13 at 10:49
As mentioned by PLB, it sounds like there is a dll missing, use Dependency Walker and Process Monitor to identify which one. — Appleman1234, Jan 23 '13 at 17:41
Look at the exception details (and edit them into your question). There should be an inner exception which shows you what went wrong in the type initializer. — Jon Skeet, Jan 24 '13 at 06:56
Was this problem ever resolved? I ran into the same problems using VS 2012 and GDALInfo.cs. — Markus M., May 06 '13 at 02:22

score 20 · Answer 1 · answered Jun 01 '16 at 19:42

20

As an update to this there is now GDAL maintained by the SharpMap team as a nuget package here which is updated regularly. You'll need to install both the "GDAL.Native" and "GDAL" package for your project to use the GDAL library. Once installed via nuget, they'll automatically create a "GdalConfiguration.cs" that you call into to initialize the GDAL paths before starting. The only thing to note is the packages are setup to automatically copy their appropriate GDAL libraries to your output build directory. If you need to deploy the application you'll have to do a bit of extra effort.

answered Jun 01 '16 at 19:42

DeusExMachina25

597
6
12

7

Yes, this is it. Key was to also install GDAL.Native. Beats me why they don't have it be a dependency on GDAL if you always need both. – Jonas Feb 21 '19 at 12:35
1

How do I deploy this? I'm getting this issue after deployment – tmndungu May 18 '20 at 06:15
1

Once you install GDAL and GDAL.Native you still need to call GdalConfiguration.ConfigureGdal(). – Corey Alix Jul 07 '21 at 14:50

nick_w · Answer 2 · 2013-02-05T09:00:12.300

To solve this one I downloaded the prebuilt libraries as described here and grabbed FWTools from here.

The unmanaged DLLs I used came from \install_dir\FWTools2.4.7\bin and the C# wrapper from \install_dir\FWTools2.4.7\csharp.

gdal14.dll, msvcp71.dll and msvcr71.dll came from here, which is mentioned in that first link.

The error you are receiving re gdal_wrap.dll is referring to one of its dependencies. I threw that DLL into depends and it found a lengthy list of dependent libraries. Note that this list is likely longer due to my use of the FWTools distribution - if you built your version from source it may look different, though the same principles apply.

To get the above code to work on my machine I had the following files in my output directory:

gdal14.dll
gdalconst_csharp.dll
gdalconst_wrap.dll
gdal_csharp.dll
gdal_fw.dll
gdal_wrap.dll
geos_fw.dll
geotiff_fw.dll
hdf5dll.dll
hdf_fw.dll
jpeg12_osgeo.dll
jpeg_osgeo.dll
libcurl.dll
libeay32.dll
libexpat.dll
libmysql.dll
libpq.dll
libtiff_fw.dll
lti_dsdk_dll.dll
mfhdf_fw.dll
msvcp71.dll
msvcr71.dll
NCScnet_fw.dll
NCSEcw_fw.dll
NCSUtil_fw.dll
netcdf.dll
ogdi_32b1.dll
proj.dll
sqlite3.dll
ssleay32.dll
szlibdll.dll
xerces-c_2_7.dll
zlib1.dll
zlib_osgeo.dll

Now these don't necessarily all have to live in the output directory - as long as they are on your path somewhere (e.g., \Windows\System32) you should be fine.

score 5 · Answer 3 · answered Dec 09 '15 at 14:47

I know it's an old question, but I believe my answer might help someone.

I was able to successfully compile and run examples using c# gdal by doing the following:

Downloading GDAL sdk from http://www.gisinternals.com/ (64 bit in my case)
Executing the SDKShell.bat script to set the system environment paths, etc.
Creating a project in Visual Studio. And referencing all .net dlls (the ones that names end with _csharp.dll), located in \bin\gdal\csharp\ inside downloaded SDK
Setting platform target in Visual Studio project settings to x64 to get rid og bad image format exceptions. The last step wouldn't be necessary if I'd choosse 32bit version of SDK to work with.

I did not install fwtools at all. It seems like the last build of fw_tools is relatively old, and sdk is still maintained.

`Setting platform target in Visual Studio project settings to x64` this part helps me. — Kliver Max, Sep 28 '18 at 08:54

score 3 · Answer 4 · answered Jun 24 '16 at 21:24

I know this is a reasonably old question now, but I found this in google after researching the same problem myself, so this means that for searches on this error this is still a very relevant page to update given it's still in the top 5 from the big G when the same problem is searched.

In my case it was the answers from "DeusExMachina25" and "Grzegorz Sławecki" that struck a chord.

I'm writing some software that makes use of the current builds of "sharp map" on NUGet (as of 24th of June 2016) and my software kept throwing the same gdal_wrap message as the OP originally reported, even though I'm using the GDAL package provided by the Sharpmap team.

I didn't realize that the NUGet installer for the package had installed a configuration class for me, but after reading through this thread and finding out that it does I went looking for it.

Sure enough I found the file 'GdalConfiguration.cs' in my project and added a call to it in an appropriate place in my project, expecting GDAL to be initialized correctly.

However, after I did this, I still had the same problem.

So, I set a break point on the beginning of the GDAL routine that had been added, and waited until the break point was hit.

I then traced through the method, and eventually found the following line:

var gdalPath = Path.Combine(executingDirectory, "gdal");

at around line 64 in the file.

Tracing through this, I noticed that the path being built was:

d:\geodata\maptest\maptest\bin\debug\gdal

but the NUGet installer had installed all the dependent assemblies in

d:\geodata\maptest\maptest\bin\debug

Exactly where I expected them to be.

I changed line 64 so that it now read:

var gdalPath = Path.Combine(executingDirectory, "");

and voila, the error went away and everything started to work.

I could have done things the other way too, and created a folder called gdal, then copied everything into that, but that then would have gotten deleted when I did a "clean" on the project.

Since the config class, set's up various environment variables based on this path, quickly changing that one line also fixes up the path for the GDAL data files , plugins and a few other things too.

score 1 · Answer 5 · answered Jan 29 '13 at 17:56

1

You could try using Dependency Walker to see if there are any dlls that gdal_csharp is trying to grab but cannot.

answered Jan 29 '13 at 17:56

Cemafor

1,633
12
27

@Appleman1234 - Sorry, I didn't see that you already suggested that. – Cemafor Jan 29 '13 at 17:57
@Hossein - Try copying the dll to the output directory eather manually or with a Build Event or adding it to your project (not as a reference) and setting the "Copy to Output Directory". See this [related question](http://stackoverflow.com/questions/239881/c-how-to-include-dependent-dlls) – Cemafor Jan 29 '13 at 19:42
I was just looking back at the popup you posted. The dll will need to be put in the folder where your exe is, probably the bin/debug or release sub-folders in your project. – Cemafor Jan 30 '13 at 03:09
Is it still looking for gdal_wrap.dll or a different dll? – Cemafor Jan 30 '13 at 19:08
Yes, it is still looking for gdal_wrap.dll! – Hossein Narimani Rad Jan 30 '13 at 19:09

score 1 · Answer 6 · answered Feb 14 '13 at 13:20

1

Have you added the path to your GDAL libraries to your PATH environment variable? I downloaded my files from http://vbkto.dyndns.org/sdk/?_sm_au_=iVVqjsHS2n46WP00 and here's my path: C:\libs\release-1600-gdal-1-9-mapserver-6-2\bin.

answered Feb 14 '13 at 13:20

Emmster

159
1
8

score 0 · Answer 7 · answered May 06 '13 at 21:16

To use the C#-bindings of GDAL you need an installation of FWTools (from http://fwtools.maptools.org/) as well as the most current binaries that match your system (from http://vbkto.dyndns.org/sdk/). Afterwards it is important to include the bin-directory of FWTools (example for 64bit-systems: C:\Program Files (x86)\FWTools2.4.7\bin) in your PATH variable as well as the necessary dlls (gdal_csharp.dll was mentioned in the question) in your Visual Studio project references. I outlined the complete processs here.

This process works on 32 bit as well as 64 bit systems, I tested it with VS 2010 and 2012.

score 0 · Answer 8 · answered Jul 02 '19 at 14:41

0

Remove the path to python from the system variables. Because the main gdal paths conflict with python 27

answered Jul 02 '19 at 14:41

Burcu Amirgan

1
1

score 0 · Answer 9 · answered Dec 20 '21 at 20:05

0

Did you forget to:

GdalConfiguration.ConfigureGdal();
GdalConfiguration.ConfigureOgr();

Gdal.AllRegister();
Ogr.RegisterAll();

answered Dec 20 '21 at 20:05

Mike J Gibson

1
1

score 0 · Answer 10 · answered Mar 15 '22 at 10:08

In my case the issue was:

I had 2 projects in my solution: ProjectA and ProjectB
I was executing ProjectA, and ProjectA was referencing ProjectB
ProjectB is the one that contained the references to both GDAL and GDAL.Native
ProjectA tried to find GDAL.Native's files under ProjectA\bin\Debug\netcoreapp3.1\gdal ... but in reality those files are under ProjectB\bin\Debug\netcoreapp3.1\gdal

Possible solutions:

Dirty solution: just copy the files from ProjectB under ProjectA\bin\Debug\netcoreapp3.1
Okayish solution: add the GDAL.Native package to each one of your "entry projects"

I don't like either of those solutions. This stuff happens under GdalConfiguration.cs, so maybe there is a way to modify it to find the correct path.

score 0 · Answer 11 · answered Feb 28 '23 at 10:12

Fixed it by changing config line from

string executingAssemblyFile = new Uri(Assembly.GetExecutingAssembly().GetName().CodeBase).LocalPath;
executingDirectory = Path.GetDirectoryName(executingAssemblyFile);

to

executingDirectory = Directory.GetCurrentDirectory();

Exception while using GDAL in C#

11 Answers11

Linked

Related