Managing IIS configuration using Ruby

I know, this is a dead place. Unfortunately, I just can’t seem to find the time to put more time into this blog… at least at this time. Anyway, the thing that is stealing most of my “free” time made me do some experiments that I thought were worth sharing.

Since quite some time now I’ve been pretty interested in that awesome programming language called Ruby — they say it’s a .Net developer disease :-), but I don’t know if that’s true. After having read a few books on the topic (on my trustworthy iLead) and some fiddling around with irb, I decided to get some “real” hands-on. So I started with a minimal-near-to-flat-learning-curve-project and migrated my build scripts to Rake (using Albacore). Bye bye XML-based build scripts!

Then I thought, why not add some deploy stuff to my build? And so I began investigating the possibilities to configure IIS (7.5) with Ruby (and Rake) which lead me to creating my first ruby library ‘inetmgr‘! You can read more about it on the inetmgr about page.

Exposing Generics to COM (or Scripting)

While COM or scripting is probably not his/her number one development environment, these days, one still has to deal with it from time to time. Recently I had to and ran into a real annoying problem…

During the refactoring of some base classes, I decided to create a generic (an IList<T> implementation, actually) base class for all collections of the system. No big deal, you’ll think. I thought so as well, until I noticed that all (and there’s quite some left) legacy scripting was no longer able to call even the simplest member like Count. The class instance was somehow recognized, but pretty much useless.

Oops, my mistake, I should have thought about this… COM is interface based and knows zip about generics. Of course unit testing didn’t bring my attention to it either. Anyway, I needed to solve it, fast and hopefully without too much rework (certainly not the scripting stuff!). Luckily there’s a pretty simple way to get this done.

First you tell .Net NOT to generate a class interface (by decorating the class with the ClassInterfaceAttribute attribute) for the class.

The second step is to explicitly implement a (non generic) interface that matches the COM/scripting requirements. Here’s an example:

[ClassInterface(ClassInterfaceType.None)]
public class FooCollection : CollectionBase<Foo>, IScriptCollection
{
   // ...
   int IScriptCollection.Count { get { return base.Count; } }
   // ...
}

[System.Runtime.InteropServices.Guid("7C1E3524-7118-427d-9669-E29A9C9DBACE")]
public interface IScriptCollection
{
   // ...
   int Count { get; }
   // ...
}

You can know call Count from COM as much as you like. Of course this is far from ideal if you have many of these (members and/or classes), fortunately, my concrete classes were being generated, so all I had to do was change a code template and regenerate.