MapGuide on Windows 10

Since Microsoft released a new preview build of Windows 10, I'd thought I give it a spin on VirtualBox.

My first impressions are simply that I am so happy to see the return of the Start Menu!

The other pleasant surprise was to see that the command prompt was finally resizable!

But my main motivation for giving Windows 10 a spin was to see if MapGuide will run on it. So I downloaded the 3.0 preview release.

I ran the installer and got this.

Okay, this normally means I have to manually "unblock" the executable in the file properties before retrying, so I did exactly that.

Except unblock does nothing! Is this a bug?

So before I chew out Microsoft for their "UAC v2.0" over-zealousness with this SmartScreen feature, I decided to click the "More Information" link on the SmartScreen dialog to see if it does anything and lo and behold, it gives me the options to finally run the thing!

Terrible UX there Microsoft. The "Run Anyway" option should be visible IMO and not concealed in the "More Information" link.

Nevertheless, after negotiating this little obstacle the installer ran after the UAC prompt. I decided to try the IIS/.net install option since:

• PHP and its MapGuide API bindings is installed regardless (it's why mapguide-rest will/should just work out of the box on any supported version of MapGuide), so we can also verify the PHP bits are working by loading a package through the Site Administrator
• This is the configuration that we always want to confirm and verify when testing support for newer versions of windows. The Apache/PHP/Java configurations are mostly self contained and can be generally trusted to work on any windows platform where there is a matching Visual C++ runtime library and a working Java SDK/RE for it.

So after waiting the normal amount of time for a MapGuide install to complete.

The Site Administrator runs without issues, allowing me to load my sample data package. Firing up the AJAX viewer (that is bound to the .net implementation due to my installation choice), shows that it is indeed functional

So there you have it. MapGuide 3.0 works on Windows 10. 

Given its current Technical Preview status, we cannot realistically have Windows 10 as a supported platform for MapGuide 3.0, but should you want to try, chances are MapGuide should work as evidenced by this post.

MapGuide 3.0 feature showcase: Bumping the version number

So now you know. The next major release of MapGuide will be MapGuide Open Source 3.0

Why the major version bump to 3.0? It's mainly for us to signify to you (the MapGuide application developer) that we are breaking free from some of the cruft and baggage that has accumulated in MapGuide over the years.

This is the cruft that you will no longer see in MapGuide Open Source 3.0

Goodbye blank MgMap constructor

The blank MgMap constructor existed in the MapGuide API from the very beginning. A new overload of the MgMap constructor (introduced with RFC 9) allows access to various convenience APIs in MgMap, but such APIs can only be available with the use of the correct constructor: The one that is not blank.

Having two different behaviours based on which constructor you use kind of violates the principle of least astonishment. Even though we have deprecated the blank MgMap constructor and try to leverage Java/C# language features and having a dedicated blog post about it to try to communicate this fact to you, there's nothing actually stopping you from using the blank MgMap constructor and having convenience APIs in MgMap throw exceptions back at you as a result.

With the 3.0 release, we removed the blank MgMap constructor and associated verbose APIs, eliminating this confusion once and for all. The convenience APIs will now always work because there will now only be one MgMap constructor to use instead of two.

Goodbye DWF eMap support

DWF eMap is basically the DWF analogue to the MapGuide 6.5 ActiveX viewer of yore. It allows your maps to be viewed in the AJAX viewer using a DWF viewer ActiveX plugin that can consume eMap data from MapGuide.

The problem (beside the ugly ActiveX) is that eMap support has long since been removed in the DWF Toolkit. You needed Autodesk Design Review 2009 or older (AFAIK) to have a DWF viewer ActiveX control that supports eMap data. We've had to stick with an ancient version of the DWF Toolkit in order to support this feature. As a side effect of an ancient DWF Toolkit, this presents DWF interoperability issues with Autodesk products with newer versions of the DWF Toolkit. We've had stories of DWF files plotted from MapGuide crashing current versions of Autodesk Design Review.

With the 3.0 release, we've upgraded the DWF Toolkit to the latest version (7.7) and removed DWF eMap API and viewer support. If you are still somehow using this eMap functionality, this is the end of the line for you. You should seriously consider migrating to our current viewer offerings, or stay on the 2.6 series if this is not an option.

For more details of what APIs have been cut, you can consult MapGuide RFC 139

Isn't it ironic?

Nope, that title is nothing more than a segway into this post :)

I've just discovered an awesome language implementation library called Irony, and have been playing around with some grammar that you might be familiar with

This has positive implications for Maestro if I can get Irony to do what I want it to do.

So far that looks very promising!

Announcing: MapGuide Open Source 3.0 Preview

It's that time of the year where we kick release cycle for the next version of MapGuide into gear.

Grab the installers for MapGuide 3.0 here. Linux builds will follow shortly.

Stay tuned for what's new in MapGuide 3.0. I think you'll like what's in store.

Brainstorming: A pure .net MapGuide API

Here is something that just entered into my stream of consciousness.

Is it worth building a pure .net MapGuide API? Note that my question is not "can we?" but rather "should we?"

Because what is the MapGuide API technically speaking? It is nothing more than a C++ object-oriented abstraction of a TCP/IP connection to a MapGuide Server process. We can easily build the same abstractions in .net (using TcpClient). The real "effort" is figuring out the wire formats and protocols for how data is to be sent and received via TCP/IP to the MapGuide Server process, and you know what? Maestro has already figured out some of that, and for the rest we can always refer to the MapGuide source code and see how they do it.

This pure .net approach would give us an API surface area similar to what is currently offered by the official MapGuide API, except for:

• Coordinate System APIs (we can't exactly port that over to .net)
• Geometry APIs (likewise)

Which isn't exactly bad news as these parts are replaceable/interchangeable. That's what we already do in the Maestro API, we let NetTopologySuite handle geometry duties and farm coordinate system functionality off to Proj.Net

If P/Invoke (the mechanism by which the SWIG-generated libraries work in .net) proves to be too much of a pain to deal with for ASP.net vNext, this pure .net approach could be a feasible alternative provided you are willing to give up the use of MgCoordinateSystem, MgGeometry and friends. In return, you would have a single, 100% managed, NuGet-able library that has none of the bitness, dll and deployment problems that is symptomatic of the current .net MapGuide API, but with 80% of the functionality.

So what do you think? Would this be something you would use for building your own MapGuide applications in .net? If you already use the Maestro API for building your applications, I guess that answer would be yes.

These thoughts are brought to you by Microsoft's announcement of open sourcing .net and their next version of ASP.net, and my firing synapses thinking about how .net MapGuide applications can be a first-class citizen in both Windows and Linux in this new exciting .net world.

MapGuide in 2015 (or: my unofficial todo list for 2015)

Happy New Year to all my fellow readers.

Things have been a bit quiet on this blog on the MapGuide front, so I'd thought I start the new year with my current thoughts about what will happen to MapGuide in 2015.

MapGuide Open Source 3.0

The next release of MapGuide will be 3.0. This release has some really compelling new features that makes 3.0 a compelling upgrade. A "preview" release of 3.0 will be available shortly for you to try out. Also stay tuned for a series of blog posts that cover the new features of 3.0

MapGuide Maestro

As mentioned previously, I've decided that MapGuide Maestro 6.0 will be my final release. However, no definitive timeline is attached to this release schedule. So what that means effectively is ... expect regular "milestone" releases of Maestro 6.0 and when I feel that there is nothing left to do, that's when I'll make the final release and call it a day on this project.

mapguide-rest

The mapguide-rest project in its current form will be winding up soon. Most of the things I want to do have been implemented, and the limitations of PHP prevent us from taking mapguide-rest in directions I want to.

When I first announced mapguide-rest, I made clear my motivations about why I chose PHP for writing this extension. It was the only language target of the MapGuide API that works on both Windows and Linux with minimal configuration and deployment overhead (which eliminates Java as an option).

Then in November of last year, something happened in .net land: They decided to make it a great day to be a .net developer by open sourcing .net, making it supported on Mac/Linux and giving a non-gimped edition of Visual Studio away for free!

This announcement has changed my thinking with mapguide-rest, which is why I put the qualifier "in its current form" when referring to the mapguide-rest project. My current line of thinking with mapguide-rest right now is to wrap it up with a 1.0 release, and start work on the next version by porting mapguide-rest to ASP.net

I love the ASP.net platform, but at the time when mapguide-rest was first announced, it was still a windows-only option and I didn't want to make a windows-only MapGuide extension. This .net announcement changes all of that. By making ASP.net truly multi-platform, I don't have real reason to stay with PHP anymore. ASP.net lets us do many more things that are not possible with PHP (or it is very cumbersome to do)

• Better control of HTTP response output
• OData support
• Ability to create/run/schedule long-running background tasks/jobs.
• Real-time communication possibilities with SignalR
• Enabling better integration with other data formats, software and services by the virtue of the large offering of packages on NuGet

However, this vision of mine can't actually take off until we have a functional .net wrapper to the MapGuide API working on Linux, which will be one of my main areas of interest once the 3.0 release is out the door. If the stars align right, we might be able to see a post-3.0 release of MapGuide where .net, PHP and Java are all cross-platform MapGuide application development options! Wouldn't that be nice?

So there's some thoughts about what I think will be happening to MapGuide. Here's to a great and exciting year for MapGuide in 2015. Is there anything you'd like to see for MapGuide in 2015? Shoot in the comments below.