RubySharp Aug 22 2006
Recently I’ve been toying with John Lam’s pet project, RubyCLR. The very notion of Ruby and C# interaction interests me, as there are around a billion different situations in which I’d like to combine the two, to get the best of both worlds.
Now, I notice in a post today, that he has spotted that Tim Ng, a guy who works on the Visual Basic compiler team, has been playing with his creation. Only, the way he went about it seemed a little complex, and wasn’t using RubyCLR’s compatibility with interfaces to the max. So, I thought I’d outline a little test scenario I knocked up when I first started playing with it.
I’ll assume that you’ve followed the instructions, and are setup with the latest version of RubyCLR (I was using the code straight from the source tree).
Firstly, the code for the C# side of things (the “host”). This defines the interface, and provides a class for executing implementations of the interface:
Host.cs:
using System;
public interface IAddIn
{
string Name { get; }
string Author { get; }
void Work();
}
public class Host
{
public static void Execute(IAddIn addin)
{
Console.WriteLine("[{0}] : {1} by {2}",
addin.GetType().FullName,
addin.Name,
addin.Author);
addin.Work();
}
}
We can simply compile this into a standalone assembly:
csc -t:library Host.cs
This will output Host.dll, which we will now consume in our super-duper Ruby script, empowered by the magic RubyCLR. I won’t stick the entire contents of the client Ruby script here, however the full thing is available from here (the full C# source file from above is available here). For now, lets just look at the implementation of our C# written interface within Ruby:
class MyAddIn
implements IAddIn
def get__name
return "My first Ruby/.Net add-in!"
end
def get__author
return "El Draper"
end
def work
puts "This is coming straight from my Ruby written add-in!"
end
end
As you can see, in order to implement the Name and Author properties, we define Ruby methods called get__name and get__author (note the double underscore).
This is all useless unless within my Ruby script I actually call my C# host and pass an instance of my Ruby written add-in. After referencing the Host.dll assembly:
reference_file ‘Host.dll’
I’m able to make the call to the host:
Host.Execute(MyAddIn.new)
Running this is then easy - once you’ve executed the “setenv.cmd” batch file within the root of the RubyCLR project, simply execute:
ruby Client.rb
(ensuring that Client.rb and Host.dll reside in the same directory).
This then outputs:
[T32dda3e3] : My first Ruby/.Net add-in! by El Draper
This is coming straight from my Ruby written add-in!
(N.B. the type name changes each and every time the script is run, as the concrete wrapper type created around the Ruby code and passed through onto the CLR is dynamically generated at run-time using System.Reflection.Emit).
The above shows that we can define an object that implements a .Net interface within Ruby, and then pass an instance of this into a .Net written host class. It then executes methods directly on the object that itself then executes Ruby code. Pretty snazzy eh!
Like Tim, I have a number of things I’d like to be able to extend this with. For one, I’d like to be able to “compile up” the concrete CLR types representing Ruby objects, and then execute this from within a .Net host, namely a C# application. My work on tweaking the RubyCLR code so far has resulted in being able to correctly output the dynamically generated assemblies, however these types when executed within a C# host application result in memory errors, presumably because it is lacking the reference to the Ruby host context and the original Ruby source file. So I need to be able to instantiate a Ruby object from my compiled emitted assembly, and then somehow build a Ruby context back to the original source file so it can correctly execute the code, but all from within a .Net host. This is really a reverse of the main scenario that RubyCLR I think was probably invented for, but none-the-less I think it should be possible. Any ideas, John? ;-)
Technorati Tags: el, eldiablo, ruby, rubyclr, clr, dotnet, c#, vb