The Queenslanders are storming ahead with today's 0.9 release of Ruby.NET, now an open source community project. The new features include designer support of Windows Forms (be sure to check out this walkthrough). You might want to compare another Windows Forms approach with IronRuby and Ruby in Steel.
If you run into error such as
The element 'Target' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'RubyCompileTask' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'. List of possible elements expected: 'Task, OnError' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'
you may have to remove and re-install the Visual Studio 2005 SDK as well as Ruby.NET Runtime and the Ruby.NET VS Integration. Also be sure to remove all prior versions of Ruby.NET.
For some background info on the challenges and the ingenious solutions of the QUT team read "Compiling Ruby on the CLR". As it turns out, the difficulties lie not with the type mapping but rather with the object lifecycle and control flow prescribed by Ruby, which makes no clear distinction between compile time and runtime. The core of the challenge is harnessing the "dynamics" of Ruby with proxy classes to have them compile for the static CLR. The IronRuby approach is different (and probably somewhat easier) in that it targets the DLR (dynamic language runtime), a common type system for dynamic languages on top of the CLR also used by IronPython.
Ruby.NET project leader Wayne Kelly hints that they are "[they] are close to getting Ruby on Rails to run successfully". This is quite exciting and having two competing (?, MS gave money to the Ruby.NET project, hopefully without strings attached) implementations on the CLR will make it harder for MS to pull a J++ on Ruby (see here, here and here), i.e. co-opting and "extending" (forking), thereby compromising competing technologies.