[gdal-dev] Re: C#: Gdal on Win64

Tomas R monshi at home.se
Mon Mar 3 05:54:47 EST 2008


Seems to be working, reports back Version 1.6.0Dev released 2008/00/00.

Have now created a small test plugin to test if my custom map plugin, 
which relies on GDAL to work, will work with this minimalistic GDAL 
distribution.

If I do a try on my computer, removing all files but my current versions 
of the file you have provided  in 64 bit versions, nothing at all works. 
Can't even retrieve version number. Perhaps caused by the fact that it 
is a version targeted for FWTools. 

I will have to wait on my guinea pig for the actual results.One result 
back as I am writing this, number 2 below works. Number 1 not tested, 
some strange error in my code stops the execution before any call to 
GDAL is made.

In essential, what I need to be able to do, the use my map plugin has of 
GDAL are:
1: Set up a pair of spatial references (OSGeo.OGR), by use of EPSG or 
WKT strings, and use in a CoordinateTransformation.
2: Read images/bitmaps from various file formats. Using code close to 
the SaveBitmapDirect example found in  the C# tutorial files.

In short - what functionality do the FWTools libraries contribute with? 
Perhaps I can skip them and just distribute the GDAL binaries and the 
proj4 binary? Would that be enough for what I wish todo? And for the 
elevation plugin to perhaps? But the I would need to compile GDAL 
myself. Or?

Another plugin which uses GDAL is one which retrieves elevation data 
from files partly by use of GDAL. No idea what it actually do or how 
(DEM files?). Will have to wait a week to test his calls since he is 
away on vacation now.


Yours
Tomas

Tamas Szekeres skrev:
> Yes I can see that the .NET framework 2.0 x64 cannot load assemblies
> compiled with the x86 option, definitely. Funny enough that the x64
> 2.0 framework can work along with the 1.1 version pretty well but our
> FWTools bundle has 32 bit images so this option is not usable either
> as you have experienced before.
>
> I've recompiled your project with my 64 GDAL compilation and it seems
> working well. I've uploaded the modified project and the binaries.
> Currently I've included only the gdal and the proj4 related files.
>
> http://vbkto.dyndns.org:1280/GDALPlugin/GDALPlugin_sourcex64.rar
> http://vbkto.dyndns.org:1280/GDALPlugin/GDALPluginx64.rar
>
> Best regards,
>
> Tamas
>
>
>
> 2008/3/1, Tomas R <monshi at home.se>:
>   
>> Google Pages seems not to be ideal to act as place from where others can
>>  download files. Not at all.
>>
>>  Try this address instead:
>>  http://goto.glocalnet.net/stfiles/GDALPlugin_source.zip
>>  No bandwidth limit there. None that I know of at least (space given by
>>  my ISP).
>>
>>  Did try number 2. No success. When user tried to use that version of the
>>  DLL SportTracks didn't even bother to try to load the plugin. I guess
>>  there is some complex interaction between different version of .Net
>>  libraries. Or whatever.
>>
>>  The roundabout time is not to big, the user is quite fast at trying my
>>  patches but still, if it is not much to ask of you, could you try and
>>  see if you can get my plugin to play along nicely with both SportTracks
>>  and GDAL? Could it perhaps work if I target the project to .Net3.5?
>>
>>  Or if SportTracks were to be compiled with the flag perhaps...
>>
>>  Should perhaps mention that with the x86-flag set the plugin functions
>>  as usual on my computer. No difference whatever .Net version I target it
>>  on. Well, I do almost nothing in the code so not much can go wrong there.
>>
>>  Yours
>>  tired Tomas signing out
>>
>>  Tamas Szekeres skrev:
>>
>>     
>>> 2008/3/1, Tomas R <monshi at home.se>:
>>>       
>>  >
>>  >> Oh, thanks for testing my plugin. Really appreciate your assistance!
>>  >>
>>  >>  The source project, the whole VSE solution, you can find here:
>>  >>  http://mapplugin.googlepages.com/GDALPlugin_source.zip
>>  >>  Excluded are ALL DLLs from FWTools, just to keep down the size. I guess
>>  >>  you have those. Copy all DLL files in FWTools\bin to the folder GDALBin
>>  >>  in the project and set all files to be copied to target. Probably you
>>  >>  also have to set the target folder of the build to another location
>>  >>  since it is set to the location of the installation of SportTracks on my
>>  >>  computer.
>>  >>
>>  >>
>>  >
>>  > I couldn't download this file, I always got the following response:
>>  >
>>  > "The bandwidth or page view limit for this site has been exceeded and
>>  > the page cannot be viewed at this time. Once the site is below the
>>  > limit, it will once again begin serving as normal."
>>  >
>>  >
>>  >
>>  >>  1: Oh, my. No chance you (or who ever) moves FWTools to Net2 and
>>  >>  possibly Win64 soon?  I guess it is possible for me, on a XP 32 bit, to
>>  >>  compile it all to Win64 but it is unknown territory for me.
>>  >>  What would I need to recompile? Just the files the C# wrapper directly
>>  >>  interact with (gdal, gdalwarp, osr, ogr, gdalconst, mapscript) or all
>>  >>  (!) files of the FWTools package I may need? Which I actually need of
>>  >>  those - no idea.
>>  >>
>>  >>  2: Quick, dirty and may work. I will give it a try but, as you indicate,
>>  >>  it is far from a perfect solution. Took some time but I finally found
>>  >>  how to set this option in Visual Studio Express, this page helped me:
>>  >>  http://www.thescripts.com/forum/thread755379.html
>>  >>  Will give the Vista 64 user a version with the flag set and see if it
>>  >>  works.
>>  >>
>>  >>
>>  >
>>  > I'm afraid I couldn't express my priorities properly. I would support
>>  > option 2 much better than option 1. I'm saying this because compiling
>>  > some parts of the gdal is much painful, some of those (like SDE)
>>  > cannot be compiled at all. You also have to compile such way the
>>  > dependent libraries as well, and I guess some of those have no WIN64
>>  > support either.
>>  > However I'll be trying to put together a GDAL WIN64 wiki for reference.
>>  >
>>  >
>>  > Best regards,
>>  >
>>  > Tamas
>>  >
>>
>>
>> _______________________________________________
>>  gdal-dev mailing list
>>  gdal-dev at lists.osgeo.org
>>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>     



More information about the gdal-dev mailing list