I make tools to help people create wonderful things.


Moonlight Development on Mac using MonoDevelop

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!

MonoDevelop Mac Preview Builds

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.

MonoDevelop with Mac main menu support

Among other things, I have:

  • Abstracted out the main menu and reimplemented it as a native Mac global menu.
  • Added handlers for Mac events, such as Quit, Dock Click, Open Files, etc.
  • Added Mac-specific command accelerators.
  • Made it possible to capture the Mac Command and Option keyboard modifiers for accelerators.
  • Made accelerators display everywhere using Mac-style glyphs.
  • Tweaked the text editor's caret and selection navigation to behave more like a Mac IDE, including Alt/Control word/subword splitting.

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.

MonoDevelop ASP.NET MVC on the Mac

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!

Running an ASP.NET MVC app in MonoDevelop on the Mac

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.

Dyson, a great game using Mono

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:

The Dyson game running on Linux using Mono

And a close-up of fending off an invasion:

The Dyson game running on Linux using Mono

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?

ASP.NET MVC MonoDevelop Addin Preview

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.

Installing the ASP.NET MVC Addin

Restart MonoDevelop, as there seems to be a minor issue with reference assemblies updating dynamically.

Now you can create new ASP.NET MVC projects.

Creating a new ASP.NET MVC project

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.

The Add View Menu

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.

The Add View dialog showing a custom TT template

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.

Running the default Hello World view

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.

MonoDevelop on Vista64

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!

Screenshot of MonoDevelop 1.9.2 on Windows Vista 64

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.

Completing ASP.NET Collection Properties

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:

Screenshot of an ASP.NET file in MonoDevelop showing autocompletion on the children of a collection property.

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.

HTML Completion

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.

Screenshot of an HTML file in MonoDevelop showing the warning underlines on implicitly closed elements.

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.

Brahma on Mono

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!

ASP.NET Completion and MonoDevelop Debugger Packages

All the basic ASP.NET code completion features I wanted to get into MonoDevelop are now essentially complete and working with the new code completion database subsystem that Mike Kruger has written to replace our old one. It handles controls, directives and HTML, all of their attributes, and some attribute values, including some colourful and time-saving examples. I've been migrating code "downwards" into HTML and XML completion editor extension, and I'll write another day about how this works and how it'll make good XAML and XML completion easier in the future.

I couldn't wait to get these features out to users (so you can start giving me bug reports!), and I think that the C# code completion has stabilised sufficiently after Mike's changes, so I started updating my MonoDevelop trunk builds again. You'll also be able to try out the text editor and C# completion improvements, your MSBuild project files will be more compatible with VS, and you can play with my vi modes.

The biggest news is that the Mono debugger is officially supported with the recent Mono 2.0 release, so I added MonoDevelop debugger packages for MDB and also for GDB, so you can try the fruits of Lluis' fantastic debugger work. As a bonus, I also created monodevelop-python packages for Christian Hergert's Python addin, and monodevelop-vala packages for the Vala binding that Levi Bard contributed.

I'm taking a short break this weekend to see the fall leaves, and after that I'll be attacking the bug queue and taking a look either at per-project text editor settings, or maybe bringing the Moonlight support in MD back up to speed.


Subscribe to Journal