Something is wrong with our reverse string marshaling

It's going to be impractical to demand a full MapGuide source tree that is built in x86 and x64 configurations as a pre-requistite to build these bindings, so we should add some scripts that help collect all the necessary artifacts (headers/libs/dlls) from an existing full source tree into a portable buildpack and have our bindings built against that instead.

• Update preparation tools to properly rewrite class id include paths in SWIG parameter file (instead of commenting them out)
• Run SWIG in XML mode to generate the XML dump of the MapGuide API surface
• Update the ClassMapGen tool to take the SWIG XML dump file and scan all the m_cls_id members for their values. These values will most likely be arithmetic expressions, so the actual id will need to be evaluated (maybe use exprtk to do this)Auto-generate the class map templates from this collected data.

Use the pending exception mechanism in SWIG to propagate caught MgException pointers to .net for rethrowing

Set up environment to allow these bindings to be built against MGOS 3.0

Although the original intent was to keep a monolithic assembly, it does complicate things if we want to introduce mg-desktop (that builds on top of the same common core) into the mix, which hampers our re-usability story which would be restricted down to source-compatibility.

So despite the initial rejection of preserving the split-assembly idea, we should at least try to see if it is possible at a minimum to split off the (Foundation, Geometry, PlatformBase) parts of the MapGuide API and have the (MapGuideCommon, WebSupport, WebApp) part depend on it in another assembly.

Now that our .net binding and its test suite are both functional, let's keep it that way by hooking the test suite up to Travis/AppVeyor

When running SWIG, SWIGTYPE_p_* proxies exist for STRING and STRINGPARAM meaning there are no typemaps for these types.

Now that our .net binding works on .net Core, port it over so that it works on the full .net framework.

HandleRef is not supported on CoreCLR >:(

So we have to add typemaps that revert back to using IntPtrs

Once #19 is fixed, the first port of call is for this to target netstandard. As our SWIG wrapper uses a very low surface area of .net in terms of classes, we should be able to target the lowest netstandard1.0. This means our wrapper will work on the oldest possible versions of .net core and .net full framework.

eg. MgSiteConnection.CreateService

Returns an instance of MgService and not the requested derived type.

This is the same problem we had when generating SWIG bindings for FDO, except for this we have actual class ids and class names attached to each object that can tell us what .net proxy to create.

HandleRef is supported here, which means we don't need our current IntPtr marshaling hacks.

Currently we are maintaining separate (but identical) class maps for .net and PHP.

This class map is a dictionary of class id -> class name, which is used to workaround SWIG's base inability to handle downcasting of derived types.

This class map should ideally be a JSON file that's fed to a tool that outputs what is currently PhpClassMap.cpp and MgClassMap.cs source files. This way we only have one source of truth.

We are currently having an undesirable effect whereby our marshaled wchar_t strings in .net core on Linux have garbage trailing characters. This blows up a fair chunk of our test suite on Linux.

Although our wchar_t typemap is based on the official Java binding, we lack the ability to infer the length of input strings, which may explain why we get trailing garbage.

Instead, we should probably try using char instead of wchar_t.

char has a consistent size on both Windows and Linux and the official PHP binding already uses char for strings that travel to/from the MapGuide module boundary, so it's not like char is an untested option.

Because we intend to build these bindings for more than one version of MapGuide, we need a tool to stamp the appropriate versions for source files that contain version numbers

Version 3.0.11 was recently released which added long-awaited support for PHP 7.

As it is imperative that we escape the pending EOL of PHP 5.6 which is in less than 2 years time, we need to explore a usable path where we can bundle in PHP 7 and a MapGuide API binding that works with this version.

Current checklist:

• Get downcasting to work. For example: MgSiteConnection::CreateService returns a proxy of MgService instead of the appropriate derived class
• Test APIs that deal with MgByteReader to verify our byte typemaps are working
• Because we downgraded to PHP 7.1, check if the pre-build sed patch workaround is still required
• Make sure we can throw MgException based exceptions
• Make sure MgException based exceptions are being properly released
• We should be building for the NTS (non-thread-safe) profile not TS as the binding in its current form (which is built for thread-safe PHP) cannot be used if hosting PHP in IIS (it uses non-thread-safe PHP). We can also use non-thread-safe PHP in Apache via mod_fcgid, so from a practical standpoint it's simpler to just build for the NTS profile.
• Since we've monkey-patched a custom destructor for MgException-derived proxy classes, find a way to get SWIG to not generate all those delete functions that will never get called.
• Put all the generated PHP code under a OSGeo\MapGuide namespace
• Get it building (Linux)
• Make existing PHP test suite pass (Windows)
• Make existing PHP test suite pass (Linux)

Now that .net core has finally reached RC2, let's port the current RC1 DNX-based CoreCLR wrapper over to RC2 and the dotnet CLI.

• Verify nuget package is consumable on full .net framework without any additional changes
  • Add MSBuild targets file for full framework to ensure unmanaged dlls are being copied to output
  • Have MapGuideDotNetApi build for AnyCPU
• Add full framework version of entire .net test suite
• Ensure it builds (Linux)
• Make .net test suite pass (Linux)
  • String parameters seem to be completed discarded or trashed (eg. new MgUserInformation("username", "password") throws MgInvalidArgumentException due to empty string parameters)

To simplify #12 the SWIG glue library that we currently make (MapGuideDotNetCoreUnmanagedApi.dll) should be re-usable for the full .net framework binding.

Therefore the name MapGuideDotNet_Core_UnmanagedApi is a bit of a misnomer as there isn't really any CoreCLR-specific native code in this library and should be renamed to MapGuideDotNetUnmanagedApi instead

• Get it building (Windows)
• Get it building (Linux)
• Build should follow same pattern as .net. Only build the SWIG glue library. Build the Java portion as its own step.
• Ensure java test suite passes (Windows)
• CentOS: Need to find and manually link in libmawt.so as linking in JNI_LIBRARIES pulls in this dependency causing an UnsatisfiedLinkError (not necessary, just don't link JNI_LIBRARIES)
• Ensure java test suite passes (Linux)
  • Ubuntu 14.04 (64-bit)
  • Ubuntu 14.04 (32-bit)
  • CentOS 6 (64-bit)
  • CentOS 6 (32-bit)
• Rename delete SWIG cleanup proxy method to something else (SWIG lets you choose a different name)

Currently our test suite can run on Linux with segfaulting (yay!) but still has lots of test failures. Looking at the test log show little that can help us because the parameters that are logged before each test are their values before any cleaning and normalization is done to them.

We need to restructure our test execution so that there is an explicit parameter collection and sanitization step that allows our logging mechanism to log the actual (post-sanitization) parameters that are used to execute the operation

Sadly, we cannot rely on .net core as a universally available dependency as it is not available on 32-bit Linux and it is not available for CentOS 6.x 64-bit.

Fortunately, these tools (SwigPrepare, PhpPostProcess) don't do overly complex things so it should be easy to rewrite them in C++

This is the latest stable release

We currently use hand-written vcxproj (Windows) and makefiles (Linux)

CMake will let us kill 2 birds with one stone

I've been noticing that the sample apps I'm building with the new MapGuideDotNetApi wrapper that any unhandled exceptions being thrown don't appear to have any error messages.

Check that there is no issues with exception messages being trashed when crossing the .net <-> native boundary.

The out string typemaps for the .net SWIG glue library will not compile on Linux without xerces headers present. This has slipped under my radar because the test Linux VM I was building these bindings in already had libxerces-c-dev package installed, which includes headers.

The work in #15 allows us to produce portable windows buildpacks so we can build this binding on Windows in both x86 and x64 without needing a full MapGuide source tree to build against.

For Linux, we should be able to build against an existing MapGuide install, as Linux shared libraries are both the "dll" and the "import .lib" in this case, so the missing piece that allows us to build our SWIG bindings is the necessary header files, which are not part of a MapGuide install.

We can just repurpose existing headers from the portable windows buildpack for this purpose.

For methods that take multiple string parameters, it seems that one or more of these strings will get corrupted. This is a blocking issue that must be resolved.

This will help streamline our ability to build the SWIG glue bindings for the various Linux distros

AppVeyor:

• Use VS 2017 image (hope it has v140 toolset, otherwise fallback to VS 2015)
• Grab the instantsetup bundle of the latest MGOS release and spin it up
  • Grab the matching "buildpack" for this release (need to prepare this)
  • Grab and install SWIG 3.0.12
• Do the main build/test
  • envsetup.cmd <major> <minor> <patch> <rev>
  • build.cmd
  • Build/run the .net test suite

TravisCI:

• Use ubuntu14 x64 image if available
• Use official ubuntu install script to headlessly install latest MGOS release and spin it up
  • Grab and extract headers from the "buildpack" for this release
  • Grab/build/install SWIG 3.0.12 (swigsetup.sh)
• Do the main build/test
  • ./envsetup.sh
  • make on src/Bindings/DotNet
  • Build/run the .net test suite

If we look at how various libraries in https://github.com/dotnet/corefx do their P/Invokes, they generally don't use IntPtr and they obviously don't use the (non-existent) HandleRef.

Instead, most use SafeHandle or some derived form of it. We should look at trying to do the same thing with our typemaps.

What Target CORE Framework will be compatible with MapGuideDotNetApi.3.1.1.9378-pre74.nupkg ?

I'm getting this error

dotnet add GoeMapping.CORE package MapGuideDotNetApi --version 3.1.1.9378-pre74

error: Package 'MapGuideDotNetApi' is incompatible with 'all' frameworks in project 'D:\Development\GOEMapping\Development\GoeMapping.CORE\GoeMapping.CORE\GoeMapping.CORE.csproj'.

Thanks for your help

Previously, IMake would generate custom files for .net property implementations that the (super-modified) copy of SWIG would process to insert property definitions to .net proxy classes.

SWIG already has a mechanism for this

%attribute

So IMake should just generate a MapGuideApi_Properties.i file containing all the %attribute typemaps from the various property definitions scanned by IMake