[gdal-dev] Future compatibility - plugins (C#)

Tamas Szekeres szekerest at gmail.com
Tue Jun 30 15:16:21 EDT 2009


2009/6/30 Tomas R <monshi at home.se>

> Trying to update my plugin to SportTracks that makes it possible for other
> plugins to the great program to make use of Gdal. Currently the plugin uses
> Gdal 1.5.1 and the plan is to move to 1.6.1


> There seem to not be a "soft" way to upgrade as a move to gdal 1.6.1 will
> break the other plugin. Are the changes between 1.5.1 and 1.6.1 so great
> they require a break in compatibility?


Tomas,


I can't recall how the architecture of SportTracks is looking like (how it
handles the plugins) and it seems your question is related to this. Assuming
it may use something like late binding to the assemblies may result some
kind of independence among the plugins and I suspect reinstalling a new
version won't violate the other (quite untelated) assemblies. Or will you
intend to keep 2 versions side by side to the application?



>
> In  the future, upgrade to Gdal 1.7 will this also not be backward
> compatible? Are there anything I can do when compiling Gdal than may
> simplify the transition? Say that a plugin linked to the 1.6.1 C# dlls will
> also work with the 1.5.1 dlls? That way it will possible to roll out the
> other plugins with support of Gdal 1.6.1 and some time later go out with the
> upgrade.
>

I would discourage mixing the dll-s from different compilations due to a
bunch of unpredictable issues may happen. Mixing the versions of the dll-s
at the swig side (ie gdal_csharp.dll and gdal_wrap.dll) is almost impossible
since the exported functions between the dll-s may be a target of frequent
changes. The gdal C API seems to be more invariant but the version change
implies different dll names which prevents from loading the newer versions.
Moreover you should also use the same compiler to compile these dll-s so as
to depend in the same CRT runtime.

You might also decide which framework is to be supported and which
architecture (x86 or x64) depending on how the host process have been
compiled. Most of the possible combinations are covered by the regular
builds can be downloaded from this location:
http://vbkto.dyndns.org:1280/sdk/Default.aspx

Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090630/a4aabed9/attachment.html


More information about the gdal-dev mailing list