Introduction

IronPython is a great way to use the .NET framework. It comes packed full of Python dynamic goodness. Unfortunately it isn't perfect. One noteworthy hole in the IronPython .NET integration is attributes. You can't use attributes in IronPython, which can sometime be a problem.

The normal way round this problem is to create stub C# classes with methods that you can override in IronPython. This doesn't always work though; sometimes you want to dynamically specify the arguments to the attributes - which can only be done at compile time with C#.

This article explores a way round the problem, with a solution that potentially has many other uses. It provides a way to dynamically compile C# source code into assemblies. These assemblies can be used in memory or saved to disk.

Compiling C#

This code uses the System.CodeDom.Compiler API, along with Microsoft.CSharp.CSharpCodeProvider:

It exposes a single function called Generate. The arguments to the Generate function are as follows:

• code

  The C# source code as a string.

• name

  The name for the generated assembly (not including '.dll' which will be added automatically if you are saving assemblies to disk).

• references (optional)

  If your code uses any assemblies outside the standard .NET framework then you will need to provide a list of references. These should be absolute paths to the referenced assemblies.

• outputDirectory (optional)

  If you want to save the assemblies to disk then provide an ouput directory as a string. If inMemory is False (the default) and you don't supply a directory then the current directory will be used.

• inMemory (optional - defaults to False)

  Set to True if you want assemblies generating in memory rather than saving to disk.

  If this argument is False then Generate returns the path to the saved assembly. If True, Generate returns a reference to the assembly in memory.

Using Generate

Using Generate is very simple. I'll use as an example the Screenshot Code from my Windows Forms tutorial. This code uses the DllImport attribute to access unmanaged code from GDI32.dll and user32.dll.

The following code shows the C# embedded in IronPython as a string. This is then compiled to an in memory assembly and imported into IronPython. The static methods are then called in exactly the same way as if the assemblies had been referenced from disk:

Note that this code calls Generate to create the assembly, and then adds a reference to the assembly using clr.AddReference. The important lines are:

Having added a reference to the assembly, you can then import directly from the 'UnmanagedCode' namespace as usual. In practical use the C# source code could also be dynamically generated, making all sorts of things possible.

If you run this script from the command line then, depending on what you have in the top left of your screen, you should see something a bit like:

Subclassing in IronPython

This is all very well, but it still requires writing classes and methods that need to be marked with attributes in C#. What if you really want to write your code in IronPython?

Fortunately that is still easy - you can create a stub class that can be subclassed in IronPython.

The following example C# creates a class with a method both marked with 'SomeAttribute'. 'method' takes two integers and returns a string. We make the method marked with an attribute call another method that is virtual, meaning that it can be overridden from IronPython.

using something;

namespace withattributes
{

    [SomeAttribute]
    class public Class
    {
        [SomeAttribute]
        public string method(int arg1, int arg2)
        {
            return realmethod(arg1, arg2);
        }

        public virtual string realmethod(int arg1, int arg2)
        {
            return "";
        }
    }
}

When you compile this with Generate, you can then import Class from the withattributes namespace:

SubClass still has the attribute on method, but your IronPython code is executed when it is called. Obviously you must observe the types of arguments and return values or .NET gets very unhappy.

Now this isn't the most memory efficient way of doing things. Especially if you are generating a lot of small assemblies - we create an assembly and the type objects every time. Speed is not so much an issue though, this compilation executes much faster than you would expect.