After mucking with your PATH, you should create a key file like this:

sn -k personality.snk
[download]

The first think you will notice when you run an example with the .NET framework is that it is terribly slow. A simple 'Hello World' takes about three seconds to run every time. It seems obvious to me that this thing was not written for quick one-liner-like execution, so be warned. Copy the following hello.cs file and compile it:

 using System;
using System.Reflection;
[assembly:AssemblyVersion("1.0.0.0")]
[assembly:AssemblyKeyFile("personality.snk")]

namespace HelloDot {

  public class HelloWorld {
   public HelloWorld(){
    //no param constructor for COM

   }
   public void SayHello(){
     Console.WriteLine("Hello from DOT NET");
   }
  }
}
[download]

Anyway, you need to compile this into a .dll like so:

csc /t:library /out:hellodot.dll hello.cs
[download]

If the .dll compiled okay you now have to register it:

 gacutil /i hellodot.dll
[download]

regasm hellodot.dll
[download]

perl -e "use Win32::OLE; $hl = new Win32::OLE('HelloDot.HelloWorld') o
+r die $!; $hl->SayHello();"
[download]

You may read from various online sources that it is unncessary to load the assembly into the GAC for you to call it as a COM component, but this does not (at least for me) seem to work. Without registering in the GAC I had to copy the .dll to the Windows/System32 directory just to get it to work for the Window's Scripting Host. Win32::OLE simply could not find the bugger until I registered it in the GAC.

Summary:
 
Are you are asking yourself, "why is any of this important?" Well, it seems that the only other way to get Perl on Windows to interact with .NET is to pony up cash for Visual Studio.NET and Visual Perl. The above tutorial offers a (relatively) quick and (depending on your threshold) painless way to interoperate with .NET components.