| | 1 | = Split implementations across multiple assemblies = |
| | 2 | |
| | 3 | == The problem == |
| | 4 | |
| | 5 | The current Maestro API assembly has direct references to the offical MapGuide API (MapGuideDotNetApi.dll). The problem here is that MapGuideDotNetApi.dll has unmanaged dependencies, making it unsuitable for use in pure-managed environments such as Mono or Silverlight. |
| | 6 | |
| | 7 | == The solution == |
| | 8 | |
| | 9 | The solution is to split the ServerConnectionI implementations into their respective assemblies. Work on the 2.1 version of the API has already laid the groundwork for this (with the !ConnectionProviderRegistry class), but the separate implementations still physically resided in the same assembly. The work involved will be simply to: |
| | 10 | |
| | 11 | * Move the http implementation to OSGeo.!MapGuide.MaestroAPI.Http |
| | 12 | * Move the native implementation to OSGeo.!MapGuide.MaestroAPI.Native |
| | 13 | |
| | 14 | The existing !ConnectionProviders.xml file will be changed to point to these new assemblies. |
| | 15 | |
| | 16 | A thing to note as well, is that through this approach, we can actually have native implementations that target specific versions of the MapGuide API without having to resort to bindingRedirect hacks [http://trac.osgeo.org/mapguide/wiki/maestro/MaestroAPI/MapGuideDotNetApiVersions as we currently do] |
