C# Bindings Conda Package
The GDAL C# Bindings Conda Package is a community supported project.
Installation
GDAL with the C# bindings and example applications can be loaded using
conda install -c conda-forge gdal-csharp
Usage
The Conda package for GDAL version 3.5.0 and later uses the CMAKE build scripts and therefore there have been changes in the build process and the artifacts produced.
GDAL 3.5.0 and later
The Conda package for GDAL version 3.5.0 and later is built using the new Cmake build scripts.
.NET Target Framework
On all architectures (i.e. Windows, Linux and Mac), the bindings are compiled using .NET6.0 as the current (at the time of writing) LTS version.
Package Artifacts
The Conda package contains two sets of artifacts:
The SWIG wrapper Dynamic Shared Objects (DSO) -
gdal_wrap.dllorlibgdal_wrap.soorlibgdal_wrap.dylibetc. These are loaded as one would expect for a Conda package (i.e. in thebinfolder in Windows and thelibfolder in Unix) and thus will automatically link to the correct version of the GDAL DSO and the dependencies, andLocal NuGet packages for the actual C# bindings (i.e.
gdal_csharp.dll,gdalconst_csharp.dll,osr_csharp.dllandogr_csharp.dll). These are created as packages calledOSGeo.GDAL,OSGeo.OSRandOSGeo.OGR. These are loaded into theshare/gdalfolder.
Usage
To use the bindings in your application, you will need to basically do the following:
Add the relevant Packages to you application as local packages, and
Add the DSOs to the search path for the application.
The former is not complicated and can be done by defining a local source, either global (as is explained here ) or in the build command as is shown below.
The latter can be based on Conda for a console application, as is shown below, but if you are working in an IDE (which being a .NET IDE knows nothing about Conda) and/or working on a GUI application (which is not going to be running in a Conda environment) you are going to have to sort out the DSOs your self; probably involving copying the relevant DSOs into the application package.
Usage Example - Windows
The most simple example would be:
Create a new application (in a dedicated empty folder)
dotnet new console
Create a small application (by replacing the contents of
Program.cs).
using System;
using OSGeo.GDAL;
namespace testapp
{
class GdalTest
{
static void Main(string[] args)
{
Console.WriteLine("Testing GDAL C# Bindings");
Gdal.UseExceptions();
Console.WriteLine($"Gdal version {Gdal.VersionInfo(null)}");
}
}
}
Add the GDAL package
dotnet add package OSGeo.GDAL -s %CONDA_PREFIX%\Library\share\gdal
Compile or run
dotnet run
Provided you run these commands in a Conda environment (containing the gdal-csharp package) this should just work.
Usage Example - Unix
Create a new application (in a dedicated empty folder)
dotnet new console
Create a small application (by replacing the contents of
Program.cs).
using System;
using OSGeo.GDAL;
namespace testapp
{
class GdalTest
{
static void Main(string[] args)
{
Console.WriteLine("Testing GDAL C# Bindings");
Gdal.UseExceptions();
Console.WriteLine($"Gdal version {Gdal.VersionInfo(null)}");
}
}
}
Add the GDAL package
dotnet add package OSGeo.GDAL -s $CONDA_PREFIX/share/gdal
Compile or run
dotnet run
警告
This will not just work under Unix since, unlike Windows, the Library Search Path is separate from the Process Search path and is not set by Conda.
To make this work, you will probably have to change the Library search path, which is ok for development but should not be accepted for production (which means that you will need to copy the DSOs to the application search path).
Under Linux:
export LD_LIBRARY_PATH=$CONDA_PREFIX/lib
Under OSX:
export DYLD_LIBRARY_PATH=$CONDA_PREFIX/lib
GDAL 3.4.x and earlier
Windows
注釈
You can test if the C# bindings are working in a Conda environment by running %CONDA_PREFIX%\Library\bin\gcs\gdal_test.
The DLLs are loaded into the %CONDA_PREFIX%\Library\bin folder, as is normal for a Conda environment.
The C# sample .EXEs are loaded into %CONDA_PREFIX%\Library\bin\gcs, because otherwise they over write the standard GDAL tools.
To run a sample application - eg GDALinfo.exe - add %CONDA_PREFIX%\Library\bin\gcs to the path and just run gdalinfo.
To link the DLLs into your code, you will need to include the DLLs into the project (which will almost certainly mean copying them to the project directory).
For a console app that is run from within the Conda environment (i.e. run conda activate) then they should work once compiled.
For GUI apps or other apps that cannot be run from with the Conda environment then you will have to setup the environment to make the GDAL DLLs available to the app.
Mac / Linux
注釈
You test if the C# bindings are working in a Conda environment by running mono $CONDA_PREFIX/lib/gdal_test.exe
The shared objects (i.e. *.so / *.dylib), the .EXE and .DLL files are all loaded into the $CONDA_PREFIX/lib
folder (not the bin folder as you might expect). This is in line with the Mono documentation.
To run one of the sample applications (e.g. GDALinfo.exe), run mono $CONDA_PREFIX/lib/GDALinfo.exe.
To build a console app in Mono, you can do this in a conda environment simple using a command similar to this (changing the source name to your own):
msc /r:gdal_csharp.dll /r:ogr_csharp.dll /r:osr_csharp.dll /r:System.Drawing.dll /out:gdal_test.exe gdal_test.cs
If the compiled executable is run in the conda environment, this should work. For something more portable or a GUI app, then you have to work out the dependencies your self.
The DLLs can also be used in a .NET project, for instance built in VS. Just link the DLLs in as dependencies.
Differences in the Conda build
The Conda build is in some ways different from the "standard" GDAL 3.4.x build:
On Mac and Linux, the SWIG files are built as
*_wrapin line with the windows versions. This means that there are no.configfiles. Most importantly, this means that the DLLs can be used in .NET and Unity projects as well as Mono.On Windows, the sample apps are built in .NET5 and not .NET CORE 2.1.
These changes anticipated the standard build for GDAL 3.5.x.