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 made a screencast demonstrating Moonlight Development on Mac using MonoDevelop. Today, I bring you the same thing on Linux:
Unfortunately, getting this running isn't quite as simple as the Mac installer. However, if you're on openSUSE/SLED, it's almost as easy, using my trunk MonoDevelop packages from the openSUSE build service (1-click install for openSUSE 11.1).
You just have to download and extract my Moonlight SDK, extract it somewhere, then tell MonoDevelop where it using the MOONLIGHT_2_SDK_PATH environment variable:
export MOONLIGHT_2_SDK_PATH=/full/path/to/MoonSDK monodevelop
If you don't have openSUSE/SLED, you'll have to use the Mono 2.4 VMWare image or build MonoDevelop from trunk. If you build MonoDevelop from trunk, I suggest not installing it, and instead using "make run". If you don't even have Mono 2.4, you'll need to build that too, and please use a parallel environment if you don't want to risk messing your system up with hard-to-diagnose problems.
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:
Note that, as I said before, this is an alpha preview release of MonoDevelop, but I feel that it's already very usable. After seeing the screencast, I'm sure you'll agree. Download it from the Mac Preview page on the MonoDevelop website.
The Moonlight support in MonoDevelop trunk is entirely functional on Linux too, but it's not so easy to get it running since you need to build and install the Moonlight stack from source, and I would strongly advise against doing this unless you're comfortable with setting up a Parallel Mono Environment. However, it's easy if you use a binary Moonlight SDK like the Mac package does, and tomorrow I'll blog about how to do this with my MonoDevelop trunk packages for openSUSE.
I wrote much of the Silverlight/Moonlight project support code in the lead-up to the 2008 PDC, but the Moonlight 2.0 toolchain and runtime wasn't complete enough to make it worthwhile for me to finish the build/run support, so I focussed on other things, and we quietly dropped the addin from the MonoDevelop 2.0 release. On Friday, with the first Moonlight 2.0 preview and Mac MonoDevelop preview looming, I decided to finish it off, and did so over that afternoon and the weekend. I spent Monday and Tuesday polishing it and making it possible to bundle the Moonlight SDK in the MonoDevelop app.
It still needs work — the XAML completion in particular is a quick hack I put together one evening during PDC — but I believe that it's already a great way to build your Silverlight apps quickly and easily!
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.
Among other things, I have:
This has been made difficult by the native GTK+ Mac. Although the basics work very well, there are substantial problems with some of the more advanced things we do, such as key capturing for accelerators, and custom widgets. In the future we will be fixing issues upstream and shipping patched GTK+ builds with Mono, but for now I've been focussing on making everything work with the released Mono 2.4.
To do much of this, I had to build a large set of Carbon P/Invoke signatures and wrappers, and getting these right took some time. It seems to me that this could be the basis of a "Mac Bridge" in the style of the Vista Bridge. Having such managed wrappers would make it easier for developers to make their apps integrate more closely with the unique aspects of various platforms.
This work will be released in MonoDevelop 2.2. Right now it's not finished, and is very much an alpha. However, since it's already a substantial improvement for Mac users, I am making available a Mac preview build. This is a trunk build that has undergone no QA testing. I simply update it whenever I feel that trunk is usable and bugfixes or improvements have been made since the previous build. Use at your own risk. I have already listed a number of known issues.
Download it from the Mac Preview page on the MonoDevelop website.
If you do run into problems that aren't on the known issues list, please file bug reports. And, as ever, contributions are more than welcome.
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.
While we were there, we went to the Independent Games Festival Awards, and there were many interesting-looking games. One in particular that stood out to me was Dyson, because of its elegant, abstract, procedurally generated art. It's an "ambient real-time strategy" game that involves exploring and conquering asteroid belts with fleets of self-replicating seedlings.
The next day, someone talking to us at our GDC booth mentioned that Dyson runs on Linux using Mono! It uses SDL via the Tao wrappers. It doesn't run on 64-bit Linux yet; it looks like Tao.Sdl isn't 64-bit safe. Fortunately, I have a 32-bit parallel Mono environment, which isn't too hard to set up. However, setting up SDL and the dependencies for libgdiplus was nontrivial, so I don't recommend this path.
Anyhow, I got it working. Here you can see an almost-conquered asteroid belt:
And a close-up of fending off an invasion:
It's a lot of fun, and I'm looking forward to the full game's release! It's already listed on Steam with a July 31st release date, and says there that Linux is a supported platform — does that mean we'll see Steam on Linux soon?
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.
You'll need MonoDevelop 2.0 and Mono 2.4 or later. Make sure you have the package that contains System.Web.Abstractions/Extensions/Routing; on SUSE this is currently mono-extras. The addin includes a copy of the System.Web.Mvc.dll, so you don;t need to do anything special for that.
The addin is in the default MonoDevelop addin repositories (though I may be releasing updated versions from my own repo at http://mjhutchinson.com/mdrepo), so open MonoDevelop, click on the Tools->Add-in Manager menu, and click the Install add-ins... button. Select the ASP.NET MVC addin, and complete the installation.
Restart MonoDevelop, as there seems to be a minor issue with reference assemblies updating dynamically.
Now you can create new ASP.NET MVC projects.
When you create a new project, you'll see a project with all the basics set up, but minimal content, so that you don't have to worry about stripping out things you don't need. If even the "Hello World" view is too much, there's also an "Empty ASP.NET MVC Application" template.
There's an "Add View" command on the context menu for the Views folder, and an "Add Controller" command on the context menu for the Controllers folder.
Similarly to the Visual Studio ASP.NET MVC tooling, you can add custom T4 templates for the "Add View" command. As part of developing this feature, I implemented an open-source T4 engine from scratch, which Miguel already blogged about. I also added some syntax highlighting, code folding, and a document outline, and T4 compilation errors are reported in the error pad so you can jump to the error location.
I'm not happy with the restrictive nature of the ASP.NET MVC T4 host, but initially I went for compatibility with MS' version. In future I'd like a way for these templates to be able to output multiple files and expose additional properties to the GUI, and for the GUI to hide settings that the templates don't support. Note also that the "Strongly Typed" model class option is disabled, as the ASP.NET MVC T4 host exposes a type object for this, whereas MD doesn't load actual types. I'm trying to figure out a way around this.
And the proof that it works with Mono and MD? Hit F5 to build and run.
There are many more exciting features that I'd like to add, though I have many other things on my plate right now, such as improving MD's Mac support, so contributions are very much welcome.
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.
My starting point was Jonathan Pobst's zip file for MonoDevelop on Windows as a starting point for the dependencies, except GTK# which I installed using the Novell GTK# 2.12.8 installer for .NET.
I then downloaded the openSUSE 11.0 MonoDevelop trunk binaries from my openSUSE Build Service repository, since openSUSE 11.0 has GTK# 2.12, which matches the version available on Windows. I then used 7-Zip to extract the binaries from the RPM, added the dependencies. Also, since some of MonoDevelop links against Mono.Posix 1.0, whereas 2.0 was in the MD directory, I downloaded the mono-core RPM, extracted the Mono.Posix 1.0 dll, and put it in the GAC.
No luck. MonoDevelop failed to run. GTK# doesn't have a 64-bit version, so it failed to locate its glue libraries. Fortunately, Corflags.exe can be used to flag that a PE image needs to be run in 32-bit mode, so after installing the .NET SDK to get hold of this, I marked MonoDevelop.exe as a 32-bit binary and ran it. It worked!
I ran into many bugs, some of which Jonathan had already filed. Some are due to our assumptions about the host OS, but there are also a few subtle bugs and runtime behaviours that MD depends on, and finding these helps us to improve Mono itself.
On the whole, it was pretty successful. On my 32-bit machine I can create HTML files in MD on .NET with fully working code completion, and the code completion window even goes transparent. I'm looking forward to the day that we can offer MonoDevelop as a stable IDE and platform on Windows and MacOSX.
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.
As well as parsing a path, for code completion, the parser can also parse a complete document into a tree. This is useful for code folding, error underlining, and the document outline. The ASP.NET extension does not yet use it in this mode, instead using the older and better-tested Mono ASP.NET parser, so the first time this saw use was in XAML completion (about which I still need to blog). I recently (and trivially) "crossported" this code over to the HTML text editor.
The final piece of the puzzle was to write an HTML tag state for the parser to enable it to recognise and implicitly close tags when appropriate. Putting this all together, we get to the most important thing: the screenshot.

The blue underlines are warnings, when a tag has been implicitly closed. Note that the document outline is still correctly formed. The red underline is of course an error, and the parser has recovered from that too.