API .NET Wrapper

SasaI_ · ‎03-01-2011

I noticed there were several requests for a .NET wrapper, but no work done (that I'm aware of) on one yet. Being a .NET developer, I figured a wrapper would come in extremely handy, so I decided to put in some effort into creating one. Having very little prior C/C++ experience I figured it would be a good way to learn the language while developing a useful library.

I've decided to go the C++/CLI route and create an equivalent .NET class for all of the exposed API classes (I've post-fixed the name of the classes with Net to distinguish them from the native API classes). Current code can be found at http://code.google.com/p/filegdb-dotnet-wrapper/. The wrapper is built against the beta 2 release of the API, and I will try to update it with the next release when one is available (provided there is enough of a demand).

Code is still in early stages of development. I've implemented most of the functionality (excluding access to buffers, so geometries, byte arrays, etc do not work yet), but I have not tested most of it. I've added two samples/tests based the GeodatabaseManagement and TableSchema projects found in ESRI samples. Using the code is pretty simple and generally similar to how it would be done from C++. Major difference is that objects/values are returned vs. returning the function call result code. Any errors caught during execution of the code (i.e. hr != 0) are thrown as an FGDBException, containing a short description of the error and the original result code. Documentation on the code is sparse - you will need to consult the official ESRI documentation.

Finally, my C/C++ experience prior to this project is minimal, so the C++ code may not be the best (especially in terms of memory management). Feedback is definitely appreciated. Let me know about any bugs found in the code, and I will try to fix them (or implement your fix if one is available). I will try to update the project as time permits based on demand.

I can be contacted through email at sasa at mapitout dot com or by posting in this thread.

ahuarte · ‎03-01-2011

Hi! excelent work! 🙂

I am working in other equivalent CLI/C++ DLL.
But I get a error in Table::GetDefinition() method.

See...
http://forums.arcgis.com/threads/23961-Spatial-Reference-Info

I tried your 'SQLTest' program of your 'API .NET Wrapper' and this method also fails.

            ....
            Console.WriteLine();
            Console.WriteLine("***** Running SQL Test *****");

            try
            {
                GeodatabaseNet gdbnet = new GeodatabaseNet();

                Console.WriteLine("Opening geodatabase.");
                gdbnet.OpenGeodatabase(gdbpath);

TableNet table = gdbnet.OpenTable("Cities");
string xml = table.GetDefinition(); -> ERROR ERROR ERROR

                ...

The no managed C++ samples in SDK work fine.

I reported this bug, but now I have no solution
Bye!

SasaI_ · ‎03-01-2011

Hm, very odd, the latest commit (at least I think I committed it) worked fine. I'll check it out tomorrow and post an update.

ahuarte · ‎03-01-2011

I edited a local copy of your code in 'SQLTest' by adding this ....

...

TableNet table = gdbnet.OpenTable("Cities");
string xml = table.GetDefinition(); -> ERROR ERROR ERROR

...

SasaI_ · ‎03-02-2011

I edited a local copy of your code in 'SQLTest' by adding this ....

...

TableNet table = gdbnet.OpenTable("Cities");
string xml = table.GetDefinition(); -> ERROR ERROR ERROR

...

If you make the OpenTable call with "\\Cities" as the table name (i.e. explicitly specify no parent), then the definition is grabbed and result is 0. If you open the table with "Cities" as the table name, then the definition is grabbed but result is -2147211775 (ITEM_NOT_FOUND). I'm not entirely sure if this is a bug or if it simply isn't documented properly. If you look at documentation of some other functions, such as Geodatabase->GetChildDatasets/GetRelatedDatasets, it notes that path should be specified as "\usa", which leads me to believe that all paths should have a leading "\" specified. Not sure why they still end up fetching the table definition even in case you don't have a leading "\". If you debug the code and look at contents of the string variable passed to Table->GetDefinition you'll notice that it is populated with the table definition, even though the result indicates it couldn't find the table.

Thanks for noticing the bug. I'll commit more tests and code updates today.

ahuarte · ‎03-02-2011

Thank you very much!

SasaI_ · ‎03-08-2011

I've done a number of updates to the code which includes implementing (almost) all API functionality, various bug fixes, and addition of a test project (both for testing and for illustrating how to use the wrapper). I've also added the source and bin downloads to the Google code project.

Project home is http://code.google.com/p/filegdb-dotnet-wrapper/
Code downloads can be found at http://code.google.com/p/filegdb-dotnet-wrapper/downloads/list

LabrecqueBruno · ‎03-17-2011

Nice wrapper, i have downolad-it yesterday, and the wrapper seems to do exactly what i was trying to do. But since c++ is very difficult for me, a this dotNet wrapper whould be able to do the job.

I will continue to check if update are available, but for now, the beta api with this first version of the wrapper will help me in what i need to achieve.

Tank you for sharing your work.

SasaI_ · ‎03-23-2011

Thanks everyone for the comments.

I've updated the wrapper to use FileGDBAPI beta 3 release. A couple of the tests still fail, so I have not created a src/bin download yet (you'll need to grab the latest changes from the svn trunk). I will fix the remaining bugs over the next couple days and add a new download for version 0.3.