Remove CSharp bindings

[rouault]

Nobody has stepped up despite call for action in https://lists.osgeo.org/pipermail/gdal-dev/2024-September/059550.html, drawing conclusions...

More cleanup would be needed. Will do if we go that road

[coveralls]

coverage: 71.536% (+1.5%) from 70.056%
when pulling cfe309e on rouault:remove_csharp
into abaccaa on OSGeo:master.

[rsking]

We do use the CSharp bindings for GDAL. The reason that I hadn't spoken up before was there was a call out for people to change the bindings to fix the UTF8 issue that people do not like. This has never been a problem for us at all, so it was a null issue for us.

If you need someone to look at the bindings, I can do so. I have looked at them in the past, and it is pretty daunting.

[rouault]

change the bindings to fix the UTF8 issue that people do not like

That's more an example and a symtom that nobody is actively and consistently maintaining the bindings, and keep up with new additions in the C API, or making sure to fix CI when there's some breakage, etc.

If you need someone to look at the bindings, I can do so. I have looked at them in the past, and it is pretty daunting.

Ideally a number of interested parties would collaborate together. Yes, writing SWIG typemaps is something hard as it involves good understanding of SWIG (you figure out by looking at existing stuff more or less close), the target language and C. That holds although for Python or Java.

[rsking]

@MaxRev-Dev I presume your packages (https://github.com/MaxRev-Dev/gdal.netcore) rely on the C# bindings as well?

[MaxRev-Dev]

@rsking Thanks for the call.
I was surprised by the recent developments. I'm not subscribed to the GDAL mailing list (I'm used to a more user-friendly interface), but I do see all the mentions here on GitHub.

I try to keep everything updated as frequently as possible. As for now I have it up-to-date with GDAL main release and planning to run the CI for a new release.
Regarding the current situation, I've noticed the issues with UTF-8. I attempted to set up GDAL for local development and explore SWIG. I even submitted a pull request to adjust some methods (#7517). However, I've since moved to a macOS machine, and Windows is no longer my primary development operating system. I struggled to find the correct setup process for macOS and left it as is.

@rouault, we are using GDAL at my current company for DEM processing and other related tools. We have recently moved from v2.4 Go packages to the latest version, on C# - v3.10.0. Several companies around the world, including ones in Ukraine, France, Germany, Canada, and China, utilize these bindings. The main package as 770k+ downloads, which is more or nearly the same as Gdal.Native.

I recognize that eliminating the entire set of bindings may not yield positive results. I'm afraid, this will require additional efforts from me to setup the build system once more. The last move from NMake required a lot of time to setup. And making this change will cause disruptions in releases at least for 6 months.
How could we sort this one? NOT applying this PR. We need only to find a SWIG developer. Other possible option could be to move them to my repository. Are there any potential pitfalls?

[tomgruszowski]

We use gdal.netcore package, these CSharp bindings are absolutely critical to us, please try to find a way to keep these.

Max's package is some of the highest quality open source code I've ever seen, he nearly instantly updates his package and multi-targets all OS's, incl arm, this is a must have to run cost effectively in the cloud.

[szekerest]

@rouault We are actively use the C# binding and satisfied with the current state, so I don't think it is reasonable to remove since there are no working alternative to access GDAL from the .NET framework. However I don't have too much free time to spend meaningful work for free, but I'm open to take over issues which are required by anyone who is willing to pay the time. In my understanding, the binding is in a fairly good condition an workable as it stands now.

[sharkAndshark]

Please do not remove it

[runette]

We also make extensive use of the C# bindings in a Unity context, and we indeed we maintain a seperate Unity UPM package for GDAL (so not based on the Nuget packages because : Unity).

We are also happy enough with the current state of the bindings which is why you do not see much activity - they work. Please do not remove them (and do not move them into a specific Nuget package).

Perhaps we need to be clearer about what the actual issue is? If there are issues with new features and /or CI/CD, I don't see them coming through the GH issues? If there is a need for a modernisation plan perhaps a more consulative and collaborative approach could lead to an action plan?

[rouault]

If there are issues with new features

basically they fall behind when new functions are bound to SWIG and typemaps are required. I usually do a "#ifndef SWIGCSHARP" to make things build (or avoid unusable csharp API to be generated). So users will not get the full experience they could get with the Python bindings let's say, and that's a bit of pollution in the .i file that hurts their readability

CI/CD

We don't have had any recently related to C#, but hard to know who to ping when such issue will undoubtedly arise when github updates some of their images

Perhaps we need to be clearer about what the actual issue is?

lack of someone(s) giving them regular love. Tickets about them never get addressed.

[rouault]

OK, closing. At least my message & feeling that the CSharp bindings are a bit in auto-pilot mode got clearly communicated.

Can we have at least a few interested parties add their name to https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system#binding-languages so we have more than one person being listed, in case we need to ping someone when some sort of urgency happens ? Thanks