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

[Tamas Szekeres]

I think you'd require a better versioning of the assemblies in order to
install that side by side in the Global Assembly Cache (am I right?). The
biggest problem around here is to properly load the the late bound unmanaged
dll versions (loded by LoadLibrary) which uses a different mechanism
(searcing for the dll-s in the executing directory and the PATH environment)
which doesn't allow to have those versions side by side.

We could also try intalling the unmanages dlls in the SxS, and refer to
those files in the assembly manifest (which may cause pre-loading those
dll-s) but I didn't try this solution and I can't confirm whether it works
or not.

Best regards,

Tamas



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

> Ok. To clear it out.
>
> I have a plugin which make gdal available for plugins within SportTracks.
> Actually, just adds gdal libraries to the path the plugins find them at
> runtime. That is, late bindings.
>
> In simple words. How do I go about updating the plugin?
> If I have gdal 1.5.1 on the path and  a plugin compiled against gdal 1.6.1
> it fails
> If I have gdal 1.6.1 on the path and a plugin compiled against gdal 1.5.1
> it fails.
> Two independent version of gdal installed, only one of them is loaded and
> available (the one with the lowest GUID actually)
>
> You have added a strong name in gdal 1.6, do this affect this behaviour?
> When moving to gdal 1.7 will  any of the above setting work (switch 1.5 to
> 1.6 and 1.6 to 1.7) or will it always be cumbersome to upgrade?
>
> Any suggestions? It is a bit hard on the developers, and users!,  depending
> in my plugin, me telling them "I will update gdal next week, it will break
> your current version of the plugin".
>
> One of the developers has a solution on his part. He sets up a wrapper that
> tries to bind to gdal 1.5.1 and one wrapper that tries to bind to gdal
> 1.6.1. The one that works he uses and it provides the function calls to gdal
> he needs. This way it will be possible for him to support multiple version,
> two  wrappers should do since I will put the 1.5 version off line at the
> time I upload 1.6.1 version. 1.5 version should die. Other plugin developers
> can of course also use this method and it is not to cumbersome I guess.
>
> Environment. 1.6.1 is compiled with VSE 2008, old version was compiled with
> VSE 2005. Only x86. SportTracks now compiled with an x86 flag, forcing it to
> run in 32 bit mode because of various problem with plugins in 64 bit mode.
>
> Since you (now) have compiled versions on the web perhaps I should give up
> compiling gdal myself?
>
> Thanks for the quick and very good answers both of you.
> Yours
> Tomas
>
> Tamas Szekeres skrev:
>
>>
>>
>> 2009/6/30 Tomas R <monshi at home.se <mailto: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
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090701/ceec8a7e/attachment-0001.html