To improve the pythonic-ness of our bindings, our container classes should implement the container and mapping protocols so that instances of these objects can be operated on as though they were lists and dicts.

The python binding is reporting memory leaks on FdoDateTime objects. The issue it seems is that FdoDateTime has no destructor defined, so SWIG cannot free the pointer.

This issue is compounded by the fact that we run SWIG with nodefaultctor and nodefaultdtor, meaning that no default destructors are ever generated for FdoDateTime.

We need to change this so that nodefaultctor and nodefaultdtor is controlled from within the SWIG interface files so that when we hit FdoDateTime, we want SWIG to generate a default destructor for it

AppVeyor's NUnit runner seems to choke on our test suite. Despite all tests passing the runner itself will crash on exit causing the entire build to be flagged as failed.

This looks to be a cryptic issue: http://help.appveyor.com/discussions/problems/693-nunit-test-suite-passes-but-runner-fails-when-exiting-failing-the-build

Perhaps we can avoid it by moving to a different test framework

The Spatial and ExpressionEngine parts of the FDO API have not been exposed yet.

This is the only remaining SWIGTYPE_p unresolved proxy class.

FdoIdentifierCollection

• Support Add(FdoString*) - Adding identifiers without needing to create FdoIdentifier
• Support Add(FdoString_, FdoString_) - Adding computed identifiers without needing to create FdoComputedIdentifier

FdoFeatureSchemaCollection

• Support GetClassDefinition(FdoString_, FdoString_) - Return a class definition or null

FdoPropertyValueCollection

• Support SetValue APIs that allow adding a FdoPropertyValue without having to create one
• Support SetValueNull APIs that allow setting a FdoPropertyValue to null

The FDO collections that are returned to wrap around methods that deal with C-arrays are currently mutable (they can be added/removed/etc). We should be returning a read-only facade of these collections.

To support foreach iteration and LINQ to objects, our FDO collection proxy classes should implement some common .net collection interfaces

We've had success getting our pure-swig MapGuide .net binding to work on .net core. We should try the same thing for FDO.

Same issue as #2 but for Python

SWIG doesn't properly handle downcastable instances when wrapping methods that return a base class pointer. For simplicity, we should handle this on a case-by-case basis instead of trying to figure a one-size-fits-all typemap.

We should look out for and modify any method that returns:

• FdoICommand
• FdoClassDefinition
• FdoPropertyDefinition
• FdoIGeometry
• FdoExpression
• FdoLiteralValue
• FdoDataValue
• FdoFilter