As part of my series on using IronPython with WPF ¹, I built an extension method in C# that does dynamic member resolution on WPF FrameworkElements. The upshot of this code is that I can write win1.listbox1 instead of win1.FindName('listbox1') when using WPF objects from Python or any DLR language. Convenient, right?

The problem with this approach is that the C# extension method gets compiled into an assembly that’s bound to a specific version of the DLR. I recently started experimenting with a more recent build of IronPython and I couldn’t load the extension method assembly due to a conflict between the different versions of Microsoft.Scripting.dll. Of course, I could have simply re-compiled the assembly against the new bits, but that would mean every time I moved to a new version of IronPython, I’d have to recompile. Worse, it would limit my ability to run multiple versions of IronPython on my machine at once. I currently have three – count ‘em, three – copies of IronPython installed: 2.0 RTM, nightly build version 46242, and an internal version without the mangled namespaces of our public CodePlex releases. Having to manage multiple copies of my extension assembly would get annoying very quickly.

Instead of adding a reference to the compiled assembly, what if I could add a reference to a C# file directly? Kinda like how adding references to Python files works, but for statically compiled C#. That would let me write code like the following, which falls back to adding a reference to the C# file directly if adding a reference to the compiled assembly fails.

try:
  clr.AddReference('Microsoft.Scripting.Extension.Wpf.dll')
except:
  import codedom
  codedom.add_reference_cs_file('FrameworkElementExtension.cs',
    ['System', 'WindowsBase', 'PresentationFramework',
     'PresentationCore', 'Microsoft.Scripting'])

Since this technique uses CodeDOM, I decided to encapsulate the code in a Python module named codedom, which is frankly pretty simple. As a shout-out to my pals on the VB team, I broke compiling out into it’s own separate function so I could easily support adding VB as well as C# files.

def compile(prov, file, references):
  cp = CompilerParameters()
  cp.GenerateInMemory = True
  for ref in references:
    a = Assembly.LoadWithPartialName(ref)
    cp.ReferencedAssemblies.Add(a.Location)
  cr = prov.CompileAssemblyFromFile(cp, file)
  if cr.Errors.Count > 0:
    raise Exception(cr.Errors)
  return cr.CompiledAssembly

def add_reference_cs_file(file, references):
  clr.AddReference(compile(CSharpCodeProvider(), file, references))

def add_reference_vb_file(file, references):
  clr.AddReference(compile(VBCodeProvider(), file, references))

The compile function uses a CodeDOM provider, which provides a convenient function to compile an assembly from a single file. The only tricky part was adding the references correctly. Of the five references in this example, the only one CodeDOM can locate automatically is System.dll. For the others, it appears that CodeDOM needs the full path to the assembly in question.

Of course, hard-coding the assembly paths in my script would be too fragile, so instead I use partial names. I load each referenced assembly via Assembly.LoadWithPartialName then pass it’s Location to the CodeDOM provider via the CompilerParameters object. I realize that loading an assembly just to find its location it kind of overkill but a) I couldn’t find another mechanism to locate an assemblies location given only a partial name and b) I’m going to be loading the referenced assemblies when I load the generated assembly anyway, so I figured it loading them to find their location wasn’t a big deal. Note, that typically you’re used to passing a string to clr.AddReference, but it also can accept an assembly object directly.

Of course, this approach isn’t what you would call “fast”. Loading the pre-compiled assembly is much, much faster than compiling the C# file on the fly. But I figure slow code is better than code that doesn’t work at all. Besides, the way the code is written, I only take the extra compile hit if the pre-compiled assembly won’t load.

I stuck my codedom.py file up on my SkyDrive. Feel free to leverage as you need.

A few random thoughts on yesterday:

Though some in the progressive blogosphere disagree, I thought Obama’s inaugural speech was very good. His start, contrasting taking the oath of office “during rising tides of prosperity and the still waters of peace” (as now-former President Bush did ¹) versus taking the oath as he does “amidst gathering clouds and raging storms” really set the tone for the whole speech. With Bush sitting right there – mere feet from the podium – Obama categorically rejected almost every policy of the Bush administration. When they cut to a shot of Bush in the middle, he didn’t seem to be enjoying Obama’s speech very much. In a way, I was reminded of Steven Colbert’s epic performance at the White House Correspondents Dinner a few years ago. Of course, the difference was that Colbert was speaking truth to power while Obama is speaking truth from power.

Speaking of Ex-President Bush (man, I love writing that) I can say a lot of negative things about him, but I will grudgingly commend him on handling the transition. However, it does feel like it’s grading him on a massive curve: “Sure he’s been an abysmal president, but at least he was able to peacefully hand over the reigns of power without fucking that up too.”

I felt sorry for Elizabeth Alexander, the poet who had to speak after President Obama’s inaugural speech. Everyone started heading for the exits after Obama was done. I hope those early exiters could hear Reverend Lowery’s benediction, it was awesome. I realize Reverend Warren was a controversial pick to deliver the invocation – certainly, I’m not a fan – but I respect Obama for being inclusive of all-viewpoints. And while having a quartet with the likes of Itzhak Perlman and Yo-Yo Ma was awesome, I especially liked John Williams’ inaugural piece “Air and Simple Gifts”. But wouldn’t the theme to Superman have been more appropriate? 😄

Finally, I skipped the rest of the pre and post inauguration analysis and commentary other than the Countdown podcast which I listen to on my way to work most days. Frankly, I didn’t need to be reminded of what an historic day it was. Res ipsa loquitur.

As I’ve written before, I originally got the programming bug from a desire to build my own text adventure games. with significant influence from my dad. Now that I’m a father myself, I want my kids to have a similar opportunity, even if they never choose to go into the “family business”.

Of course, the technology has moved on significantly since the days of “You are in a maze of twisty little passages, all alike”. At CES yesterday, Microsoft announced Kodu which I’ve written about before under it’s original name Boku. Kodu came out of Microsoft Research as a tool for teaching kids how to program. The programming language is very visual and iconic and you use the Xbox controller exclusively for all input. Here’s a screenshot:

To demo Kodu at CES, Robbie Bach brought a 12 year old girl named Sparrow up on stage to demo. I showed the video to my kids this morning and they went gaga for it. They’re a little young – Patrick turns 6 next month and Riley turns 4 later this year – but I think they’ll be able to get the hang of it (with a little help from dad). Below is the video of the CES demo, and there are more Kodu videos at On10 (Matthew MacLaurin on Kodu and Watch Kodu in Action).

Personally, I think this is brilliant. I have been eagerly waiting a change to play this with my kids for over a year, so I’m very excited that they’re bringing this to market. Seriously, Halo Wars just got bumped to the #2 slot on my “Most Anticipated Xbox Games of 2009” list.

I’m most interested in how these creations will be shared online. I couldn’t find any details, but Robbie specifically said “And on Xbox Live they can distribute and share those finished games with other people.” Will there be a charge? (“normal” Community Games cost between $2.50 and $10 a pop) How will parental controls affect shared Kodu games? I guess those details will come closer to release.

Here are some technical details on my Nightly Builds solution. I broke them into a separate post because I figured most people are more interested in the actual service than how it’s built.

As you might expect, I built most of the solution in IronPython. All of the download, build, compress and Azure upload code was written in IPy. The one part I didn’t write in IPy was the Azure cloud web app, which I wrote in C#. Jon Udell’s been investigating getting IPy to run in Azure, but I just wanted something quick and dirty (as you can see from the utter lack of formatting) so I decided to use C# instead. Man, were my ASP.NET skills rusty.

As for the IronPython parts, for the most part I’m using external tools for downloading, building and compressing. I use the Source Control RSS Feed to discover recent source code changesets, CodePlex Client to download source from CodePlex, MSBuild to build the binaries, 7-zip to compress the binaries and the StorageClient library sample to upload the compressed binaries up to Azure blob storage.

For building and compressing, I’m literally shelling out to MSBuild and 7-Zip via os.system. I looked at programmatically building via the MSBuild API, but I ran into an assembly binding bug that I wasn’t motivated enough to work around. As for creating zip files programmatically, IronPython doesn’t have a zlib module implementation yet so I just used 7-Zip’s command line utility instead.

For downloading form CodePlex, I originally started by shelling out to CodePlex Client. However, I wanted the ability to cloak folders – for example Tutorial and SrcTests – that weren’t required to build. CodePlex Client has a very useful TFS library embedded in it – the build process combines all the libraries into a single executable via ILMerge. I could have compiled my own version of the TFS library, but instead I just load cpc.exe as an assembly reference via clr.AddReferenceToFileAndPath. It’s a nifty trick Jim Hugunin showed me once.

Uploading to Azure was very straightforward because of the StorageClient library. Here’s the code to create a blob container object (creating the actual blob container if it doesn’t already exist) and to upload a file to a container.

def get_blob_container(prj):
  azure_account = StorageAccountInfo(endpoint, None, azure_name, azure_key)
  storage = BlobStorage.Create(azure_account)
  container = storage.GetBlobContainer(prj.lower())
  if not container.DoesContainerExist():
    print "Creating", prj, "Azure Blob Storage Container"
    container.CreateContainer(None, ContainerAccessControl.Public)
  return container

def upload_to_azure(container, upload_filepath, azure_filename, metadata):
    print "Uploading", azure_filename, "to Azure"
    prop = BlobProperties(azure_filename)
    nv = NameValueCollection()
    for key in metadata:
      nv[key] = metadata[key]
    prop.Metadata = nv

    with File.OpenRead(upload_filepath) as stream:
      contents = BlobContents(stream)
      if not container.CreateBlob(prop, contents, True):
        raise "Uploading " + azure_filename + " to Azure failed"

I’ve been working on some pure IronPython code to access the blob storage REST API directly, but that’s primarily to familiarize myself with the service. At some point, I’m going to want to leverage Table Storage but my brief experimentation with the StorageClient Table Storage interface makes me think that it depends on static typing too much to be useful for IPy. If that turns out to be true, the Table Storage REST API will be my only option.

As you can see in the code above, these Azure blob containers are set to be publically accessible (via ContainerAccessControl.Public argument passed to CreateContainer). So for my C# app, I’m simply using calling XDocument.Load with the List Blobs operation url, shaping the results via LINQ to XML and binding them to nested ASP.NET Repeater controls.

Assuming people find this useful, I’m thinking of some additional improvements, in order of what I’m likely to get to first:

• Caching Project Info in the cloud app
  Currently, I’m hitting getting and processing the list of binary releases on every request. I’m sure caching that data to make it more efficient.
• Virtual Build Environment
  Currently, I’m just building on my laptop. It would be nice to have a clean environment dedicated to running the build script.
• Auto-Build
  My script uses the RSS feed to find the recent checkins, but I have to manually kick off the process. I’d like it to set it up as a service that periodically checks the source code RSS feed automatically and downloads and builds any new releases that it finds.
• Table Storage for Build Metadata
  Today, I am simply grabbing the list of all uploaded compressed binaries for a given project, parsing their names, and displaying that as a hierarchical list on the project page. If I used Table Storage, I could add additional metadata including social software features like ratings and comments.
• Amazon EC2 Virtual Build Environment
  If I’m creating a virtual machine for my build environment, I could look at hosting it on Amazon EC2. They support Windows now after all. Ideally, I’d use an Azure worker role for compiling and compressing builds, but our build tools need access to the file system.

IronPython 2.0 shipped about a month ago, but we’re still chugging along with our post 2.0 work. We’ve shipped seven source code releases since we shipped 2.0 and we should be back to our normal schedule of updating the source 2-3 times a week schedule by next week. Given how often we ship source, we’re thinking of extending the the time between binary drops. Binary releases have to be signed and there’s a fairly arduous process we have to go thru in order to get each binary release out the door.

However, there’s something nice and convenient about downloading a pre-compiled binary release. So I spent my Christmas vacation building a script to download and build IronPython nightly builds. Once built, I compress the binaries and upload them to Azure blob storage. Finally, I built a very simple cloud app for users to view and download available nightly builds. As an extra benefit, I’m also providing nightly builds of the DLR.

Please note, these are *NOT* official Microsoft releases of IronPython and/or DLR. They aren’t signed and they haven’t gone through the aforementioned release process. I’m just downloading the public source, building it with the publicly available tools, then making them available on a a publicly accessible website.

The website for the IronPython (and DLR) nightly builds is http://nightlybuilds.cloudapp.net.

As usual, I welcome any feedback. Is having prebuilt unsigned binaries of IPy releases useful? Do you want IronRuby binaries as well? What about social features (rating releases, comments, etc)? Please let me know what you think.