Articles tagged 'dotnet'

RubySharp Aug 22

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:


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}",

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!"

def get__author
return "El Draper"

def work
puts "This is coming straight from my Ruby written add-in!"

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:


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: , , , , , , ,



My first real contribution to project RIDE-ME, the add-in architecture, is now in the trunk of the source tree. Check it out, comment, submit patches or let me know feedback. I’m pretty pleased with it, and it should foster some nice add-in development hopefully :-)


For all these times, that we walked away Jul 14

Bit of a catch-up here, as it’s been far too long since I blogged:

  • England are out, and the World Cup is over. The first event left me feeling raw anger towards the Portuguese (who over the years have given me plenty to be pissed about). The second was a rather bittersweet event. On the one hand, I’d far rather see neither France nor Italy win it, but out of the two I would have to have reluctantly picked the aging French surrender monkeys, rather than the greasy match-fixing Italians, to have won it. But the Zidane incident made the entire thing worthwhile, it was pure enjoyment seeing him getting his marching orders, with the classic shot of him leaving the field yards away from the World Cup trophy, combined with the fact than an Italian was for once legitimately polaxed.
  • I got me SkyHD installed, and it is sw-eeeet. I can now watch HD sporting events, movies, and other assorted goodies (including alsorts of random documentaries, which I’d never usually watch except for the fact that it’s in HD). The box itself is sleek and chic, and bar a couple of random lock-ups last couple of days, has behaved excellently for a first generation piece of equipment. Oh, and the Sky+ PVR system is fantastic, I forgot how much I missed being able to setup entire series to be recorded with a couple of remote clicks.
  • I’m wrapping up the add-in architecture for RIDE-ME. I hope to have it in my branch by the end of this weekend, and then merge it over after then to trunk. We can then test the hell out of it, while the other guys start to write whatever add-ins they can dream up. Eventually, in the 1.0 release, it’ll see the light of day, and we hope to build a nice add-in community around it. Oh, and I’m now hosting all of the resources for the RIDE-ME project.
  • Did I mention HD? I’m currently watching Die Hard With A Vengeance apparently in HD (didn’t even realise HD cameras were around back in ‘95), and Bruce Willis never looked so good.
  • I’ve been having a lot of fun with the object/relation mapping framework I’m working on at the minute, integrating it tightly with the model-view-controller framework I knocked together. It’s starting to come together, and I’ve just implemented associations in queries (read: joins). I’ve got a reason for putting all of this together, and that reason is almost ready for the big-time, so watch this space…
  • I’ve ordered a SleepTracker watch, but there’s no stock at the minute so I gotta wait.
  • The new Rise Against album is fantastic, along with the latest albums from Billy Talent and Lostprophets, expect reviews soon
  • RubyCLR is superb, I think John Lam might be a genius
I think that’s mostly it believe it or not, so peace out for now.


DotNetKicks... Jun 28

is a Digg like clone, centered around .Net content. Useful resource for .Net developers.

Technorati Tags: , , , , ,


Get offensive like Tet Jun 28

Interesting article from Ted Neward, starting with an interesting analogy, segwaying into a brief history of the Vietnam war, and ending up with the crux of the article being about object/relational mapping, the black art of mapping objects to relational database tables. Interesting concepts and ideas, I’m still reading and digesting much of what the article has to say.

While I’m linking like a link-whore this evening, DHH finally blogs about his ActiveResource sweetness committed to the Rails trunk the other day. His post includes the slides from RailsConf, and the entire concept sparks a load of potential ideas off with me.

Technorati Tags: , , , , , , ,


Plug In Baby Jun 27

Here’s a good post from Phil Haack about plugins, and making a plugin architecture resilient to versioning. He presents some good ideas, some stuff worth thinking about in there. I’m thinking about and working on plugins loads at the minute, including working on an add-in architecture for Project RIDE-ME. Reading this post though made me start to question some of the terminology, where a lot of the time I’m using “plugin” out of context. The way I now see it, there are plugins, add-ins, and providers. I’m about to refactor a bit of code I’ve been working on, as it is effectively a provider system, for database and logging providers, however I’ve referred to it throughout as plugins, and I feel this is now slightly out of context…

Plugin: something fairly generic, to be able to “plug in” new components to change almost any aspect of an application
Add-in: something that is contained, used more within rich user interfaces to provide a specific bit of UI content or functionality, much more refined than a general purpose plugin
Provider: some kind of general functionality such as data querying, logging, that can be achieved against different sources, hence the need for differing providers

This is now how I’m starting to formalize some of the terms above, and while almost all of the reflection code remains the same regardless, the design of the architecture depends heavily
on which of the above you are trying to achieve.

Technorati Tags: , , , , , ,


Rail Riding Jun 9

So I came across what looks to be a nice little Windows based Ruby on Rails IDE - RIDE-ME. It’s written in .Net which is cool, and while still in its early phases, seems to be looking quite nice. Also, they are looking for C# developers to join the fold and help out, so with my experience in C# programming, and my almost unhealthy interest in Ruby and Rails, I feel compelled to contribute!

Haven’t posted much recently, but there’s a few things I’ve got that I want to post when I got more time, so hopefully over the coming weekend I’ll get it done.

Technorati Tags: , , , , , , ,


Intriguing Apr 18

Catching up on some of the weekends tidbits, I noticed RSSBus - this looks quite interesting, and reading through the whitepaper brings up some intriguing ideas - however until I can play with the actual product, I’m not sure how useful it’ll actually end up being. Not sure I count as an “early adopter” or “influencer” either ;-)

Technorati Tags: , , , , ,


Building blocks Apr 10

So before I get cracking with a few ideas I’ve got going on, I wanted to get my base framework and build environment sorted. After taking xFramework offline and turning all of the useful code I wrote into a more condensed, useful set of libraries, I then decided to work on a few build tools.

First up was to refine the unit-testing libs and console tool that was part of xFramework. Re-named, and re-built, I made it leaner and faster. Previously, there was one core library - this was the same one the console tool used to execute tests, and the client library containing the unit-tests referenced to tag unit-test classes. Now, it’s two separate libraries - a client framework lib referenced to mark up unit-test classes with attributes, and a console tool with core library (and a reference to the framework lib) to execute unit-tests themselves.

Secondly, I wanted a build server. I searched a while back, and came up short. There are plenty out there, but the criteria I’m after is:

  • Automated build setup, with an easy-to-use configuration structure
  • Plugin interface for a totally extensible build and reporting process
  • Cross-platform, runs on both Linux and Windows, and preferably Mac OS X too
This is the basics of what I wanted, but it’s a start. Anyway, I decided a while back I’d write my own, and got a way through it before more important stuff took precedence. This time, I decided to stick at and get it done. I started from scratch, only referring to the code I wrote previously for a couple of things, more as a source of comparison. I now have a fully extensible build system, which so far has the ability to:
  • Checkout a working copy from a Subversion repository, either using the “file” or the “svn+ssh” protocol. I’ll write further SCM support as and when I need it.
  • Build the project, so far the only supported plugin is an MSBuild plugin, for building MSBuild project files such as Visual Studio 2005 solutions and projects (of course the API should be fairly similar to the XBuild tool for Mono, which was a port of MSBuild, and I’m thinking about a NAnt provider somewhere down the line)
  • Run some code metrics, so far just a simple line counter for each file meeting the configured criteria, and a total line count
  • Run unit-tests on the code, using my unit-testing framework, and a bridging plugin for the build system
  • Generate some documentation, using my own documentation engine (see below)
  • Cleanup after itself
All of this can be done using a series of plugin schedulers, also extendable to provide further scheduling options, however currently providing hourly and daily schedulers, aswell as a run once scheduler (runs immediately, once only) and a continuous build (building over and over) for testing. Eventually I plan to write a scheduler that queries the source code system for updates, thereby turning it into a continuous integration build system too.

Now that this is done, and tested, there are a few other plugins I want to write for it, but on the whole it’s good enough for me to develop with now. The build reports are also extendable - an interface is defined so that plugins can be written to deal with the build report, and so far I’ve written one provider that saves this report to file, and one that mails it to me, both of which I use. This means I now have my project building nightly, with everything automated, and me being notified of the results.

The third and final tool I’ve written, is a documentation engine. This came about purely because I tried writing an NDoc documentation plugin for my build system, to no avail (it didn’t like my .Net 2.0 assemblies). I browsed around, and found two things: 1) there is little or no activity currently occurring on the NDoc project, and 2) a few users are starting to modify the source themselves to provide a source distribution of NDoc with support for .Net 2.0. I took one look at the Xml documentation files that the C# compiler outputs (the ones that NDoc uses) and decided instead of using unsupportable, possibly unreliable user hacks to get my documentation needs accomplished, I’d write my own little engine, and in this way I’d get exactly what I needed. And so my third development tool in my toolchain, a core library defining a plugin interface for document generation, was born. It allows project files to be configured (defining the Xml document input files to use), and it allows plugin documentation generators that handle the actual output - I wrote one simple plugin to provide Html output for now, more advanced output could be Linux style man files, a Windows style help system, MSDN docs, or a multi-page Html documentation web site solution (currently it chews out one Html file, using JavaScript to allow expanding/collapsing of elements). I have written a console tool to build documentation from the project file, and of course the build server plugin is used to generate documentation directly from within the automated build process.

I now have an end-to-end build process, which, while some tweaking and a bit more code writing is necessary, does the job more than adequately for me. I feel far more confident going on to build upon a lot of my ideas, knowing I have the building blocks in place to write and develop applications more reliably.

Technorati Tags: , , , , , , , , , , ,


Ooh, embarassing Apr 10

Hows that for cross-browser compliance? Just realised (thanks to my bro) that when viewing this very blog using Internet Explorer it appears it was asking users to download the page as a file. This will be down to the work I was doing on accept types and content types a while back, and it must have snuck by my rigourous multi-browser regression testing system ;-)

Anyway, one quick fix later and even IE users can see the content now :-)

Technorati Tags: , , , , ,


Muby, or Ronad Apr 6

Two interesting points of view on a debate between two technologies that I didn’t think could be so comparable - Monad (MSH), and Ruby. Ted Neward puts forward his case for using Monad, because of its scripting ability, and provides some interesting usage of the scripting syntax to back his views up. Glenn Vanderburg says he’s sticking with Ruby however, and goes on to explain why, cleverly writing the same script that Ted did using Monad, in Ruby - just 17 lines of code, instead of 37 using MSH. Both posts are worth a read, however my opinion? I think Ruby has my vote all the way - it’s cross-platform nature, and the fact that it is a dedicated scripting language (rather than a shell with a neat syntactical scripting language to back it up) are really winning points for me. After all, I’d be happy combining Ruby with Rails to write a fully-fledged web application - but besides utilities/maintenance scripts, I don’t give Bash a run out very often. In the same way, I think at first people may say “look at how cool Monad is, look at what it can do!” but in the long-run, it’s use will be relegated to command line oriented tasks, and the “real code” will be written with languages like Ruby. My $0.02 on an interesting topic of conversation.

UPDATE: it looks like the original script in Ted’s article actually originated from a post by Lee Holmes - and since the debate, he has re-written the script, matching the Ruby version almost line for line - I guess that blows the whole lines of code argument out of the water then. Really it just comes down to what you are trying to write - in this case there’s not a lot between the two, however in other projects there may be a clear advantage to using one or the other. I’m happy to have both at my disposal :-)

Technorati Tags: , , , , , ,


Stick this in yer pipe Apr 3

A great demo of the power of the ASP.NET processing pipeline.

Technorati Tags: , , ,


Page 1 of 1 |