# Compiling the C# bindings - Legacy Scripts

This page describes the primary steps when creating the GDAL/OGR C# binaries from the source.

In most cases this is not necessary and it is better to use one of the pre-compiled sources, such as GisInternals or Conda.

## Building on Windows

To building the C# interface, you need a compiled version of the GDAL core. This can be the result of a manual compilation or can be linking to one of the prebuilt binaries. In the former case the following should be run in the clone of the GitHub repository used to build GDAL and the steps to create the environment should not be necessary.

### Requirements

The build environment has the following dependencies:

- nmake / Visual Studio

- SWIG 3/4

Note

The GDAL test scripts windows_build.yml use VS 2019 (MSVC Ver 1920) so it would make sense to use the same versions.

Note

SWIG is used to build the API bindings. The GDAL test scripts use version 3 and the conda build use version 4. Both Work.

### Build Environment

You need to set up the build environment. If you are using VS 2019, this might be the command:

VsDevCmd.bat -arch=x64

Note

The VsDevCmd.bat command can usually be found in `C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools` or the equivalent for the Community Edition.

If you don't want to bother with executing the proper vcvars*.bat you might use the development environment specific command prompt to accomplish this task. When using a Win64 compilation be careful to activate the x64 version of the command prompt installed on your system.

Note

If you are not running in an environment that has been used to compile GDAL locally, then there are a number of variables that need to be configured. The Conda `gdal-feedstock` configuration app can be used as a guideline about how to do that - build.bat.

### Creating the SWIG interface code

The first step is to generate the SWIG interface code. This will create a set of `.cs` definitions that will be compiled into the `.dll` files

To create the interface execute the following command (from the `swig\csharp` directory):

    nmake /f makefile.vc interface`

Note

You should edit nmake.opt adding the actual location of the `swig.exe` file.

### Compiling the code

After creating the interface the code can be compiled using this command (from the `swig\csharp` directory):

    nmake /f makefile.vc

Upon a successful compilation the following files are created:

- `gdal_csharp.dll`

- `ogr_csharp.dll`

- `osr_csharp.dll`

- `gdalconst_csharp.dll`

- `gdal_wrap.dll`

- `ogr_wrap.dll`

- `osr_wrap.dll`

- `gdalconst_wrap.dll`

- various sample applications

The `*_csharp.dll` binaries are the managed part of the interface. You should add a reference to these assemblies for using the classes of the interface. These `*_csharp.dll` files will load the corresponding `*_wrap.dll` files, which are the unmanaged part of the interface hosting the code of the gdal core.

### Testing the successful compilation

To test the compiled binaries, you can use:

    nmake /f makefile.vc test`

This command will invoke some of the sample applications.

Note

For the tests to work the location of the proj and gdal DLLs should be available in the PATH.

### Using MONO on Windows

If you have the Windows version of the MONO package installed you can compile the C# code using the MONO compiler. In this case uncomment the following entry in csharp.opt:

MONO = YES

Note

mcs.exe must be in the PATH.

## Building on Linux/OSX

### Requirements

The build environment has the following dependencies:

- make

- SWIG 3/4

- mono (probably any reasonable version)

### Build Environment

The build environment needs to be correctly configured. If you are not running in an environment that has been used to locally build GDAL then you should run the configure command from the GDAL root directory.

The conda gdal-feedstock recipe provides an example of how to do that - build.sh

### Creating the SWIG interface code

The first step is to generate the SWIG interface code. This will create a set of `.cs` definitions that will be compiled into the `.dll` files

To create the interface execute the following command (from the `swig/ csharp` directory):

    make generate

Warning

In versions of GDAL < 3.3.0 - this command will create incorrect interfaces without the correct namespace. See #3670.

### Compiling the code

After creating the interface the code can be compiled using this command (from the `swig/csharp` directory):

    make

Upon a successful compilation the following files are created:

- `gdal_csharp.dll` and `gdal_csharp.dll.config`

- `ogr_csharp.dll` and `ogr_csharp.dll.config`

- `osr_csharp.dll` and `osr_csharp.dll.config`

- `gdalconst_csharp.dll` and `gdalconst_csharp.dll.config`

- `libgdalcsharp.so / .dylib` etc

- `libogrcsharp.so / .dylib` etc

- `libosrcsharp.so / .dylib` etc

- `libgdalconst_wrap.so / .dylib` etc

- various sample applications (`*.exe`)

The `*_csharp.dll` binaries are the managed part of the interface. You should add a reference to these assemblies for using the classes of the interface.

The `*_csharp.dll` files will try to load the corresponding `*_wrap.dll` and are redirected to the `libxxxcsharp.*` libraries, which are the unmanaged part of the interface hosting the code of the gdal core, by the `*.dll.config` definitions.

### Testing the successful compilation

To test the compiled binaries, you can use:

    nmake test

This command will invoke some of the sample applications.

Note

For the tests to work the location of the proj and gdal libraries should be available in the PATH.

### Using The Bindings on Unix

Note that the bindings created by this process will only work with Mono at the moment.

To run one of the prebuilt executables - you can run them with Mono as follows :

mono GDALInfo.exe

Both the managed libraries (i.e. the DLLs) and the unmanaged libraries must be available to Mono. This is in more detail in the Mono documentation