Closed jumpinjackie closed 3 years ago
Are you using MaestroAPI built from source or from the nuget package?
If nuget package, what package version? If from source, is it current git master HEAD?
I am using the nuget latest, using VS2019 nuget manager (3.1.2.9484) I have just loaded source so will try and link to that once I get the build working
When I build the Maesto API from source I get two issues: I don't get a MaestroAPI.http.dll I get an GetLegendImageStream is unimplemented when I mix a MaestroAPI.http.dll with my own build
Regarding no MaestroAPI.http.dll anymore, that's because the HTTP connection provider has been folded into the MaestroAPI library itself.
GetLegendImageStream unimplemented is weird, because it is implemented right here!
mg-desktop wrapper: https://github.com/jumpinjackie/mapguide-maestro/blob/ce0158e4e7edca7bb47437cfee62a8c06828624a/OSGeo.MapGuide.MaestroAPI.Local/LocalConnection.cs#L1213
roll-your-own MapGuide API wrapper: https://github.com/jumpinjackie/mapguide-maestro/blob/ce0158e4e7edca7bb47437cfee62a8c06828624a/OSGeo.MapGuide.MaestroAPI.Native/LocalNativeConnection.cs#L912
http implementation: https://github.com/jumpinjackie/mapguide-maestro/blob/ce0158e4e7edca7bb47437cfee62a8c06828624a/OSGeo.MapGuide.MaestroAPI/Http/HttpServerConnection.cs#L1581
Yes,,, I saw all those... but something in runtime didn't pick up the right DLL ?
Difficult to get messages etc as all on a remote VPN login/desktop but the reason I has to add the Maestro.http DLL back in from the Nuget package was that I got a compiler error that the class was inaccessible (protected?) when I used just the MaestroAPI (and ObjectModel) included directly with the project. There are obviously some differences with the Nuget (3.1.2.9484) and the build from git head because of the output DLLs... -- I also tried to update all the nuget package references but then got in a real mess as GeoAPI and NetTopologySuite start arguing about who owns which class in the code... but that's another story.
Plan is to go back to including the MaestoAPI and ObjectModel as project references in my solution and report from that point later.
If we work from the starting point that GeoAPI and NTS are not cooperating, then I already have a work-in-progress .net 5.0 feature branch that already updated NTS and gets rid of GeoAPI. I'll try to graft out these changes back into master and try to get new nuget packages up afterwards
I see your "feature/package-updates-2109" branch commits ongoing
Hi - sorry I can't apply latest merge to my environment until I request a firewall relaxation again for http. But I have gone back and built test project again directly against MaestroAPI.
My issue throws trying to initialise FixedWBKBReader()... but any break points in the constructor are not hit so I don't really understand why.
The trace is effectively: conn.FeatureService.QueryFeatureSource(...) which in QueryFeatureSourceCore(...) creates a WebRequest = ...SelectFeatures(...) which tries to return a new XmlFeatureReader(resp)
I can confirm that getting the actual HTTP request from reqAsUrl(...) returns an XML as expected from the MG Server.
What does your AppDomain loaded assemblies look like before the FixedWKTReader is new()'d?
This is the AppDomain of a test exercising the FixedWKTReader (before the package update merge, at commit: ce0158e4e7edca7bb47437cfee62a8c06828624a)
Does your AppDomain have these assemblies and with versions that correspond to whatever versions you are expecting?
Ah... maybe a useful helper. All is well apart from NTS which is showing 2.x in the assemblies. A look at the NuGet consolidate shows the Maestro project uses 1.15.3 but my main application is on 2.3 -- and the DLL within the \bin folder is the v2.3 one ... I will now try and get the source head updates from your last merge.
Hi, Included the API and ObjectModel projects from source (head) with the updated NuGet for NTS and all is good again. Excellent. Case closed. Thank you for support.
One observation (possibly intended behaviour?) is that it is possible to pass a list (array) of property names as an override into: FeatureService.QueryFearureSource(...)
However, if one of the property names is a geometry field then within: MaestroAPI\Schema\PropertyDefinitions.cs (line 260) PropertyDefinition Parse(...)
it will throw an Exception Maybe OK... but a geometry is a Property so a clearer Exception or handling would help?
Just a heads up @Crispin-at-Linknode
I added this test case and could not reproduce the exception. Which has lead me to believe that the condition on this line is not being hit for your particular case.
If you care the pursue this issue any further, I'm interested in what the value of the type
attribute for your geometry property is. I suspect it may be missing the gml:
prefix or the geometry type string is completely different.
@Crispin-at-Linknode wrote:
I hope you can see the image... I have transferred some code to a new WinServer2019 and MG 3.1.2 server and matched the Maestro API ... we have a drill-down point selector (to find all objects under a click, not just the top one). But the Maestro API is throwing an exception, like it hasn't resolved the "GEOMETRY" field properly?
Any help appreciated - not sure if it needs a API fix?