Our team is happy to announce Dynamic Silverlight (DSL), which integrates our DLR dynamic languages with Silverlight. It requires Silverlight 2, which includes the cross-platform CLR and a set of libraries for rich graphics, media and web programming. It is packaged as a Silverlight extension, which means that it is downloaded in addition to Silverlight on an as-needed basis.
DSL has a runtime and an SDK component. The runtime consists of two assemblies: Microsoft.Scripting.dll, and Microsoft.Scripting.Silverlight.dll. You'll also need the language assemblies, which are IronRuby.dll and IronRuby.Libraries.dll for Ruby and IronPython.dll and IronPython.Modules.dll for Python. The runtime component is a small additional download. Today, the IronRuby Silverlight runtime is just a 712KB download, which takes less than 5 seconds to download over modern broadband.
There is also an SDK component to DSL. The piece of software that you'll interact with the most is our local web server called Chiron. Created by John Messerly and Dmitry Robsman, it gives you a very nice interactive development experience using nothing more than your local file system. Let's take a look at Chiron.[1]
Update: Here's a link to the download of the Dynamic Silverlight SDK. The dsl.bat file can be found in the \bin directory of the SDK.
Open up a command prompt and ensure that Chiron is on your path:
Next, use our template generator to create a starter IronRuby Dynamic Silverlight project:
You'll see that we've generated a set of starter files for you. To run this app, type chiron /b on your command prompt:
This should bring up a browser window with the current directory's contents displayed:
If you click on the index.html file, you'll see that the browser fetches a number of files from the server, and displays our Hello, World message:
Chiron prints a list of files that the browser requested. The interesting file is app.xap. This is the way we package Silverlight components for distribution. It's just a ZIP file with a different name. To look at its contents, just point your browser at http://localhost:2060/app.xap, and you'll see that it contains:
This illustrates what Chiron does: it dynamically packages everything that you need to run your DSL application into the XAP and serves it up to your browser. The core DSL runtime pieces and the IronRuby assemblies are in the file, along with all of the other files that we generated in our starter application.
Binaries are listed in the AppManifest.xaml file that Chiron generated for you. You can see how Silverlight 2 boots DSL when you open the file:
The EntryPointAssembly is the DSL 'shim' that connects the DLR to Silverlight. The EntryPointType is the name of the type that Silverlight will run when it starts up. DynamicApplication derives from the Silverlight System.Windows.Application type, which defines the Startup event which is used to bootstrap the DLR.
Next, let's look at index.html. The <object> tag is all that is needed to startup Silverlight. No more external JS files for folks who are familiar with the older Silverlight 1.1 Alpha. The source attribute points to app.xap, and initParams are used to pass initialization data to your program.
Notice the reportErrors = errorLocation parameter. This points to a <div> element that we generated for you. We use this <div> to report runtime errors and their stack traces to you.
This element also has a dependency on error.css to define the formatting for the error messages. I think it's pretty cool that we were able to use the extensibility mechanisms of Silverlight to inject custom DLR error message formatting into Silverlight.
Next, lets look at app.rb:
You'll notice that we just run this script and inject our hello world message into the element tree defined by the XAML:
There's a little bit of magic in layout_root.message.text. The message XAML element is a child of the layout_root element. How does Ruby resolve these references? The answer is found in the required file, Silverlight.rb:
We're adding a method_missing method to the FrameworkElement class and the SilverlightApplication class. So when we try to retrieve layout_root, it delegates to the SilverlightApplication's implementation of method_missing. It dynamically invokes the target passed in m, which invokes the generic method_missing method in FrameworkElement. This gives a very natural feel for 'dotting through' a set of contained XAML elements, which is largely made possible by the Ruby programming language.
I hope this post gives you a feel for what Silverlight programming from IronRuby looks like. In the next part of this series, we'll look at how we can build a more sophisticated application that uses network stack, JSON, flickr, and some funky animation as well.
[1] The fine print:
There's still some work that we have left to do before we can push the sources and bits out. The code is baked, but packaging this stuff still takes some time. Check back here on Friday, the day of my talk at MIX (you are going, right?), and you'll have some bits that you can use to follow along with this tutorial.
Update: Here's a link to the download of the Dynamic Silverlight SDK.
You'll also need to have a working install of CRuby to run some of our utilities. I recommend the Ruby one-click installer for Windows. This will be fixed in the next release of IronRuby.
