[Gdal-dev] C# Bindings

[Simon Perkins]

On Thu, 2 Nov 2006 17:23:19 +0100, "Tamas Szekeres"
<szekerest at gmail.com> said:
> Simon,
> 
> >
> > As with so many VS 2005 problems, this turned out to be a manifest
> > issue. Inserting a few lines into the makefile.vc to embed the manifest
> > files into the DLLs fixed this. I'll check in these changes if nobody
> > objects. I suspect that similar lines need to be added for other SWIG
> > languages on windows if anyone else feels like doing that...
> >
> 
> Please give me the option to investigate the problem in more detail. I
> would not keen to decorate the c# assemblies with embedded manifests
> by default. I consider this as solely a VS2005 issue. I would also
> keep up the support for the MONO runtime currently on Windows and on
> Linux/OSX in the future.

The lines I added to the makefile check to see if the manifest file
exists before embedding it in the DLL, so AFAIK they would have no
effect on VS 2003. Would it have any effect on MONO builds?

If it only has an effect in VS 2005, why would you ever not want to
embed the manifest? It's one less file to worry about keeping around,
and in many cases you have to embed to get the DLL to work. In fact, I
couldn't get the swig C# test program to run without embedding the
manifest. My understanding is that putting the manifest in the same
directory as the assembly works OK for executables, but not for DLLs.
The OS seems to igore the .dll.manifest file. Sometimes it works OK,
because the libraries required by the DLL have already been loaded by
the calling executable, but not always. Is there any cost for embedding
manifests?


> As far as I remember the VS2005 linker is able to generate the
> manifest files along with the binaries. Placing the manifests in the
> same directory as the executable with the same name adding the
> .manifest extension would be sufficient in most cases.

The .manifest files are generated automatically, but not embedded. I
couldn't get the simplest test programs to work until I embedded the
manifest. This is with all the executables, DLLs, manifest files etc in
the same directory.


> > However, I'm still a little unclear about exactly how to use the SWIG
> > libraries. My primary interest is in the GDAL RasterIO functions, which
> > seem to be present as Band.ReadRaster() and Band.WriteRaster(). The C#
> > function signatures for these are:
> >
> 
> Well, I have dealt mostly with the OSR/OGR part of the interface so
> far and we have some typemaps missing mostly at the GDAL part.
> Therefore you cannot really use those functions with objects prefixed
> by SWIGTYPE_
> I'm continously adding the missing typemaps to the interface, and I
> have to write test samples so see how GDAL handles the parameters and
> the return values behind the scenes.
> So as to speed up this work if would be helpful if I got some expected
> C# examples to see how the folks would use the interface. Some of the
> specific test samples could be placed into the \swig\csharp\apps
> directory as well.

I'd be happy to help with this, since I need this one function ASAP -
ideally by the weekend... I'll take a look tonight and if I come up with
an obvious solution I'll run it by you. I'm not a SWIG expert by any
means, though I did write large chunks of the hand-rolled C# GDAL
bindings that were circulated on this list a few months back, including
this function.

Just off the type of my head, it would be nicest to have a generic
function with a signature that was something like:

  CPLErr ReadRaster<T>(int xOff, int yOff, int xSize, int ySize, T[]
  buffer, int bufXSize, int bufYSize, int pixelSpace, int lineSpace)

and similarly for Band.WriteRaster(). Overloads could be provided
without the last two arguments (or even the last four), for the most
common default cases. Is this kind of generic function possible with
SWIG? Or are you trying to preserve C# 1.x compatibility anyway (which
would preclude using generics)? Without the generic, we could either
have separate functions for each of the GDAL data types (my preference)
or have the user pass in some kind of void pointer and a type flag as in
the C function. What do you think? 

Actually, it may even be better to have the user pass in a pointer since
we often want to use GDAL to read/write from/to a Bitmap buffer, where
we can only access the internal buffer via a pointer. Either way, the
function is likely to have to be declared unsafe.

Cheers,

Sy