An IronPython Silverlight Application

The Structure of a Dynamic Application

The Silverlight Image Snipper Sample

... note:

These examples show how to create IronPython Silverlight applications using an ``app.xap`` to bundle the application. An alternative technique, that doesn't require a xap file and uses the IronPython binaries from a Microsoft content delivery network, is called `Gestalt <>`_.

Structure of a Silverlight Application

A basic Silverlight application consists of the following parts:

  • HTML file - the webpage that embeds the Silverlight control

  • 'app.xap' - The application. A zipfile containing:

    • - your main Python file
    • The IronPython assemblies (dlls)
    • A XAML (XML) manifest file
    • A language.config file
    • Any additional Python modules, XAML files and assemblies your app uses

With Silverlight we can create a dynamic application with just a web page and a 'xap' file. Creating these 'xap' files is made simple with the use of Chiron. Chiron is a tool for packaging dynamic applications, and it can also serve applications from the filesystem whilst you are developing them.

Chiron, along with IronPython for Silverlight, is in the zip file distribution of IronPython from

If you're in a hurry, you can skip this page and just use the simple examples from the next article:

If you want to understand what you're working with, then read on...

Embedding the Silverlight Control

Embedding a Silverlight control in a webpage is straightforward. Here is a typical example that displays the 'Get Microsoft Silverlight' link and image if Silverlight is not installed.

<object id="SilverlightPlugin" data="data:application/x-silverlight,"
 type="application/x-silverlight-2" width="450" height="540">
  <param name="source" value="app.xap"/>
  <param name="onerror" value="onSilverlightError" />
  <param name="background" value="#FFFFFF" />
  <param name="initParams" value="debug=true,reportErrors=errorLocation,exceptionDetail=true" />
  <param name="windowless" value="true" />

  <a href="" style="text-decoration: none;">
    <img src=""
     alt="Get Microsoft Silverlight" style="border-style: none"/>
<iframe style='visibility:hidden;height:0;width:0;border:0px'></iframe>

The 'onerror' parameter is Javascript functions to be called in the event of error. The one we use here is a Javascript function defined by the dynamic languages SDK that nicely formats tracebacks for us.

The reportErrors parameter in the Silverlight object tag specifies the id of a location for errors to be reported:

<div id='errorLocation' style="font-size: small;color: Gray;"></div>

The 'xap' File

The 'xap' file is really just a zipfile which you can construct manually or can be autogenerated for you by Chiron. The command line magic to make Chiron create a 'xap' file from a directory is:

Chiron /d:dir_name /z:app_name.xap

If you are running this on the Mac (requires OS X and Mono), then the command line will look something like this:

mono bin/Chiron.exe /d:dir_name /z:app_name.xap

More importantly, you can use Chiron to test your application from the filesystem, without having to create a 'xap' file. If your application is called 'app.xap' then your application files should be kept in a directory named 'app'. Chiron will act as a local server, and dynamically create the 'xap' file when the browser requests it. The command to launch Chiron as a webserver is:

Chiron /w

By default this serves on localhost port 2060.

The XAML Manifest File

The way that Silverlight knows an application is dynamic is through the manifest file. This is an XML (actually XAML) file contained in the 'xap' file.

If you aren't using any assemblies beyond IronPython (or IronRuby) then you can just use the following, or let Chiron generate the manifest file for you:

<Deployment xmlns=""
  xmlns:x="" RuntimeVersion="2.0.31005.00"
    <!-- Add additional assemblies here -->
    <AssemblyPart Source="/deploy/Microsoft.Scripting.ExtensionAttribute.dll" />
    <AssemblyPart Source="/deploy/Microsoft.Scripting.Silverlight.dll" />
    <AssemblyPart Source="/deploy/Microsoft.Scripting.Core.dll" />
    <AssemblyPart Source="/deploy/Microsoft.Scripting.dll" />
    <AssemblyPart Source="/deploy/Microsoft.Scripting.Debugging.dll" />
    <AssemblyPart Source="/deploy/IronPython.dll" />
    <AssemblyPart Source="/deploy/IronPython.Modules.dll" />
    <AssemblyPart Source="/deploy/Microsoft.Dynamic.dll" />

XML manifest files makes Silverlight applications fit for the enterprise...

The dlls listed there are part of the Dynamic Silverlight SDK, and will be included in your manifest file automatically by Chiron. It is interesting to note the EntryPoint attributes in the 'Deployment' element. This is how Silverlight knows how to execute a dynamic application - and in fact a dynamic application is just a normal C# application as far as Silverlight is concerned. It is the Microsoft.Scripting.Silverlight that does the magic for us.

To use additional assemblies in your applications, beyond the standard ones that are part of Silverlight, they need to be included in the manifest. Some of the fancy new controls for Silverlight are actually provided as external assemblies (with sources and tests!).


As well as a manifest file the xap must also include a languages.config file. This tells the dynamic language runtime how to execute Python code:


Your Python Application

If your Silverlight app is written in IronPython, then you will need to include at least one Python file (plus any you import of course) in your application. For Silverlight to find it, the main script must be called (or app.rb for IronRuby or app.js for managed JScript). The next article looks at how to create the Python file:

For buying techie books, science fiction, computer hardware or the latest gadgets: visit The Voidspace Amazon Store.

Hosted by Webfaction

Return to Top

Page rendered with rest2web the Site Builder

Last edited Sat Aug 14 14:34:17 2010.