MJHutchinson.com Michael Hutchinson's Home on the Web

In the Microsoft XNA EULA, I found the following restriction:

You may not use the software to develop programs that run on any platform other than the Windows, Zune or Xbox 360 platforms

I'm no lawyer, but this sounds like very poor wording. Does this mean that all source code developed with XNA Game Studio is restricted to use on those platforms, in perpetuity? That would mean that it couldn't even be used on a future, new Microsoft platform!

This seems to me to be unreasonable and probably unenforceable.

Yesterday I announced much-improved MonoDevelop preview builds for Mac, which include ASP.NET MVC support out-of-the-box. However, there was a little surprise in that build that I didn't mention — full support for building and running Silverlight projects using a bundled copy of the Moonlight SDK.

I created a screencast to show off how easy this makes it to develop Silverlight apps on the Mac:

The past few weeks I've been working on improving the MonoDevelop experience on the Mac, making it integrate better with the Mac experience. Along with ASP.NET MVC support and other soon-to be-announced excitement, I think this makes MonoDevelop much more interesting for Mac users.

After releasing a preview of the ASP.NET MVC MonoDevelop addin, I decided to try it on the Mac.

Although the MonoDevelop 2.0 release on the Mac is still an alpha, it's a lot better on the Mac than 1.0 was. Other than a couple of GTK+ redraw issues, the major remaining problems are mostly to do with lack of Mac integration, such as Ctrl-Click, top-level menu bar and Mac-like keyboard shortcuts. Making MonoDevelop completely supported on the Mac is one of our targets for MonoDevelop 2.2.

I downloaded the Mono 2.4 Mac installer and MonoDevelop 2.0 Mac installer (beware, alpha release) then followed exactly the same steps from my earlier Linux-based walkthrough, and apart from a couple of harmless warnings during installation of the addin, it worked flawlessly!

Since none on the MD team is familiar with Macs, contributions from Mac users would be most welcome, including testing and feedback about how to make it feel more Mac-like.

Last week, Miguel, Joseph and I went to the GDC again to promote the use of Mono as a runtime for games. I may write about that at a later time.

The past month or two, in addition to bugfixing for our recent MonoDevelop 2.0 release, I've been quietly hacking on a MonoDevelop Addin to support writing ASP.NET MVC applications. Those of you following me on Twitter may have picked up a few hints...

Now that Microsoft has released ASP.NET MVC under the MS-Pl licence, I'm making a preview release of the ASP.NET MVC addin for people who'd like to start playing with this exciting new tech on Mono. It's relatively immature, so don't expect everything to work perfectly, but it handles creating and running a VS-compatible ASP.NET MVC project just fine.

Last night I got MonoDevelop working (to some extent) on Windows Vista x64 using the Linux binaries, tweeting my progress along the way.

UPDATE: In another 5am hacking run this evening, I've managed to build MonoDevelop fully in Visual Studio 2008, and debug at all the way to the Welcome Page, using 32-bit debugging on Vista 64. However, I'm going to have to tidy the project file fixes a lot before I commit them.

I've recently been tweaking the ASP.NET completion, adding support for resolving valid children for a control. These can be properties, a property, or controls. More difficult was resolving the valid children for properties, but this is now done:

Unfortunately, there aren't actually any designer or parser attributes for limiting the children of a property, so in order to resolve the children, I assume it's a collection, and look for an Add method with a single parameter derived from Control. If this exists, I use its parameter to filter the types in the control completion list. It's an ugly hack, but it works perfectly for tables and wizards. In the worst case, MonoDevelop falls back to showing all controls.

With this done, the ASP.NET completion is essentially feature-complete.

The main thing I've been working on for the upcoming MonoDevelop 2.0 release is ASP.NET code completion, and I'm pretty happy with its current state. Recently I've been "downporting" this code into base classes to make it easier to write XML completion and HTML completion editor extensions. A while back I wrote a hybrid XML/ASP.NET/HTML parser, which I've been using in MonoDevelop for triggering ASP.NET code completion. The aims of this parser were to be extensible and to have good error recovery. This makes sharing code between XML-like completion extensions very easy — the completion triggering code and the path bar code are entirely shared between the editors.

After moving the HTML code down to a common base class, I decided to expose this functionality for actual HTML files, rather than just ASP.NET, and wrote an HTML text editor extension to handle this.

I'm very excited to see that Ananth, the author of the Brahma LINQ-to-GPU provider, now has it running on Mono using OpenGL.

If anyone's not heard of GPGPU, it's the technique of taking a graphic processor unit and using it to run general-purpose computation. Discrete GPUs are incredibly powerful, so if code is ported effectively, it sees a massive speedup. However, the graphics-centric APIs and ridiculously parallelised architecture make this non-trivial. This is where Brahma comes in. It takes your C# 3 LINQ expression trees and automagically runs them on your GPU.

I can't wait to see it running on Linux!