maxrev-dev / gdal.netcore

GDAL 3.x C#/F# bindings for .NET apps

gdal.netcore

A simple (as is) build engine of GDAL library for .NET.

Provides a minimal setup without requirements to install heavy GDAL binaries into your system.

Packages (NuGet)

MaxRev.Gdal.Universal

MaxRev.Gdal.Core

MaxRev.Gdal.WindowsRuntime.Minimal

MaxRev.Gdal.LinuxRuntime.Minimal

• MaxRev.Gdal.LinuxRuntime.Minimal.x64
  
• MaxRev.Gdal.LinuxRuntime.Minimal.arm64
  

MaxRev.Gdal.MacosRuntime.Minimal

• MaxRev.Gdal.MacosRuntime.Minimal.x64
  
• MaxRev.Gdal.MacosRuntime.Minimal.arm64

Table Of Contents

Show

• Packages (NuGet)
• Table Of Contents
• About this library
  • What is this library
  • What is not
• How to use
  • Universal package
  • Separate core and runtime packages
  • Initialize libraries in runtime
• Supported runtimes
• Using GDAL functions
• Development
• How to compile on Windows
• How to compile on Unix
• About build configuration
• Building runtime libraries
• FAQ
  • Q: Packages does not work on CentOS 7, Ubuntu 18.04
  • Q: Can I compile it on Ubuntu or another Unix-based system?
  • Q: Projections are not working as expected
  • Q: Some drivers complain about missing data files
  • Q: Missing {some} drivers, can you add more?
  • Q: GDAL functions are not working as expected
  • Q: Some types throw exceptions from SWIG on Windows
  • Q: In some methods performance is slower on Unix
  • Q: OSGeo.OGR.SpatialReference throws System.EntryPointNotFoundException exception
  • Q: Packages does not work on MacOS Catalina or lower
  • Q: The first run on MacOS is slow and takes more than 3 seconds
  • Q: BadImageFormatException on Windows
  • Q: Publishing the project with runtime packages
• About and Contacts
• Acknowledgements

Table of contents generated with markdown-toc

About this library

What is this library

• Only generates assemblies and binds everything into one package.
• Provides easy access to GDAL by installing only core and runtime package
• DOES NOT require installation of GDAL. From 3.7.0 version GDAL_DATA is also shipped. While it contains the proj.db database you may require proj-data grid shifts.

What is not

• Does not compile all drivers. Only configured, they are listed below. By default GDAL has a lot of internal drivers.
• Does not change GDAL source code.
• Does not extend GDAL methods.

How to use

Universal package

1. Install universal package - MaxRev.Gdal.Universal. It references all runtime packages and the core package. They will be automatically installed during restore. Note that this may increase the size of your nuget cache.

dotnet add package MaxRev.Gdal.Universal

Separate core and runtime packages

1. Install core package - MaxRev.Gdal.Core

dotnet add package MaxRev.Gdal.Core

2. Install libraries for your runtime. You can install one of them or all with no conflicts. There is no requirement to install all of them or GDAL binaries. If you work on Windows and Linux you can skip MacOS package and vice versa.

# windows supported only for x64
dotnet add package MaxRev.Gdal.WindowsRuntime.Minimal 

# install linux bundle which references both arm64 and x64 binaries
dotnet add package MaxRev.Gdal.LinuxRuntime.Minimal 
# or install a specific runtime
dotnet add package MaxRev.Gdal.LinuxRuntime.Minimal.arm64
dotnet add package MaxRev.Gdal.LinuxRuntime.Minimal.x64

# install macos bundle which references both arm64 and x64 binaries
dotnet add package MaxRev.Gdal.MacosRuntime.Minimal 
# or install a specific runtime
dotnet add package MaxRev.Gdal.MacosRuntime.Minimal.arm64
dotnet add package MaxRev.Gdal.MacosRuntime.Minimal.x64

Initialize libraries in runtime

using MaxRev.Gdal.Core;
// call it once, before using GDAL
// this will initialize all GDAL drivers and set PROJ6 shared library paths
GdalBase.ConfigureAll();

4. Profit! Use it in ordinary flow. See the section below for more info.

Supported runtimes

• Windows x64 (.NET Framework 4.6.1+, .NET Standard 2.0+, .NET 6/7/8+)
• Linux x64/arm64 (.NET Framework 4.6.1+, .NET Standard 2.0+, .NET 6/7/8+)
• MacOS x64/arm64 (.NET Framework 4.6.1+, .NET Standard 2.0+, .NET 6/7/8+)

This means you can build .NET Framework applications on Linux/MacOS using Mono. Also, any project based on NET Standard 2.0 or higher can utilize this library.

Using GDAL functions

If you're struggling using GDAL functions. Here's a good place to start:

• Vector related operations
• Raster related operations
• Sample Apps

Development

How to compile on Windows

Enter win directory to find out how.

How to compile on Unix

Detailed guide is here - unix.

How to compile on macOS

Detailed guide is here - osx.

About build configuration

The package configuration is marked as minimal. That means you don't have to install GDAL binaries. Also, some uncommon drivers are not available (were not built).

Drivers included PROJ, GEOS, and more than 200 other drivers.

To view the complete list of drivers, see: tests/gdal-formats/supported_drivers.md.

NOTE: Runtime drivers availability may differ. Ask me about a specific driver for runtime. Please issue if I need to mention any packages.

Starting version 3.9.0 the packages can be compiled and run on .NET Framework 4.6.1+. The libraries and gdal-data will be automatically copied to the output directory. See tests/MaxRev.Gdal.Core.Tests.NetFramework for more info.

Building runtime libraries

Each runtime has to be build separately, but this can be done concurrently as they are using different contexts (build folders). Primary operating bindings (in gdal.core package) are build from windows. Still, the resulting core bindings are the same on each runtime package (OS).

To make everything work smoothly, each configuration targets the same drivers and their versions, respectively.

To start building for a specific runtime, see the README.md in a respective directory.

FAQ

Q: Packages does not work on CentOS 7, Ubuntu 18.04

A: These are old distros and are out of support (EOL). Use docker (see this Dockerfile how to package your app) or a newer distro (GLIBC 2.31+). Packages for older systems are difficult to maintain. From 3.6.x version the Debian 11 distro is used. See this for more info.

Q: Can I compile it on Ubuntu or another Unix-based system?

A: Yes, you can (see unix folder for readme). All you have to do, is to choose one of the latest distros like Ubuntu 22.04 or Debian 11 (recommended). From the 3.6.x version the Debian 11 distro is used by default. It was changed because of EOL of the previous distro (see answer above). Prior to 3.6.x version packages were built on CentOS - glibc of version 2.17. It's the lowest version (in my opinion) that suits all common systems (Ubuntu, Debian, Fedora).

Q: Projections are not working as expected

A: This package only contains the proj.db database. Make sure you have installed proj-data package. It contains aditional grid shifts and other data required for projections. Add path to your data folder with MaxRev.Gdal.Core.Proj.Configure(). See this for more info.

Q: Some drivers complain about missing data files

A: This is related to the previous package versions (prior to 3.7.0). From 3.7.0 version, GDAL_DATA folder is also shipped with core package.

Q: Missing {some} drivers, can you add more?

A: Feel free to contribute and I will help you you to add them. Here's the my additional answer.

Q: GDAL functions are not working as expected

A: Try to search an issue on github. In 98% of cases, they are working fine.

Q: Some types throw exceptions from SWIG on Windows

A: Yes, currently there are some redundant types in OGR namespace. This will be fixed in the next builds.

Q: In some methods performance is slower on Unix

A: Apparently, it's not a fault of the build engine. I did not face this issue and I use this packages in several production environments.

Q: OSGeo.OGR.SpatialReference throws System.EntryPointNotFoundException exception

A: That's a problem with swig bindings. Please, use SpatialReference type from OSR namespace. More info here and here.

Q: Packages does not work on MacOS Catalina or lower

A: The current version of packages was compiled on MacOS Ventura and 11.3 SDK respectively. Consider updating your system to at least MacOS 13. The systems that reached EOL (end-of-life) won't be supported.

Q: The first run on MacOS is slow and takes more than 3 seconds

A: It's a known issue related to the linking of the shared libraries. If you find any solution/workaround, please let me know. Currently, linker tries to find all shared libraries in the @loader_path/. It should point to the executable directory.

Q: BadImageFormatException on Windows

A: Ensure that you are using the same architecture for your project and the runtime package. If you are using AnyCPU, you should use only the x64 runtime package. See the sample project for details in tests/MaxRev.Gdal.Core.Tests.NetFramework.

Q: Publishing the project with runtime packages

A: There are several ways to publish. One important thing to keep in mind, that you have to ensure the output folder contains either runtimes/<os>-<arch>/native path, gdal-data folder and maxrev.gdal.core.libshared/proj.db. In most cases this should be handled automatically by dotnet. Usually, we release a runtime-dependent binary. The end user will have to install the .NET runtime, but the size of the app will be small and the build time is faster. Otherwise, you can publish a self-contained app which will include all required .NET runtime libraries. More details on publishing can be found here. Also, see the sample dockerized project for details in tests/MaxRev.Gdal.Core.Tests/Dockerfile.

About and Contacts

This work is based on GDAL and GDAL bindings by jgoday.

Contact me in Telegram - MaxRev.

Enjoy!

Acknowledgements

As the maintainer of this repository, I want to express my heartfelt thanks to Verge Agriculture Inc.. They generously provided the necessary resources that made compiling the macOS bindings and the latest versions of GDAL possible.

gdal.netcore's Issues

[BUG] Namespace OSGeo.OGR contains non-functional SpatialReference class

Describe the bug
The namespace OSGeo.OGR contains non-functional SpatialReference class. I think it is not to be there at all. Attempts to use it by calling constructor new OSGeo.OGR.SpatialReference([null|string.Empty|valid wkt]) lead to

System.EntryPointNotFoundException: 'Unable to find an entry point named 'CSharp_OSGeofOGR_new_SpatialReference___' in DLL 'osr_wrap'.'

To Reproduce
Gdal3CoreApp.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MaxRev.Gdal.Core" Version="3.0.1.25" />
    <PackageReference Include="MaxRev.Gdal.WindowsRuntime.Minimal" Version="3.0.1.35" />
  </ItemGroup>

</Project>

Program.cs:

namespace Gdal3CoreApp
{
    class Program
    {
        static void Main(string[] args)
        {
            MaxRev.Gdal.Core.GdalBase.ConfigureAll();
            System.Console.WriteLine($"IsConfigured = {MaxRev.Gdal.Core.GdalBase.IsConfigured}");

            string wkt = null;
            using (var sr = new OSGeo.OGR.SpatialReference(wkt))
            {
                if (sr.ImportFromEPSG(4326) == 0)
                {
                    if (sr.ExportToWkt(out wkt, null) == 0)
                        System.Console.WriteLine(wkt);
                }
                else
                {
                    System.Console.WriteLine("Could not identify EPSG:4326");
                }
            }
        }
    }
}

Expected behavior
The OSGeo.OGR.SpatialReference class should not be present at all.
Using OSGeo.OSR.SpatialReference works fine.

Environment information:

• OS (version): Windows 10 (1909)
• Package version (core): 3.0.1.25
• Package version (runtime): 3.0.1.35

Additional context
I have not tested the linux runtime.

Native dependencies bugs

Problem

While using prebuilt gdal from gisinternals (and nuget packages by @szekerest), I've noticed some issues, which I've explained in details in gdal repo:

• Using wildcard breaks gdalbuildvrt osgeo/gdal - issue1749
• Bad support for cyrillic paths osgeo/gdal - issue 1245

These issues also appears in this library. Recently I've located a new problem, related to this nuget package: my antivirus deletes the package instantly because of libgeos_c.dll.

Solution

Not so long ago I've found some time to sort out how gdal builds and managed to find a solution for these issues.

First two I are fixed by changing gdal's nmake.opt. It requires a new dependency -- iconv (I've got it through vcpkg) and adding those paths to nmake.opt:

LIBICONV_INCLUDE = -IC:\vcpkg\installed\x64-windows\include
LIBICONV_LIBRARY = C:\vcpkg\installed\x64-windows\lib\libiconv.lib
LIBICONV_CFLAGS = -DICONV_CONST=const

I've also specified wsetargv.obj in nmake.opt, so it can be a part of solution too:

SETARGV = "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\lib\x64\wsetargv.obj"

I've tested the fixes above on latest gdal 3.1.2 with PROJ 7.1.0 (installed it's deps through vcpkg, built with cmake+vs using sqlite3 and libtiff) built on win-x64. Even though I've tested it on gdal apps, not the library, I think that might be also a solution for resolving the same issue in library.

Regarding the geos issue, I've tried to build geos with your win/getgeos.bat script, but antivirus still deleted the libgeos_c.dll. Building the newer commit (e.g. 3.8.1 release, not 3.8.0) fixes the issue. I suppose there were some kind of vulnerability in 3.8.0, idk.

I'm not sure how your binaries are built and don't want to break anything, so I've decided to open an issue instead of PR to convey this information to you.

Remove deprecated netcoreapp2.1 TMF

.NET Core 2.1 reached End of Support on August 21, 2021.
It will be removed from package targets.

More info: https://devblogs.microsoft.com/dotnet/net-core-2-1-will-reach-end-of-support-on-august-21-2021/

[BUG] Library fails on configuring when executed directly as DLL

Describe the bug
GdalConfigureAll fails when used in an AddIn of another Application in Windows OS.
I developed an AddIn to Microstation Connect Edition which is a CAD system.
This AddIn is a dynamic link library (DLL) with some tools for automatic drawing generation.
ConfigureAll fails here:
var executingDir = new FileInfo(Assembly.GetEntryAssembly().Location).Directory;

To Reproduce
Call library DLL directly from another application or DLL without .NET executable applications.

Expected behavior
Calling Assembly should not be used to define path to library contents.

Proposed solution
Allow the possibility to define executingDir from the Calling Assembly other than Entry Assembly.

Environment information:

• OS (version): Windows 10
• Package version (core): 3.2.0.300
• Package version (runtime): 3.2.0.300

First time for me to submit an issue. Hopefully it is correctly described. Thanks

[BUG] Fedora 35 / .NET 6 - Exception when executing GdalBase.ConfigureAll()

Describe the bug
On Fedora 35 when targeting a .NET 6 project an exception is thrown when GdalBase.ConfigureAll() is executed. I was following the steps in this article to read a FileGDB using the OpenFileGDB gdal driver.

https://www.spatial-focus.net/blog/working-with-file-geodatabase-in-csharp-1

To Reproduce

mkdir test
cd test
dotnet new console
dotnet add package MaxRev.Gdal.Core
dotnet add package MaxRev.Gdal.LinuxRuntime.Minimal
edit Program.cs:

using MaxRev.Gdal.Core;

try
{
    GdalBase.ConfigureAll();
}
catch(Exception ex)
{
    Console.WriteLine(ex);
}

dotnet build
dotnet run

Expected behavior
I expected initialization to not throw an exception.

Screenshots

System.TypeInitializationException: The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
 ---> System.DllNotFoundException: Unable to load shared library 'gdal_wrap' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libgdal_wrap: cannot open shared object file: No such file or directory
   at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate applicationDelegate, ExceptionDelegate arithmeticDelegate, ExceptionDelegate divideByZeroDelegate, ExceptionDelegate indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate, ExceptionDelegate invalidOperationDelegate, ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate overflowDelegate, ExceptionDelegate systemExceptionDelegate)
   at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
   --- End of inner exception stack trace ---
   at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
   at OSGeo.GDAL.GdalPINVOKE..cctor()
   --- End of inner exception stack trace ---
   at OSGeo.GDAL.GdalPINVOKE.AllRegister()
   at OSGeo.GDAL.Gdal.AllRegister()
   at MaxRev.Gdal.Core.GdalBase.ConfigureGdalDrivers()
   at MaxRev.Gdal.Core.GdalBase.ConfigureAll()
   at Program.<Main>$(String[] args) in /home/blahblahblah/src/test/Program.cs:line 6

Environment information:

• OS (version): Fedora Linux 35
• Package version (core): 3.3.3.110
• Package version (runtime): 3.3.3.110

Can't find proj.db folder from package in project output directory [BUG]

Describe the bug

I've created a little library (netcore3.0, x64) which uses MaxRev.Gdal.Core and MaxRev.Gdal.WindowsRuntime.Minimal packages. Then I've referenced this library from console application. Now when I'm trying to call GdalBase.ConfigureAll(); it throws exceptions:

The type initializer for 'OSGeo.OSR.OsrPINVOKE' threw an exception.
Can't find proj.db folder from package in project output directory
Error in MaxRev.Gdal.Core, Version=3.0.1.2, Culture=neutral, PublicKeyToken=null
System.TypeInitializationException: The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
 ---> System.DllNotFoundException: Unable to load DLL 'gdal_wrap' or one of its dependencies: Не найден указанный модуль. (0x8007007E)
   at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate applicationDelegate, ExceptionDelegate arithmeticDelegate, ExceptionDelegate divideByZeroDelegate, ExceptionDelegate indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate, ExceptionDelegate invalidOperationDelegate, ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate overflowDelegate, ExceptionDelegate systemExceptionDelegate)
   at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
   --- End of inner exception stack trace ---
   at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
   at OSGeo.GDAL.GdalPINVOKE..cctor()
   --- End of inner exception stack trace ---
   at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
   at OSGeo.GDAL.Gdal.SetConfigOption(String pszKey, String pszValue)
   at MaxRev.Gdal.Core.GdalBase.ConfigureAll()
The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
The type initializer for 'SWIGExceptionHelper' threw an exception.

To Reproduce

Empty console app on netcore3.0 has the same issue, can be tested here. Just reference mentioned nuget packages and call GdalBase.ConfigureAll();

Expected behavior

Gdal initilazed successfully.

Environment information:

• OS (version): Windows 10 (1903)
• Package version (core): 3.0.1.2
• Package version (runtime): 3.0.1.2

Core v3.2.0 - Can't find proj.db

Describe the bug

Datasets those use a proj.db database to create projection throw this error on MaxRev.Gdal.Core.3.2.0.[100 - 200].

Error Message:
   System.ApplicationException : PROJ: proj_create_from_database: Cannot find proj.db
  Stack Trace:
     at OSGeo.GDAL.Gdal.GDALInfo(Dataset hDataset, GDALInfoOptions infoOptions)

To Reproduce

GdalBase.ConfigureAll();
using var inputDataset = Gdal.Open(inputFilePath, Access.GA_ReadOnly);
var info = Gdal.GDALInfo(inputDataset, new GDALInfoOptions(null));

Expected behavior
GdalInfo should not throw System.ApplicationException

Already WIP

Is Gdal.VSIFReadL not supported?

Is your feature request related to a problem? Please describe.
<Can't read a file with the path /vsimem/Data/filename.mif as byte[].>

Describe the solution you'd like or your ideas here
< Add support for Gdal.VSIFReadL please >

Additional context
I use /vsimem/ file system to create Mapinfo files in-memory but I couldn't find a way to retrieve file without creating a local file.

var vsiFile = Gdal.VSIFOpenL(filePath, "r");

Gdal.VSIFSeekL(vsiFile, 0, 2);
var size = Gdal.VSIFTellL(vsiFile);
Gdal.VSIFSeekL(vsiFile, 0, 0);

var data = new byte[size];
// Gdal doesn't have VSIFReadL 😢 
// Gdal.VSIFReadL(data, size, 1, vsiFile);
return data;

<details>
  <summary>
![image](https://user-images.githubusercontent.com/74559101/142561681-04cdab11-f25e-43a5-bb3a-ce1070766778.png)
</summary>
  [link](to)
</details>

Can't start up on windows

I restore gdalcoretest.csproj then enter F5 start the project(not the docker-compose method).

the console output the error information:
Trying to configure all twice
Error in MaxRev.Gdal.Core, Version=3.0.1.25, Culture=neutral, PublicKeyToken=null
System.TypeInitializationException: The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'gdal_wrap' or one of its dependencies: 找不到指定的模块。 (Exception from HRESULT: 0x8007007E)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate applicationDelegate, ExceptionDelegate arithmeticDelegate, ExceptionDelegate divideByZeroDelegate, ExceptionDelegate indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate, ExceptionDelegate invalidOperationDelegate, ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate overflowDelegate, ExceptionDelegate systemExceptionDelegate)

but if i use the gdal.core and gdal.core.windowruntime package it work success.

'./Drawing1.dxf' not recognized as a supported file format.

Hello,Author:
I recently wanted to convert a DXF file to a GeoJSON file through your GDAL project,But when I use your Linux Mini Runtime, program prompts me for unsupported file types.
Tips are as follows:
ERROR 4: `./Drawing1.dxf' not recognized as a supported file format.
Is it because the Mini bag does not contain devICED with DXG?

[BUG] CoordinateTransformation swaps axis

Describe the bug
Using CoordinateTransformation swaps the resulting coordinate axis.

To Reproduce
Look at this simple transformation from Web Mercator to WGS84:
https://epsg.io/transform#s_srs=3857&t_srs=4326&x=1781111.8500000&y=6106854.8300000

This should result in the WGS84 (EPSG:4326) coordinate x=16, y=48.

using System;
using MaxRev.Gdal.Core;
using CoordinateTransformation = OSGeo.OSR.CoordinateTransformation;
using SpatialReference = OSGeo.OSR.SpatialReference;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            var x = 1781111.85;
            var y = 6106854.83;

            GdalBase.ConfigureAll();

            SpatialReference source = new SpatialReference(string.Empty);
            source.ImportFromEPSG(3857);
            SpatialReference destination = new SpatialReference(string.Empty);
            destination.ImportFromEPSG(4326);
            CoordinateTransformation transformer = new CoordinateTransformation(source, destination);

            double[] p = new double[3];

            transformer.TransformPoint(p, x, y, 0);

            Console.WriteLine($"Transformed {x}/{y} to {p[0]}/{p[1]}");

            // Output:
            // Transformed 1781111,85/6106854,83 to 47,9999999706363/15,999999975813965
        }
    }
}

Expected behavior
Passing X and Y coordinate should result in outputting X and Y coordinate and not swapping to Y and X.

Environment information:

• OS (version): Windows 10 (1909)
• Package version (core): 3.0.1.25
• Package version (runtime): 3.0.1.35

Additional context
This is a simple demonstration. It is easy to just use p[1] and p[0] instead. But I believe that this is also the root cause for the method Geometry.Transform(...) to swap the coordinates as well.

Add support for LIBKML

Hello, I am using this library in my .Net 5 project. It works perfectly but not when working with kml or kmz file.
Can you please support this feature in the next update or may give some guide for me to do it my self.
Thank you very much !

Error reading UTF-8 shapefile

can't read shapefile utf8

on linux centos 7

GML driver missing

Describe the bug
GML-Reader not work
System.ApplicationException: File C:\Temp\lakes.gml appears to be GML but the GML reader can't
be instantiated, likely because Xerces or Expat support was not configured in.
Missing dll- libs?

To Reproduce
Download GML-File Sample, http://qgis.org/downloads/data/qgis_sample_data.zip

        static void Main(string[] args)
        {
            MaxRev.Gdal.Core.GdalBase.ConfigureAll();
            System.Console.WriteLine($"IsConfigured = {MaxRev.Gdal.Core.GdalBase.IsConfigured}");

            var gmlDriver = Ogr.GetDriverByName("GML");
            var inDataSource = gmlDriver.Open("C:\\Temp\\lakes.gml", 0);
            var layer = inDataSource.GetLayerByIndex(0);
            System.Console.WriteLine($"Name - {layer.GetName()}");
        }

 <ItemGroup>
    <PackageReference Include="MaxRev.Gdal.Core" Version="3.0.1.25" />
    <PackageReference Include="MaxRev.Gdal.WindowsRuntime.Minimal" Version="3.0.1.35" />
  </ItemGroup>

Environment information:

• OS (version): Windows 10 (1909)
• Package version (core): 3.0.1.25
• Package version (runtime): 3.0.1.35

Additional context
I have not tested the linux runtime.
Sample-Code works with GDAL.Native 2.4.3 /.NETFramwork 4.7.2 https://www.nuget.org/packages/GDAL.Native/

Azure App Service (Web app) : Receiving runtime exception System.BadImageFormatException with MaxRev.Gdal.Core assembly

Hi Team,

We have a .NET 5.0 web api application that leverages the following Gdal Core packages:

<PackageReference Include="MaxRev.Gdal.Core" Version="3.2.0.320"/>
<PackageReference Include="MaxRev.Gdal.WindowsRuntime.Minimal" Version="3.2.0.300"/>

The application compiles and runs successfully in our local development environment (Visual Studio Code, Windows 10 Enterprise). However, when it's packaged and published to an Azure app service (web app) it yields the following runtime exception:

System.BadImageFormatException 1
Could not load file or assembly 'MaxRev.Gdal.Core, Version=3.2.0.319, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.

The said assembly, MaxRev.Gdal.WindowsRuntime.Minimal.dll & other runtime native assemblies were packaged and are present in the Azure app service backend (Kudu- wwwroot directory) once deployed. Also, Azure App service and solution project (.csproj) are both targeting to .net5.0.

Are we missing any build configuration while packaging which could be causing this issue in Azure on deployment?

MacOS runtime binaries

Hello. Just wondering if you're planning to create MacOS binaries package (aka MaxRev.Gdal.MacOSRuntime.Minimal). It seems like gdal supports MacOS (judjing by GitHub Actions in Gdal repo).

. net framework support

Will. Net framework be supported in the future？

GDAL_FILENAME_IS_UTF8 config option doesn't work for cyrillic symbols

No one's taken this issue on Gdal's repo for 2 years now, so I decided to test it on your version of gdal bindings.

Any geotiff on input will pass as input data. Slightly updated test code:

Click to expand

using System;
using System.IO;
using System.Linq;
using OSGeo.GDAL;
using MaxRev.Gdal.Core;

namespace TestGdalBuildVrt
{
    internal static class Program
    {
        private static void Main()
        {
            // Configure Gdal's paths before using it. Don't forget to change target system to x64
            GdalBase.ConfigureAll();

            // Check the default state of "GDAL_FILENAME_IS_UTF8" config option.
            string currentState = Gdal.GetConfigOption("GDAL_FILENAME_IS_UTF8", "YES");

            // Paths local variables
            string dataDirectoryPath = "D:/test";
            string inputEngDirectoryPath = Path.Combine(dataDirectoryPath, "input-eng");
            string inputCyrDirectoryPath = Path.Combine(dataDirectoryPath, "input-cyr");

            string englishInputFilePath = Path.Combine(inputEngDirectoryPath, "input data.tif");
            string cyrillicInputFilePath = Path.Combine(inputCyrDirectoryPath, "исходные данные.tif");
            string outputFilePath;

            #region Test 1

            // Test 1 - Passing. Paths doesn't contain any cyrillic symbols

            Console.WriteLine($"GDAL_FILENAME_IS_UTF8 is set to {currentState} by default");

            outputFilePath = Path.Combine(dataDirectoryPath, "test1.vrt");
            string testResult = RunTest(englishInputFilePath, inputEngDirectoryPath, outputFilePath) ? "passed" : "failed";
            Console.WriteLine($"Test 1 {testResult}");

            #endregion

            #region Test 2

            // Test 2 - Gdal.Open pass, BuildVrt fails (doesn't throw errors/exceptions, but no output file), writes "warning" in console

            Console.WriteLine($"GDAL_FILENAME_IS_UTF8 is set to {currentState} before the test");

            outputFilePath = Path.Combine(dataDirectoryPath, "test2.vrt");
            testResult = RunTest(cyrillicInputFilePath, inputCyrDirectoryPath, outputFilePath) ? "passed" : "failed";
            Console.WriteLine($"Test 2 {testResult}");

            #endregion

            // Change "GDAL_FILENAME_IS_UTF8" value to "NO" and check, if it was changed correctly.
            Gdal.SetConfigOption("GDAL_FILENAME_IS_UTF8", "NO");
            currentState = Gdal.GetConfigOption("GDAL_FILENAME_IS_UTF8", "YES");

            #region Test 3

            // Test 3 - Gdal.Open pass, BuildVrt fails (doesn't throw errors/exceptions, but no output file), writes "warning" in console

            Console.WriteLine($"GDAL_FILENAME_IS_UTF8 is set to {currentState} before the test");

            outputFilePath = Path.Combine(dataDirectoryPath, "test3.vrt");
            testResult = RunTest(englishInputFilePath, inputEngDirectoryPath, outputFilePath) ? "passed" : "failed";
            Console.WriteLine($"Test 3 {testResult}");

            #endregion

            #region Test 4

            // Test 4 - all fails, Gdal.Open throws exception, BuildVrt writes "" warning

            Console.WriteLine($"GDAL_FILENAME_IS_UTF8 is set to {currentState} before the test");

            outputFilePath = Path.Combine(dataDirectoryPath, "test4.vrt");
            testResult = RunTest(cyrillicInputFilePath, inputCyrDirectoryPath, outputFilePath) ? "passed" : "failed";
            Console.WriteLine($"Test 4 {testResult}");

            #endregion
        }

        private static bool GdalBuildVrt(string[] inputFilesPaths, string outputFilePath, string[] options, Gdal.GDALProgressFuncDelegate callback)
        {
            try
            {
                using Dataset result = Gdal.wrapper_GDALBuildVRT_names(outputFilePath, inputFilesPaths, new GDALBuildVRTOptions(options), callback, null);
            }
            catch (Exception exception)
            {
                Console.WriteLine(exception.Message);

                return false;
            }

            return true;
        }

        private static bool OpenDataset(string inputFilePath)
        {
            try
            {
                using Dataset inputDataset = Gdal.Open(inputFilePath, Access.GA_ReadOnly);
            }
            catch (Exception exception)
            {
                Console.WriteLine(exception.Message);

                return false;
            }

            return true;
        }

        private static bool RunTest(string inputFilePath, string inputDirectoryPath, string outputFilePath)
        {
            bool isTestSuccessful = OpenDataset(inputFilePath);

            string[] inputFilesPaths = new DirectoryInfo(inputDirectoryPath)
                                      .EnumerateFiles().Select(fileInfo => fileInfo.FullName).ToArray();
            if (!GdalBuildVrt(inputFilesPaths, outputFilePath, null, null))
                isTestSuccessful = false;

            // Check if .vrt file was created, because GdalBuildVrt doesn't throw exceptions in that case
            if (!new FileInfo(outputFilePath).Exists)
                isTestSuccessful = false;

            return isTestSuccessful;
        }
    }
}

Tested on Win10 x64, MaxRev.Gdal.Core ver. 3.2.0.250, MaxRev.Gdal.WindowsRuntime.Minimal ver. 3.2.0.250. Run on .NET ver. 5.0.2.

Interesting difference with original issue, that Test 4 now produces the almost correct .vrt file, yet the naming of file is corrupted and the path inside of file too. Also, on the last test, Gdal fails to open dataset, but GdalBuildVrt doesn't seem to throw any warnings or exceptions.

This also reminds me about #23. Did we end up using iconv in vcpkg, or no? Ah, don't mind, found it in GdalCore.opt.

[BUG] Unable to call SpatialReference.SetWellKnownGeogCS

(I suspect I'm missing a call that will include the DLLs that are necessary)
Describe the bug
Windows 10, VS 2019, Nuget packages.
After constructing a SpacialReference object I try to call SetWellKnownGeogCS, and receive the error: "System.EntryPointNotFoundException: 'Unable to find an entry point named '?' in DLL 'osr_wrap'.'

To Reproduce
In a console based application netcore v2.2:
GdalBase.ConfigureAll();
Gdal.AllRegister();

// Uncomment line below to get a different EntryPoint exception
//Console.WriteLine("Osr.Version: {0}.{1}", Osr.GetPROJVersionMajor(), Osr.GetPROJVersionMinor());

IntPtr intPtr = new IntPtr();
SpatialReference spatialReference = new SpatialReference(intPtr, true, null);
spatialReference.SetWellKnownGeogCS("WGS84");

Expected behavior
The above should run without error/exception.

Environment information:

• OS (version): Windows 10
• Package version (core): v3.0.0.4
• Package version (runtime): v3.0.0.4
• Visual Studio Version: 2019 (v16.1.0)

Additional context
I have not yet tested this on linux.

Errors when adding NetCDF

For a project I need to process GRIB and NetCDF files. I can read the GRIB files but for the NetCDF files I have to add a driver. But when I compile it for unix I get the following error after running make -f gdal-makefile:

./.libs/libproj.so: undefined reference to `curl_easy_getinfo'
./.libs/libproj.so: undefined reference to `curl_easy_setopt'
./.libs/libproj.so: undefined reference to `curl_easy_init'
./.libs/libproj.so: undefined reference to `curl_easy_perform'
./.libs/libproj.so: undefined reference to `curl_easy_cleanup'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:1394: proj] Error 1
make[4]: Leaving directory '/root/gdal.netcore/build-unix/proj-source/src'
make[3]: *** [Makefile:884: all] Error 2
make[3]: Leaving directory '/root/gdal.netcore/build-unix/proj-source/src'
make[2]: *** [Makefile:450: all-recursive] Error 1
make[2]: Leaving directory '/root/gdal.netcore/build-unix/proj-source'
make[1]: *** [gdal-makefile:172: build_proj] Error 2
make[1]: Leaving directory '/root/gdal.netcore/unix'
make: *** [gdal-makefile:42: proj] Error `2`

I've installed CentOS7 on WSDL2 (from here) and after that I've followed the instructions which are mentioned here.

It might be caused by permission issues because at the beginning I get the following errors:

./configure: line 18494: /root/gdal.netcore/unix/../build-unix/vcpkg/installed/x64-linux-dynamic/share/curl/curl-config: Permission denied
./configure: line 18495: /root/gdal.netcore/unix/../build-unix/vcpkg/installed/x64-linux-dynamic/share/curl/curl-config: Permission denied
        found libcurl version
checking for curl_global_init in -lcurl... ./configure: line 18506: /root/gdal.netcore/unix/../build-unix/vcpkg/installed/x64-linux-dynamic/share/curl/curl-config: Permission denied
yes
./configure: line 18550: /root/gdal.netcore/unix/../build-unix/vcpkg/installed/x64-linux-dynamic/share/curl/curl-config: Permission denied
./configure: line 18551: /root/gdal.netcore/unix/../build-unix/vcpkg/installed/x64-linux-dynamic/share/curl/curl-config: Permission denied

I'm logged in as the root user and I cloned the source in the /root folder.

Besides that, I had to manually install patchelf by using yum -y install https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/p/patchelf-0.12-1.el7.x86_64.rpm

Can you help me getting the compilation to work for me and possibly give me some directions to add the NetCDF driver?

[BUG] Published apps with multiple gdal initilization throws exceptions

Describe the bug
.NET Core 3.0 applications with multiple gdal initializations, built with dotnet publish, throws exceptions.

To Reproduce
Create a small console application, which Main() method has the following code:

Console.WriteLine("Gdal configure start.");
GdalBase.ConfigureAll();
Console.WriteLine("Gdal configure 1 ended.");
GdalBase.ConfigureAll();
Console.WriteLine("Gdal configure 2 ended.");

It'll run without any problems as usual Debug/Release build. But if you'll try to dotnet publish "NewGdalTest.csproj" -c Release -r win-x64 -o Publish/NewGdalTest/1 /p:PublishSingleFile=true /p:PublishTrimmed=true --self-contained this project and run it, you'll see this output:

Gdal configure start.
Gdal configure 1 ended.
Error in MaxRev.Gdal.Core, Version=3.0.1.2, Culture=neutral, PublicKeyToken=null
System.UnauthorizedAccessException: Access to the path 'C:\Users\gigas\AppData\Local\Temp\.net\NewGdalTest\uirzks2h.nlv\gdalplugins\gdal_HDF4.dll' is denied.
   at System.IO.FileSystem.DeleteFile(String fullPath)
   at System.IO.File.Delete(String path)
   at MaxRev.Gdal.Core.GdalBase.ConfigureAll()
Unhandled exception. System.UnauthorizedAccessException: Access to the path 'C:\Users\gigas\AppData\Local\Temp\.net\NewGdalTest\uirzks2h.nlv\gdalplugins\gdal_HDF4.dll' is denied.
   at MaxRev.Gdal.Core.GdalBase.ConfigureAll()
   at NewGdalTest.Program.Main(String[] args)

Expected behavior
Don't throw exceptions.

Environment information:

• OS (version): Windows 10 (1903)
• Package version (core): 3.0.1.2
• Package version (runtime): 3.0.1.25

Additional context
I've figured out how to fix this issue and will create pull request with my minor improvements soon.

Convert WKT to NetTopologySuite.Geometries.Geometry

var geometryWKT = "MULTISURFACE (CURVEPOLYGON (COMPOUNDCURVE ... "; // truncated for convenience

Please help me!

GetProjection returns empty string

Hi,

I am loading a raster image (jpg/jgw/prj) and when I call GetProjection() or GetProjectionRef() on the Dataset it comes back with an empty string. I would have expected something like (in this case) "PROJCS["UTM_Zone_10_Northern_Hemisphere",GEOGCS["GCS_WGS_1984",DATUM["D_WGS84",SPHEROID["WGS84"...".

Is there some configuration that I am missing or are the functions stubbed out and do nothing? I have tried on Windows and in a Linux docker container.

The JPEG driver info comes back with only the jpg and jgw in the files list. Should it be also showing the prj?

Cheers,
Clint

proj.db location from nuget

Hi,

This is in case it helps anyone else, though I do have a question further below.

When running the 3.0.1.25 version of MaxRev.Gdal.Core I notice that when I need to load something I was getting a error:

System.ApplicationException: 'PROJ: proj_create_from_database: Cannot find proj.db'

Looking into the debug folder, I notice that
{project}\bin\Debug\netcoreapp3.0 contains proj.db but
{project>\bin\Debug\netcoreapp3.0\maxrev.gdal.core.libshared is empty.

Copying proj.db into {project>\bin\Debug\netcoreapp3.0\maxrev.gdal.core.libshared fixes the issue.

I was not successful in changing environment variables to locate this file for some reason:
SystemEnvironment.AddEnvironmentVariable("PROJ_LIB", @"C:\tmp");
for example, does not work.

For the new version of MaxRev.Gdal.Core, 3.1.0.100 released on nuget, it is for .NetStandard 2.1, not 2.0. Can anyone comment on why this is the case? I need to stick with 2.0 for other reasons.

GDAL 3.3.3 support

Hi, @MaxRev-Dev ! Thank you for your awesome work for supporting GDAL/C# :)

When is the new version release expected?

PROJ projection does not match with epsg.io/transform

Describe the bug
I'm getting unexpected results when projecting from British National Grid to Lambert Equal Area (on ETRS1989 datum).

To Reproduce
Explore the values asserted in this code

using MaxRev.Gdal.Core;
using OSGeo.OSR;
using System;
using System.Threading.Tasks;
using Xunit;

namespace DHI.WaterData.Projections.Provider.Test.WKTS
{
    public class MatchWKTStringsTest
    {
        [Fact]
        public async Task TransformPointIsOk()
        {
            var x = 826158.063;
            var y = 2405844.125;

            var sourceWkt =
                "PROJCS[\"OSGB 1936 / British National Grid\",GEOGCS[\"OSGB 1936\",DATUM[\"OSGB_1936\",SPHEROID[\"Airy 1830\",6377563.396,299.3249646,AUTHORITY[\"EPSG\",\"7001\"]],TOWGS84[446.448,-125.157,542.06,0.15,0.247,0.842,-20.489],AUTHORITY[\"EPSG\",\"6277\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4277\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",49],PARAMETER[\"central_meridian\",-2],PARAMETER[\"scale_factor\",0.9996012717],PARAMETER[\"false_easting\",400000],PARAMETER[\"false_northing\",-100000],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH],AUTHORITY[\"EPSG\",\"27700\"]]";
            var targetWkt =
                "PROJCS[\"ETRS89 / LAEA Europe\",GEOGCS[\"ETRS89\",DATUM[\"European_Terrestrial_Reference_System_1989\",SPHEROID[\"GRS 1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6258\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4258\"]],PROJECTION[\"Lambert_Azimuthal_Equal_Area\"],PARAMETER[\"latitude_of_center\",52],PARAMETER[\"longitude_of_center\",10],PARAMETER[\"false_easting\",4321000],PARAMETER[\"false_northing\",3210000],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AUTHORITY[\"EPSG\",\"3035\"]]";
            
            Proj6.Configure();
            
            var sourceSr = new SpatialReference(string.Empty);
            sourceSr.ImportFromWkt(ref sourceWkt);
            sourceSr.SetAxisMappingStrategy(AxisMappingStrategy.OAMS_TRADITIONAL_GIS_ORDER);
            
            var targetSr = new SpatialReference(string.Empty);
            targetSr.ImportFromWkt(ref targetWkt);
            targetSr.SetAxisMappingStrategy(AxisMappingStrategy.OAMS_TRADITIONAL_GIS_ORDER);
            
            var transformation = new CoordinateTransformation(sourceSr, targetSr);
            if (transformation == null)
                throw new ArgumentException("Invalid projection WKT");

            var projected = new double[3];
            transformation.TransformPoint(projected, x, y, 0.0);
            var px = projected[0];
            var py = projected[1];

            var ex = 4316131D;
            var ey = 5330926D;
            Assert.Equal(ex, px, 0);
            Assert.Equal(ey, py, 0);
        }
    }
}

Expected behavior

coord	British n. grid	expected projected	actual projected
x	826158.063	4316131.0	4316331.549
y	2405844.125	5330926.0	5331101.982

The expected projected coordinates come from:
https://epsg.io/transform#s_srs=27700&t_srs=3035&x=826158.0630000&y=2405844.1250000
The expected projected coordinates were also retuned from another, proprietary. transformation library I used.

Environment information:

• OS (version): Windows 10 and Windows 11.
• Package version (core): 3.2.0.320
• Package version (runtime): 3.2.0.250

Additional context
This may be ultimately a PROJ issue, but I'm using it through MaxRev.gdal so this seems to be the right place to start.
I've been researching about PROJ (and the changes in version 4, 6, and onwards), but nothing really explained this discrepancy.
I suspect the datum transformation is not applied because when I changed the TOWGS parameters of the British National Grid WKT string to all zeros, I got exactly the same results. Also the SetAxisMappingStrategy calls have no impact in this case.
It may also be that we are missing the transformation grids needed for this transformation. But how do we install grid shift files with MaxRev.gdal?

[GDAL] Can't compile 3.1 release version on Windows

Unable to build the latest commits in branch @gdal/release/3.1

What I've tried:

• OSGeo/gdal@a3f8b8b
• OSGeo/gdal@fb88e3c

Environment information:

• OS: Windows 10

To reproduce: (cmd)

• Clone this repo
• cd win
• ALL_INSTALL
• gdal-fetch
• gdal-build

Output:

   Creating library gdalmdiminfo.lib and object gdalmdiminfo.exp
gdalmdiminfo_bin.obj : error LNK2019: unresolved external symbol GDALMultiDimInfoOptionsNew referenced in function wmain
gdalmdiminfo_bin.obj : error LNK2019: unresolved external symbol GDALMultiDimInfoOptionsFree referenced in function wmain
gdalmdiminfo_bin.obj : error LNK2019: unresolved external symbol GDALMultiDimInfo referenced in function wmain
gdalmdiminfo.exe : fatal error LNK1120: 3 unresolved externals

Additional context:
I don't know exactly, maybe linker can't resolve some symbols in "gdal_utils.h"

@rouault

Possible RegenerateOverviews parameter issue?

I am wondering what is the correct usage of Gdal.RegenerateViews(). It has a parameter that takes SWIGTYPE_p_p_GDALRasterBandShadow and I feel like that should have been just a Band type. Is this a bug or should I be doing something else?

The "Band" that I want to pass in comes from DataSet.GetRasterBand(...)

Cheers,
Clint

[BUG] cannot compile the source code.

Hello, I want add the postsql driver to the project.
When I edit the GdalCore.opt and configuregdal.sh files,and excute the 3.2 step "./configuregdal.sh"
an error occurred!

     extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);

using ICONV_CPP_CONST=""
checking for PROJ >= 6 library... checking for proj_create_from_wkt in -lproj... yes
configure: error: proj.h not found

how can i do ?

In addition，I execute the command "./configure --prefix=$gc_root/gdal-build CFLAGS="-fPIC"" directly under the gdal folder, instead your 3 Step ，then excute "make RID=linux-x64",I got the runtimes successfully.
But how i get the win-64 runtimes?

I don’t know if there is any problem in the third step of replacing you, can you provide more detailed compilation process documentation, thank you！

How to add postgis driver？

I have successfully compiled the project on windows OS.
Then I want to add the postgis driver,how should i start？
Can you help me？

Cannot run as Azure Function

I've done extensive attemps (also compiling my own nugets) but no matter what I do I seem to get the following error when attempting to run it as Azure Function.

The error is similar on both Windows and Linux consumption plans. Windows:

System.TypeInitializationException: The type initializer for 'GeoDk.Central.IO.GIS.DataSource' threw an exception. The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception. The type initializer for 'SWIGExceptionHelper' threw an exception. Unable to load DLL 'gdal_wrap' or one of its dependencies: The specified module could not be found. (0x8007007E)

Linux:
System.TypeInitializationException: The type initializer for 'GeoDk.Central.IO.GIS.DataSource' threw an exception. The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception. The type initializer for 'SWIGExceptionHelper' threw an exception. Unable to load shared library 'gdal_wrap' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libgdal_wrap: cannot open shared object file: No such file or directory

Obviously it has problems finding the native dependencies, or a transitive dependency of them. Any ideas what might be causing this?

more vector drivers request!

More and more the database is used to spatial database stored ,eg PostGis,Mysql,Mongodb etc..

The Gdal.org have support about 90+ ogr drivers [https://gdal.org/drivers/vector/index.html]

But this package only support about 75+ ogr drivers. More seriously，the usually database types doesn't be supported.

do you have plan to support postgis or other database types driver?

[BUG] System.TypeInitializationException : The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception. While unit testing with xUnit

Describe the bug
I have problems with initializiting Gdal while using xUnit. GdalBase.ConfigureAll(); was called.

  Message: 
    System.TypeInitializationException : The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.
    ---- System.TypeInitializationException : The type initializer for 'SWIGExceptionHelper' threw an exception.
    -------- System.DllNotFoundException : Unable to load DLL 'ogr_wrap' or one of its dependencies: The specified module could not be found. (0x8007007E)
  Stack Trace: 
    OgrPINVOKE.GetDriverByName(String jarg1)
    Ogr.GetDriverByName(String name)

Environment information:

• OS (version): [e.g. Windows 10 (2004)]
• Package version: 3.0.1.2 (same with he 3.1.100)

Does it support arm architecture machines

Hello, I'm using an arm based computer now. Do you support it

[BUG] Azure functions - GDAL Can't find proj.db on configuring environment

Describe the bug
Can't find proj.db. exception thrown when calling GdalBase.ConfigureAll(). The proj.db file is present in the runtimes, but the method expects it to be under bin\runtimes.

To Reproduce
Create a sample Function App v3 (Microsoft.NET.Sdk.Functions 3.0.11), install the core MaxRev.Gdal.Core and runtime MaxRev.Gdal.WindowsRuntime.Minimal packages with a HttpTrigger function. Call GdalBase.ConfigureAll(); in the function, call the function.

Expected behavior
Exception not thrown, GdalBase is configured.

Screenshots

Screenshot:

Environment information:

• OS (version): Windows 10 Pro (20H2)
• Package version (core): 3.2.0.310
• Package version (runtime): 3.2.0.300

Additional context
I've used these configuration calls before and they are working:

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

Here's a zipped solution with the code to reproduce. Just run in debug and hit the api/GetBasicDxfInfo endpoint.
ImportTest.zip

Geometry.CreateFromWkb fails when WKB contains coordinate system description

Describe the bug
The function Geometry.CreateFromWkb throws an exception if the WKB contains a coordinate system description.

To Reproduce

1. Create a WKB with a coordinate system.
2. Pass an array of bytes to the Geometry.CreateFromWkb.

Expected behavior
Geometry with a coordinate system is created.

Screenshots

Environment information:

• OS (version): Windows 10
• Package version (core): 3.2.0.320
• Package version (runtime): 3.2.0.300

Additional context

Can't build GDAL 3.2.0 with external libtiff on linux

Describe the bug
GDAL of version 3.2.0 fails to build with external libtiff on linux.
Configure requires a higher version of libtiff than 4.0.
But 4.1.0 is already installed and windows part links successfully.

To Reproduce
Please, checkout the branch repro-v3.2.0-libtiff
Go to directory: cd unix

• Install VCPKG packages: make -f vcpkg-makefile install_requirements
  • Compile PROJ and GEOS, if these libraries were not built before:
    make -f gdal-makefile build_proj build_geos
• Build GDAL make -f gdal-makefile build_gdal

Expected behavior
GDAL configure fails with this output:

configure: Bash completions not requested
checking for libtiff... using libtiff from /gdal-netcore/unix/build-unix/vcpkg/installed/x64-linux/lib.
checking for TIFFScanlineSize64 in -ltiff... no
configure: error: libtiff >= 4.0 is required.
make[1]: *** [gdal-makefile:73: configure_gdal] Error 1

VCPKG (build-unix/vcpkg - vcpkg --list)

szip:x64-linux-dynamic                             2.1.1-6          Szip compression software, providing lossless co...
tiff:x64-linux                                     4.1.0            A library that supports the manipulation of TIFF...
xerces-c:x64-linux                                 3.2.3-1          Xerces-C++ is a XML parser, for parsing, generat...

Environment information:

• Package version (core): 3.2.0
• Package version (runtime): 3.2.0

@rouault we'd be very grateful for your assist. There was a related issue in OSGeo/gdal#3135.
Currently we use an internal libtiff in 3.2.0.100, but some tests on linux are failing in this library Gigas002/GTiff2Tiles - Bump gdal packages and Gigas002/GTiff2Tiles - CI.
This issue was related to bindings, but anyway we have a problem with configure.

[BUG] gdal_wrap dll Error on Windows 10

When executing Gdal.open(path, Access.GA_ReadOnly), I get the the following error:
DllNotFoundException: Unable to load DLL 'gdal_wrap' or one of its dependencies: The specified module could not be found.

I have tried: repairing Visual C++ redis, using a constant in place of Access.GA_ReadOnly, changing to an older version of the package

I'm not totally sure what could be causing this issue. I'm using a Gdal install from QGIS/OSGeo4W, so I'm on Gdal 3.1.4.

Environment information:

• OS: Windows 10 (19042)
• Package version: 3.2.0.320

Gdal.wrapper_GDALWarpDestName has an overhead of 450ms on linux and 0ms on windows

Describe the bug
I'm running the same .net core code in windows 10 environment and in a linux container. With this docker file. Everything seems a bit faster on linux than on windows by few milliseconds but wrapper_GDALWarpDestName is very slow, whatever warp options I'm using: no option at all, output format (no driver specified, VRT or nwt_grd), ts, te, aggregation method...

To Reproduce
Run this code

namespace GdalCoreTest
{
 class Program
 {
  static void Main(string[] args)
  {
	GdalBase.ConfigureAll();
	Console.WriteLine("GDAL configured");
	Console.WriteLine(string.Join('\n',
		"GDAL Version: " + Gdal.VersionInfo("RELEASE_NAME"),
		"GDAL INFO: " + Gdal.VersionInfo("")));
	WarpFile();
	WarpFile();
	WarpFile();
  }

  public static void WarpFile()
  {
	Stopwatch sw = new Stopwatch();

	int sizeX = 1024, sizeY = 1024;
	var driver = Gdal.GetDriverByName("MEM");
	string path = $"/vsimem/test.mem";
	string vrtFilePath = null;
	using(Dataset ds = driver.Create(path, sizeX, sizeY, 1, DataType.GDT_UInt32, new string[0]))
	{
	  try
	  {
	  //**************
	  //create a grid
		ds.SetGeoTransform(new double[]{0, 30, 0, 0, 0, -30});

		var ttt = new SpatialReference(null);
		ttt.ImportFromProj4("+proj=longlat +datum=WGS84");
		ttt.ExportToWkt(out string latLongWkt, new string[0]);
		ds.SetProjection(latLongWkt);

		//write data in the buffer
		int[] buffer = new int[sizeX * sizeY];
		for (int x = 0; x < sizeX; x++)
		{
		  for (int y = 0; y < sizeY; y++)
		  {
			buffer[y * sizeX + x] = x + y;
		  }
		}

		ds.GetRasterBand(1).WriteRaster(0, 0, sizeX, sizeY, buffer, sizeX, sizeY, 0, 0);


		//**************
		//Prepare for warping
		IntPtr[] ptr = {Dataset.getCPtr(ds).Handle};
		GCHandle gcHandle = GCHandle.Alloc(ptr, GCHandleType.Pinned);
		var dss = new SWIGTYPE_p_p_GDALDatasetShadow(gcHandle.AddrOfPinnedObject(), false, null);
		vrtFilePath = $"/vsimem/tile.vrt";

	  //Warp
		sw.Start();
		using (Dataset dst = Gdal.wrapper_GDALWarpDestName(vrtFilePath, 1, dss, new GDALWarpAppOptions(new[]{"-of", "VRT" }), null,null))
		{
		  sw.Stop();
		}
	  }
	  finally
	  {
		Gdal.Unlink(path);
		Gdal.Unlink(vrtFilePath);
	  }
	}
    Console.Out.WriteLine($"Warp duration = {sw.ElapsedTicks} ticks ({sw.ElapsedMilliseconds} ms).");
  }
 }
}

Expected behavior
This is the output I'm getting on windows:

GDAL configured
GDAL Version: 3.0.1
GDAL INFO: GDAL 3.0.1, released 2019/06/28
Warp duration = 221267 ticks (22 ms).
Warp duration = 133395 ticks (13 ms).
Warp duration = 155402 ticks (15 ms).

This is the output I'm getting on docker/linux:

GDAL configured
GDAL Version: 3.0.1
GDAL INFO: GDAL 3.0.1, released 2019/06/28
Warp duration = 395911725 ticks (395 ms).
Warp duration = 368923383 ticks (368 ms).
Warp duration = 373055090 ticks (373 ms).

Environment information:

• OS (version): Windows 10 (1903)
• Docker:
  Server: Docker Engine - Community
  Engine:
  Version: 19.03.2
  API version: 1.40 (minimum version 1.12)
  Go version: go1.12.8
  Git commit: 6a30dfc
  Built: Thu Aug 29 05:32:21 2019
  OS/Arch: linux/amd64
  Experimental: false
• Linux in docker file: debian 9 (mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim)
• Package version (core): [e.g. 3.0.1.25]
• Package version (runtime windows): [e.g. 3.0.1.25]
• Package version (runtime linux): [e.g. 3.0.1.2]

Notes
Thank you very much for this package, everything else I tried had the same behavior on linux and windows !

mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809 Issue calling registerAll()

I am facing exception issue when i call registerall() method
System.TypeInitializationException: The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.

Below is the docker file, i am build image for server2019

---

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-nanoserver-1809 AS build
WORKDIR /src
COPY ["Sample.API/Sample.API.csproj", "Sample.API/"]
COPY [".nuget","c:/.nuget"]
RUN dotnet restore "Sample.API/Sample.API.csproj" -s "https://api.nuget.org/v3/index.json" -s "c:/.nuget/packages"
COPY . .
WORKDIR "/src/Sample.API"
RUN dotnet build "Sample.API.csproj" -c Release -r win-x64 -o /app/build

FROM build AS publish
RUN dotnet publish "Sample.API.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Sample.API.dll"]

---

here .nuget folder is local nuget source reference which has nuget for a project where
MaxRev.Gdal.Core" Version="3.1.0.100"
MaxRev.Gdal.WindowsRuntime.Minimal" Version="3.1.0.100"
are installed.

I even installed above two lib in API project to make sure the proj.dll is copied, which it actullay did, but still i am getting below exception
System.TypeInitializationException: The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.
---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
---> System.DllNotFoundException: Unable to load DLL 'ogr_wrap' or one of its dependencies: The specified module could not be found. (0x8007007E)
at OSGeo.OGR.OgrPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Ogr(ExceptionDelegate applicationDelegate, ExceptionDelegate arithmeticDelegate, ExceptionDelegate divideByZeroDelegate, ExceptionDelegate indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate, ExceptionDelegate invalidOperationDelegate, ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.OGR.OgrPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.OGR.OgrPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.OGR.OgrPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.OGR.OgrPINVOKE.RegisterAll()
at OSGeo.OGR.Ogr.RegisterAll()

• i can see gdal_wrap and proj.dll both are there in exe folder

have you tried hosting in nanoserver before?
mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809

Originally posted by @santoshkaranam in #25 (comment)

Windows - gcc and c++ compilers not found

I want to add FILEGDBAPI, so I follow win build steps. but when nmake -f makefile.vc - builds default targets get error,

git clone https://github.com/libgeos/geos.git E:\gdal.netcore\win/../build-win/geos-source
Cloning into 'E:\gdal.netcore\win/../build-win/geos-source'...
remote: Enumerating objects: 462, done.
remote: Counting objects: 100% (462/462), done.
remote: Compressing objects: 100% (287/287), done.
remote: Total 61613 (delta 244), reused 254 (delta 166), pack-reused 61151
Receiving objects: 100% (61613/61613), 25.93 MiB | 3.32 MiB/s, done.
Resolving deltas: 100% (46465/46465), done.
        cd E:\gdal.netcore\win/../build-win/geos-source
        git fetch
        git checkout -fq 3.9.0
        git reset --hard
HEAD is now at c8e3fe8a Commit 3.9.0 and tag
        git clean -fqdx
        cd E:\gdal.netcore\win
-- GEOS: Build type: Release
-- GEOS: Run-time output: E:/gdal.netcore/build-win/geos-source/build/bin
-- GEOS: Archives output: E:/gdal.netcore/build-win/geos-source/build/lib
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:124 (project):
  The CMAKE_C_COMPILER:

    gcc

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.


CMake Error at CMakeLists.txt:124 (project):
  The CMAKE_CXX_COMPILER:

    g++

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.

I guess vcpkg environment variable is not set correctly? But I'm not familiar with C++ nmake, so can we make docker build image , something like https://github.com/OSGeo/gdal/blob/master/gdal/docker/alpine-normal/Dockerfile , this can be helpful for who want to build self.

[BUG] Inconsistent gdal dll version name in MaxRev.Gdal.Core.WindowsRuntime 3.2.0.300

Hi,
first of all great job. To have all the native dependencies for GDAL with C# bindigs in a nuget package is very very usefull.
I testet it and it works!

But one little thing:
I need support for ECW and JPG2000 on Windows. I dont want to compile it by myself and downloaded binaries from gisinternals.com.
Then i copied

gdalplugins/gdal_ECW_JP2ECW.dll
libecwj2.dll

to the native/win-x64 directory in my solution. The Plugin is compiled vor GDAL 3.2.0 (same as your dlls)
But it did not work, becuase gdal_ECW_JP2ECW.dll depends on gdal302.dll. Your dlls name is gdal301.dll ;)

I also tried to use the gdal_ECW_JP2ECW.dll for GDAL 3.1.0. In this case Gdal.RegisterAll() complains, that the Version gdal_ECW_JP2ECW.dll is compiled for a wrong version of GDAL (witch is the correct answer anyway).

In your gdal_nmake.opt you have defined VERSION = 301.
Can you please change this to the right Version (302), next time you publish the package to nuget?

Thanks!

Unable to load shared library 'gdal_wrap' or one of its dependencies

I run MaxRev.Gdal.Core + MaxRev.Gdal.LinuxRuntime.Minimal on CentOS 7 with simple code:

return new string[] {
   "GDAL Version: " + Gdal.VersionInfo("RELEASE_NAME"),
   "GDAL INFO: " + Gdal.VersionInfo("")
};

This code throws an error:

An unhandled exception has occurred while executing the request. System.TypeInitializationException: The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception. ---> System.DllNotFoundException: Unable to load shared library 'gdal_wrap' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libgdal_wrap: cannot open shared object file: No such file or directory

The same code work smoothly on Windows

UTF-8 non-ascii string values cause string to be truncated

Describe the bug

UTF-8 non-ascii string values cause string to be truncated. In reproduction case it's a shapefile that has a value Befæstet which become Befæste. Likely string char length is assumed to be byte length somewhere.

To Reproduce

Clone https://github.com/bjornharrtell/gdal.netcore.utf8issuerepro then do a dotnet build then a dotnet run.

Expected behavior

Should not corrupt strings.

Environment information:

• OS (version): Ubuntu 20.04
• Package version (core): [e.g. 3.0.1.25]
• Package version (runtime): [e.g. 3.0.1.2]

Additional context

I've also reproduced this with other formats (fx. GML) and my own builds of gdal.netcore and when running on Debian 10, so this seems to sit down deep somewhere.

Native binaries collision with libgdiplus

I got the following error when i try to use the library. I have zlib 1.2.11 (latest version) and its dev version installed but i am still getting the same error.

I get success if i use Gdal.Core package and its runtimes. but their version are old.

The detail i got from LD_DEBUG below :

23172: checking for version GLIBC_2.4' in file /lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgif.so.7 [0] 23172: checking for version GLIBC_2.2.5' in file /lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgif.so.7 [0]
23172: checking for version GLIBC_2.2.5' in file /lib/x86_64-linux-gnu/libm.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libpng16.so.16 [0] 23172: checking for version ZLIB_1.2.9' in file /home/tyaleze/Desktop/code/server/teoframework/TeoGIS.Framework/TeoFramework/bin/Debug/netcoreapp3.1/runtimes/linux-x64/native/libz.so.1 [0] required by file /usr/lib/x86_64-linux-gnu/libpng16.so.16 [0]
23172: /home/tyaleze/Desktop/code/server/teoframework/TeoGIS.Framework/TeoFramework/bin/Debug/netcoreapp3.1/runtimes/linux-x64/native/libz.so.1: error: version lookup error: version `ZLIB_1.2.9' not found (required by /usr/lib/x86_64-linux-gnu/libpng16.so.16) (fatal)
23172:
23172: file=/usr/lib/x86_64-linux-gnu/liblibgdiplus.so [0]; destroying link map
23172:
23172: file=/usr/lib/x86_64-linux-gnu/libcairo.so.2 [0]; destroying link map
23172:
23172: file=/usr/lib/x86_64-linux-gnu/libtiff.so.5 [0]; destroying link map

Environment information:

• OS Ubuntu 18.04 TLS
• Package 3.0.1.100
  Dotnet Core 3.1

mcr.microsoft.com/dotnet/core/sdk:3.1.404-nanoserver-1809 Issue calling registerAll()

I'm facing issues with the allregister() method when running in a docker container. I'm not facing any issues in my local and remote VM.

System.TypeInitializationException: The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.

Below is my docker file
FROM mcr.microsoft.com/dotnet/core/sdk:3.1.404-nanoserver-1809
WORKDIR /app
EXPOSE 80
EXPOSE 443

RUN dotnet tool install --global PowerShell --version 7.0.3
USER ContainerAdministrator
ADD API/gdal-frame-dlls C:/Windows/System32/
COPY ["security.dll", "C:/Windows/System32"]
COPY ["SampleAPI/Sampleoutput", "."]
COPY ["generate-database-connection.ps1", "."]

USER ContainerAdministrator
ENTRYPOINT ["pwsh", "-command", "Copy-Item 'C:/appsettings/appsettings.json' -Destination 'C:/app/appsettings.json';", "dotnet API.dll;"]

I'm referring to below Nuget sources
MaxRev.Gdal.Core" Version="3.2.0.320"
MaxRev.Gdal.WindowsRuntime.Minimal" Version="3.2.0.310"
are installed.

Couldn't find 'MaxRev.Gdal.Core.Windows' assembly in loaded assemblies of current domain. Is it installed?
Failed to configure Gdal for windows runtime
[12:06:03 ERR] Exception in UploadShapeFile Controller Method:The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2]
Executed action API.Controllers.PolygonController.UploadShapeFile (API) in 105.3672ms
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
Executed endpoint 'API.Controllers.PolygonController.UploadShapeFile (API)'
fail: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[1]
An unhandled exception has occurred while executing the request.
System.TypeInitializationException: The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
---> System.DllNotFoundException: Unable to load DLL 'gdal_wrap' or one of its dependencies: The specified module could not be found. (0x8007007E)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate applicationDelegate, ExceptionDelegate arithmeticDelegate, ExceptionDelegate divideByZeroDelegate, ExceptionDelegate indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate, ExceptionDelegate invalidOperationDelegate, ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.GDALDestroyDriverManager()
at OSGeo.GDAL.Gdal.GDALDestroyDriverManager()

Better way to write native files

Hello.
I'm using this package along with others projects on Linux. After building the project with MaxRev.Gdal.LinuxRuntime.Minimal package, it writes Linux dependencies in "runtimes/linux-x64/native" directory.
However, another library writes its dependencies the same way and Gdal's dependencies overrides some files there. Because of that, NetVips in my application doesn't work, throwing the exception:

Message [string]:"Unable to load shared library 'libvips.so.42' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibvips.so.42: cannot open shared object file: No such file or directory"

Probably the native binaries should be written the other way to avoid these conflicts?

[BUG] Can't run GdalBase.ConfigureAll() from a Windows app installed in Program Files without admin rights

Describe the bug
When running GdalBase.ConfigureAll() from a .NET application installed in the Windows 'Program Files' directory the application throws an UnauthorizedAccessException due to the lack of rights when running as a normal user.
ConfigureAll() always tries to create a directory in the executing assembly directory, even if it already exists.

To Reproduce
Create a simple Windows console application with only 'GdalBase.ConfigureAll()'. Build the application and disable write access on the application folder for the current user. Then run without elevated access to reproduce.

Expected behavior
GdalBase.ConfigureAll() should check if the directories and files already exist. If so then it should skip creation.

Environment information:

• OS (version): Windows 10 Enterprise(21H1)
• Package version (core): 3.2.0.320
• Package version (runtime): 3.2.0.310

Update to .NET6.0

Set all projects and CI workflow to brand new .NET6.0 and C#10

[BUG] make pack fails to include native deps in linux build

I'm building on Debian 10 and all goes well except that the resulting MaxRev.Gdal.LinuxRuntime.Minimal only contains proj.db in /runtimes/linux-x64/native/maxrev.gdal.core.libshared/. The make step produces native deps in gdal.netcore/runtimes/linux-x64native but seems they are not picked up and I'm failing to understand why.