Исключение при использовании GDAL в C#

Question

Я начал использовать dll gdal_csharp в своем приложении и читать файл geotiff. но это говорит:

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

это мой код

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

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

кто-нибудь может помочь?

Редактировать:

У меня есть эти библиотеки

Это полное сообщение об ошибке:

Это говорит о том, что не может загрузить gdal_wrap, Но когда я собираюсь добавить эту DLL к моему приложению, появится следующее сообщение:

Answer 1

В качестве обновления к этому теперь GDAL поддерживается командой SharpMap как пакет nuget, который регулярно обновляется. Вам необходимо установить оба пакета "GDAL.Native" и "GDAL", чтобы ваш проект использовал библиотеку GDAL. После установки с помощью nuget они автоматически создадут "GdalConfiguration.cs", который вы вызываете для инициализации путей GDAL перед запуском. Единственное, на что нужно обратить внимание, так это на то, что пакеты настроены на автоматическое копирование соответствующих им библиотек GDAL в ваш выходной каталог сборки. Если вам нужно развернуть приложение, вам придется приложить дополнительные усилия.

Answer 2

Чтобы решить эту проблему, я скачал готовые библиотеки, как описано здесь, и взял FWTools отсюда.

Неуправляемые библиотеки DLL, которые я использовал, пришли из \install_dir\FWTools2.4.7\bin и оболочка C# из \install_dir\FWTools2.4.7\csharp,

gdal14.dll, msvcp71.dll а также msvcr71.dll пришел отсюда, который упоминается в этой первой ссылке.

Ошибка, которую вы получаете повторно gdal_wrap.dll ссылается на одну из его зависимостей. Я бросил эту DLL в depends и он нашел длинный список зависимых библиотек. Обратите внимание, что этот список, вероятно, длиннее из-за моего использования дистрибутива FWTools - если вы создали свою версию из исходного кода, она может выглядеть иначе, хотя применяются те же принципы.

Чтобы приведенный выше код работал на моей машине, в выходном каталоге у меня были следующие файлы:

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

Теперь все они не обязательно должны находиться в выходном каталоге - пока они находятся где-то на вашем пути (например, \Windows\System32Вы должны быть в порядке.

Answer 3

Я знаю, что это старый вопрос, но я верю, что мой ответ может кому-то помочь.

Я смог успешно скомпилировать и запустить примеры, используя C# gdal, выполнив следующие действия:

1. Загрузка GDAL SDK с http://www.gisinternals.com/ (64 бит в моем случае)
2. Выполнение SDKShell.bat скрипт для установки путей к системной среде и т. д.
3. Создание проекта в Visual Studio. И ссылки на все.net DLL (те, имена которых заканчиваются на _csharp.dll), находится в \bin\gdal\csharp\ внутри скачанный SDK
4. Установка целевой платформы в настройках проекта Visual Studio на x64, чтобы избавиться от плохих исключений формата изображения. Последний шаг не был бы необходим, если бы я выбрал 32-битную версию SDK для работы.

Я вообще не устанавливал fwtools. Похоже, что последняя сборка fw_tools относительно старая, и sdk все еще поддерживается.

Answer 4

Я знаю, что это довольно старый вопрос сейчас, но я нашел его в Google после исследования той же самой проблемы, так что это означает, что для поиска по этой ошибке это все еще очень актуальная страница для обновления, поскольку она все еще в топ-5 из большой G, когда та же проблема ищется.

В моем случае это были ответы от "DeusExMachina25" и "Grzegorz Sławecki", которые вызвали отклик.

Я пишу какое-то программное обеспечение, которое использует текущие сборки "точной карты" в NUGet (по состоянию на 24 июня 2016 года), и мое программное обеспечение продолжало выдавать то же сообщение gdal_wrap, которое первоначально сообщал OP, хотя я использую Пакет GDAL, предоставленный командой Sharpmap.

Я не осознавал, что установщик NUGet для пакета установил для меня класс конфигурации, но после прочтения этого потока и выяснения того, что он делает, я начал его искать.

Конечно же, я нашел файл 'GdalConfiguration.cs' в своем проекте и добавил к нему вызов в соответствующем месте в моем проекте, ожидая, что GDAL будет правильно инициализирован.

Однако после того, как я это сделал, у меня все еще была та же проблема.

Итак, я установил точку останова в начале добавленной подпрограммы GDAL и ждал, пока точка останова не будет достигнута.

Затем я проследил этот метод и в итоге нашел следующую строку:

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

около строки 64 в файле.

Прослеживая это, я заметил, что путь был построен:

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

но установщик NUGet установил все зависимые сборки в

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

Именно там, где я и ожидал.

Я изменил строку 64 так, чтобы она теперь читала:

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

и вуаля, ошибка ушла, и все начало работать.

Я мог бы сделать что-то иное и создать папку с именем gdal, а затем скопировать все в нее, но это было бы удалено, когда я произвел "очистку" проекта.

Так как класс config устанавливает различные переменные среды на основе этого пути, быстрое изменение этой строки также исправляет путь к файлам данных GDAL, плагинам и некоторым другим вещам.

Answer 5

Вы можете попробовать использовать Dependency Walker, чтобы увидеть, есть ли какие-либо библиотеки, которые gdal_csharp пытается получить, но не может.

Answer 6

Вы добавили путь к своим библиотекам GDAL в переменную среды PATH? Я скачал свои файлы с http://vbkto.dyndns.org/sdk/?_sm_au_=iVVqjsHS2n46WP00 и вот мой путь: C:\libs\release-1600-gdal-1-9-mapserver-6-2\bin.

Answer 7

Для использования C#-привязок GDAL вам нужна установка FWTools (с http://fwtools.maptools.org/), а также самые последние двоичные файлы, которые соответствуют вашей системе (с http://vbkto.dyndns.org/sdk/). После этого важно включить в вашу переменную PATH переменную bin- директории FWTools (например, для 64-битных систем: C: \ Program Files (x86) \ FWTools2.4.7 \ bin), а также необходимые библиотеки DLL (gdal_csharp.dll был упомянут в вопросе) в ваших ссылках проекта Visual Studio. Я обрисовал в общих чертах процессы здесь.

Этот процесс работает как на 32-битных, так и на 64-битных системах, я тестировал его с VS 2010 и 2012.

Answer 8

Удалите путь к python из системных переменных. Поскольку основные пути gdal конфликтуют с python 27

Answer 9

Исправлено, изменив строку конфигурации с

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

к

      executingDirectory = Directory.GetCurrentDirectory();

Answer 10

В моем случае проблема заключалась в следующем:

• У меня было 2 проекта в моем решении: и

• Я выполнял и ссылался

• это тот, который содержал ссылки на оба GDALа также

• ProjectAпопытался найти файлы GDAL.Native под ProjectA\bin\Debug\netcoreapp3.1\gdal... но на самом деле эти файлы находятся под ProjectB\bin\Debug\netcoreapp3.1\gdal

---

Возможные решения:

• Грязное решение: просто скопируйте файлы из ProjectBпод ProjectA\bin\Debug\netcoreapp3.1

• Нормальное решение: добавить GDAL.Nativeпакет для каждого из ваших «входных проектов»

---

Мне не нравится ни одно из этих решений. Это происходит под GdalConfiguration.cs, поэтому, возможно, есть способ изменить его, чтобы найти правильный путь.

Answer 11

Вы забыли:

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

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