[Gdal-dev] Re: nmake for c # interfaces

[Tamas Szekeres]

The previous explanation was fairly exhautive :)

The recent version (in SVN trunk) links to the gdal.dll dynamically so
gdal14.dll should also be available to load. In addition to the
proj.dll the gdal14.dll might load further dll-s depending on the
functionality used. You can download the recent FWTools to obtain all
of the required libraries.(You might alter the names of the *_fw.dll
files to the original names)

Most of the frequently used C API funcions are mapped to the SWIG API
but I think we still have missing ones. If you find something missing
please file a ticket for that item.

I guess only a few people compile against the Win64 platform. The
current buildbot configuration (http://buildbot.osgeo.org:8500)
contains a Win64 builder to make sure the project compiles on this
platform as well.  So as to run the Win64 images most of the depencies
like the gdal.dll should also be compiled for this platform.


Best regards,

Tamas



2007/7/3, Simon Perkins <sy at perkins.net>:
>
>  kevser sonmez wrote:
> Hi again,
>  By getting a snapshot from the cvs the error has gone related to that tiff
> :)
>  But I have another problem;
>  The test data wouldnt work and the
> system.typeinitializationexception is thrown by the
> ogr.registerall () command.
>  I searched for the mailing archives, the error seems to be related with the
> missing of some required dll's. (proj.dll or some other) But actually I dont
> know which dlls should be referred, that is should be on the path??
>
>  If you need proj.dll then you probably need to build the PROJ4 library
> which is separate from GDAL, though you'll find links on the GDAL web page
> to it.
>
>
>
> Another question is, I cannot refer to the wrap.dll s from the csharp
> project (e.i. csharp_wrap.dll) from a csharp project, is this normal?, it
> complains about that dll is not a COM component or a valid assembly? I dont
> know much of C #, so sory :((
>
>  In .NET projects, you can only add direct references to .NET assemblies.
> Only some of the DLLs produced by SWIG are assemblies - namely those that
> have corresponding .cs files, rather than.cpp files. The assemblies in turn
> call the unmanaged DLLs. So, add references to gdal_csharp.dll and
> ogr_csharp.dll in your C# project. Then make sure that all the other DLLs
> that you need (includling gdal_csharp_wrap.dll and gdal.dll) are in a
> directory that is on your PATH. Although you can't add references to those
> unmanaged DLLs, windows needs to be able to find them at runtime. To do
> this, it looks in various places, most importantly in the directory
> containing the executing application, and also in the directories on the
> PATH. Your proj.dll also needs to be on the PATH.
>
>
> And the last question is, is c# is complete in terms of the ogr, I mean; Is
> everything; that can be done in the c++ API, can also be done by using the
> c# bindings?
>
>  The OGR C# bindings are actually generated from the OGR C API, but
> reorganized through the magic of SWIG (and Tamas) to provide an object
> oriented API. Since the OGR C API is itself a wrapper around the original
> C++ classes, it typically provides a subset of the C++ functionality - for
> instance there is no hierarchy of Geometry classes. However, most important
> things are there, though there's no real documentation on what the C#
> binding provide except for the SWIG code itself. So, say that you're looking
> for a method described in the OGR C++ read/write tutorial. Once you have the
> C++ name, look at the C API to see what the equivalent C method is called.
> Then search through the corresponding .cs file in swig/csharp/ogr for a
> similar named method, and see what arguments it takes. There's generally a
> fairly simple pattern to the C++ -> C# name translation, but there are a few
> quirks.
>
>  Cheers,
>
>  Simon
>
>
>
>
>  And to mention, I am working with visual studio 2005, in an 64 bit windows
> XP...
>
>  Cheers
>  Thanks a lot for the contributions :)
>
>
>
>
> On 7/2/07, kevser sonmez <kevsemola at gmail.com > wrote:
> > Hi,
> > I have been trying to build the gdal and swig files using the nmake
> utility, for the csharp part of the swig (csharp seems to have the good
> documentation :) ). When I try to build the gdal core library, it seems to
> fail at the frmts directory for the tiff library. It gives the error,
> > " This version of tif_config. h header is dedicated for Windows CE
> platform !"
> >
> > I can produce the four namespace dll s for the c# interfaces but since I
> cannot produce the core gdal library with the nmake, the linking cannot
> succeed.
> >
> > I am trying to compile it for a win64 bit system and setting the WIN64=YES
> options in the nmake.opt file and also in the comandline when calling for
> nmake.
> >
> > Any ideas are geratly appreciated ...
> > Thanks in advance :)
> >
>
>  ________________________________
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>