[Gdal-dev] Re: Problem using EPSG in C#

[Tomas R]

Ok Tamas, it kind of works...

I followed the steps you have described for me and those I found on the 
Wiki:
1: Downloaded latest trunk
2: Compiled  GDAL (how many of the steps must I do? All? Or just the 
first, I guess just the first)
3: Created the C# interface and compiled it.
4: Copied the resulting *_wrap.dlls to Fwtool1.3.0\bin folder
5: Added the new CSharp-dlls to my C# project.
6: Checked that the system path contains FWTools1.3.0\bin folder
If I try running my project after those steps I get an exception when 
trying to call GDAL, whatever *_wrap.dll that is called is not found/not 
possible to load.

When I add the wrap-dlls to the "root" of my C#-project, no apparent change.
When I copy the GDAL-dll to my projects root and include it in the 
build, together with the wrap-dlls, it works!
But is this how it now is supposed to be? I guess I with this setup can 
use GDALs basic function but all the functions which rely on other libs 
(which I have not tested/any knowledge of yet) are not available? For 
example reading and writing of GeoTiff images? (That is possible via the 
C#-bindings?)
For now I think I'm content with coordinate translation but I think I 
want to try how efficient GDAL is to use when importing maps of 
different formats. It would be nice to be able to rip directly from 
GeoTiff (or RIK) with GDAL.

Perhaps a bit OT but:
In basic it boils down to that I have now not a clear idea how to 
distribute the plugin I am building. Demand that FWTools are installed 
or include the nessecary dlls? O well, there is time left to think about 
that.

/Tomas

Tamas Szekeres skrev:
> Oops!  Some recent changes in gdal have been interfering with this
> setting. I've now fixed up the problem in the gdal-trunk and set the
> default option to link the C# dll-s dynamically to the gdal libraries.
> Please, checkout the latest version and repeat your tests.
> 
> It must be noted that after this change the gdal14.dll should be
> available to load when running the application or the 'nmake -f
> makefile.vc test' target.
> 
> Best regards,
> 
> Tamas
> 
> 
> 2007/5/10, Tomas R <monshi at home.se>:
>> I thought  I had the issue solved, that I had managed to compile the
>> correct C# bindings and so on.
>>
>> But, sadly no.
>> What have I got?
>> FWtools 3.0
>> Gdal source, from the latest Trunk
>> Got the whole SDK-kit from MS, Swig 1.3.31 and Visual Studio Express C++
>>
>> I manage to compile the whole GDAL-project. I manage to compile C#
>> bindings with CSHARP_STATIC_LINKAGE = YES and CSHARP_STATIC_LINKAGE = NO
>> but NOT with it commented out.
>> The compile with CSHARP_STATIC_LINKAGE = NO do not seem to affect the
>> result as would be needed. When I try to set up a SpatialReference with
>> an EPSG-code I still get a 6.
>>
>> With CSHARP_STATIC_LINKAGE  commented out the compilation halts when
>> creating gdal_wrap.dll:
>> > LINK : gdal_wrap.dll not found or not built by the last incremental 
>> link; perfor
>> > ming full link
>> >    Creating library gdal_wrap.lib and object gdal_wrap.exp
>> > gdal_wrap.obj : error LNK2019: unresolved external symbol 
>> _GDALIdentifyDriver at 8
>> > referenced in function "void * __cdecl IdentifyDriver(char const 
>> *,char * *)" (?
>> > IdentifyDriver@@YAPAXPBDPAPAD at Z)
>> > gdal_wrap.dll : fatal error LNK1120: 1 unresolved externals
>> > NMAKE : fatal error U1077: '"C:\Program\Microsoft Visual Studio 
>> 8\VC\BIN\link.EX
>> > E"' : return code '0x460'
>> > Stop.
>>
>> Why is it never as simple? Do I miss something?
>>
>> /Tomas
>>
>>
>> Tamas Szekeres skrev:
>> > Tomas,
>> >
>> > You'll have to comment out the
>> > CSHARP_STATIC_LINKAGE = YES
>> > in csharp.opt and recompile the C# interface. Using this setting the
>> > csharp dll-s will link against the gdal14.dll so the
>> > PushFinderLocation and ImportFromEPSG will operate on the same global
>> > data. In the future I consider to use this setting as the default
>> > option.
>> >
>> > BTW: I would propose to use the latest development version of the C#
>> > related stuff. There were some fundamental changes in the interface
>> > that might cause some changes in the existing code. For more
>> > information see:
>> > http://trac.osgeo.org/gdal/wiki/GdalOgrCsharpVersions
>> >
>> > You might also use the binaries of the latest FWTools
>> > http://test.gdal.org/fwtools/FWTools130.exe
>> > and replace the *_wrap.dll-s and *_csharp.dll-s inside with the
>> > compiled version.
>> >
>> > Best regards,
>> >
>> > Tamas
>> >
>> >
>> >
>>
>> _______________________________________________
>> Gdal-dev mailing list
>> Gdal-dev at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/gdal-dev
>>