Changes between Version 5 and Version 6 of GdalOgrCsharpVersions


Ignore:
Timestamp:
Apr 8, 2007, 4:01:57 PM (17 years ago)
Author:
tamas
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • GdalOgrCsharpVersions

    v5 v6  
    22= GDAL/OGR CSharp interface versions =
    33
    4 The GDAL/OGR CSharp interface is fairly new and the first official version was published along with the GDAL 1.4.0 release. As of the 1.4.0 release there was a substantial evolution in the interface based on the various user requests. Some of these changes in the current version (1.5.0) were backward incompatible with 1.4.0 and currently the transition to the current development version is suggested for the interface users and 1.4.0 is considered as deprecated.
     4The GDAL/OGR CSharp interface is fairly new and the first official version was published along with the GDAL 1.4.0 release. As of the 1.4.0 release there was a substantial evolution in the interface based on the various user requests. Some of these changes in the current version (1.5.0) were backward incompatible with 1.4.0 and the transition to the current development version is suggested for the interface users and 1.4.0 is considered as deprecated.
    55
    66== The main differences between 1.4.0 and 1.5.0, and the migration steps for the existing code ==
    77
    8 This chapter described the fundamental differences between the 1.4.0 and 1.5.0 versions. Although the 1.5.0 version is not yet released the CSharp interface users are encouraged to make this transition since it will be more difficult to make these steps later.
     8This chapter describes the fundamental differences between the 1.4.0 and 1.5.0 versions. Although the 1.5.0 version is not yet released the CSharp interface users are encouraged to make this transition as soon as possible since it will be more difficult to make these steps later.
    99
    1010=== Support for the enumerated types of the C# interface (#1559) ===
    1111
    12 The 1.4.0 version treats the enumerated types as integers. Handling integers instead of enums is quite uncomfortable for the .NET developers since they don't enjoy the benefit of the autocompletion support of the IDE. The 1.5.0 version exposes the enumerated types to the interface and therefore the programmer should use the proper values instead of integer constants of the module class or using the gdalconst assembly. Every CSharp sample application has also been modified to reflect this behaviour.
     12The 1.4.0 version treats the enumerated types as integers. Handling integers instead of enums is quite uncomfortable for the .NET developers since they don't enjoy the benefit of the autocompletion support of the IDE and it's quite an unconfortable to find out the possible values of a particular type. The 1.5.0 version exposes the enumerated types to the interface and therefore the programmer should use the proper values instead of using integer constants of the module class or using the constants from the gdalconst assembly. Every CSharp sample application has also been modified to reflect this behaviour.
    1313
    1414As an example in GDALColorTable.cs we use
    … …  
    8282}}}
    8383
     84Many of the functions use the CPLErr enum as the return value but some of them still use integers though. This behaviour itself falls outside the scope of the C# bindings, so the developes may use type casts whenever needed like:
     85
     86{{{
     87if (ds.BuildOverviews(args[1], levels) != (int)CPLErr.CE_None)
     88{
     89   Console.WriteLine("The BuildOverviews operation doesn't work");
     90}
     91}}}
     92
    8493=== Changed the names of the Windows builds for a better match with the GNU/Linux/OSX builds ===
     94
     95The 1.4.0 version uses different filenames for the Windows and the GNU/Linux/OSX builds. This behaviour makes difficult to include the SWIG generated interface files into the daily shapshot because the wrappers are genereted on Linux but should be usable also on Windows. Since the Windows builds have been affected by this change the programmers should be aware making references to the proper assembles in this case like:
     96
     97{{{
     98csc /r gdal_csharp.dll /out:MyEXE.exe MySource.cs
     99}}}
     100
     101instead of:
     102
     103{{{
     104csc /r gdal_gdal_csharp.dll /out:MyEXE.exe MySource.cs
     105}}}
    85106
    86107=== The gdalconst assembly is now deprecated ===
    87108
    88 === Added support for Dataset.!BuildOverviews (#1552) ===
     109The constans related to the GDAL and OGR projects are now included in the corresponding assemblies. There's no need to reference a separate assembly any more. In addition many of the existing constants might have to be changed, like:
     110
     111{{{
     112ColorTable ct = new ColorTable(PaletteInterp.GPI_RGB);
     113}}}
     114
     115instead of using
     116
     117{{{
     118ColorTable ct = new ColorTable(gdalconst.GPI_RGB);
     119}}}
    89120
    90121=== GDAL C# libtool build support (#1558) ===
     122
     123The 1.4.0 version required to use the ''--without-libtool'' parameter at the configuration of the GNU/Linux/OSX builds. This problem have been corrected with the latest development version and will not be backported to 1.4.0.
    91124
    92125=== !CreateFromWkb support (#1565) ===
    … …  
    94127=== Dataset.!ReadRaster, Dataset.!WriteRaster support ===
    95128
     129=== Added support for Dataset.!BuildOverviews (#1552) ===
     130
    96131=== Examples added ===