Managed JScript/ Microsoft Dynamic Languages
JScript is Microsoft's version of JavaScript (technically ECMA Script 3.0) which runs in Internet Explorer. Managed JScript (as compared to JScript.NET) is the version of JScript available in Silverlight which is designed to take advantage of the DLR.

Dynamic languages have many devoted supporters, as do statically typed languages, and rail cars of ink have been spilled discussing the relative merits of each. The question of which one is better for creating your RIA is rendered moot because existing dynamic language supporters do not need to switch to C# or Visual Basic.NET in order to create a Silverlight application. As can be seen from the sample applications discussed in this article, it is possible to create Silverlight applications using exclusively one of the Microsoft dynamic languages.

Most interestingly, two of Microsoft's dynamic languages are Open Source. Both IronPython and IronRuby have been released under the Microsoft Public License.

The source code for IronPython is available at CodePlex. The source code for IronRuby is hosted on Rubyforge. Since Managed JScript is not Open Source, only the binary files (Microsoft.JScript.Runtime.dll and Microsoft.JScript.Compiler.dll) are released. The location of the latest versions should always be available from the Silverlight Dynamic Languages SDK site on CodePlex (discussed below).

Silverlight Dynamic Languages SDK
To provide developers with the tools which they would need to use Microsoft dynamic languages for building Silverlight applications, Microsoft created the Silverlight Dynamic Languages SDK. Version 0.4.0 was released in mid-October 2008. It has four main components: the Dynamic Language Runtime (DLR), assemblies for IronPython, IronRuby and Managed JScript, Chiron (a tool for creating .xap files for dynamic language applications, discussed below) and Microsoft.Scripting.Silverlight.dll which provides the integration between Silverlight and the DLR. It also includes a number of sample applications written in each of the three supported dynamic languages.

Dynamic Language Runtime
The Dynamic Language Runtime (DLR) is a critical element for dynamic language applications running under Silverlight. The DLR is a common substrate for all of Microsoft's dynamic languages that provides them with code generation capabilities, efficient method dispatch, name lookup and debugging support. Most importantly, the DLR is what enables Microsoft's dynamic languages to interoperate with the .NET Framework and with each other.

The DLR is contained in two assemblies, Microsoft.Scripting.dll and Microsoft.Scripting.Core.dll. Since neither of these assemblies is included in the Silverlight browser plug-in, it is necessary for a developer to package them with any dynamic language application. This is one of the tasks of the Chiron tool (discussed below).

Chiron
Chiron is a special tool for creating Silverlight application packages (xap files) for projects which use one of the Microsoft dynamic programming languages. Chiron can be used either from a command line or indirectly from Microsoft Visual Studio® 2008 (See figure 4 below). The syntax for calling Chiron from a command line is relatively simple (assuming that the command line current directory is the folder containing index.html and the folders containing the Python/Ruby/JScript file(s) and other assets)

Figure 1. This screenshot illustrates the folder structure for a simple IronPython Silverlight application. In this case the required current directory from which to call Chiron would be U:\clock\.

Figure 2. This screenshot illustrates how to call Chiron with the /b parameter which launches the user's default browser to view the Silverlight application. "Path" is simply an alias for the actual physical path to Chiron.exe.

Note that Chiron.exe is initially found in the bin folder in the Silverlight Dynamic Language SDK along with several other dll files. Generally, moving Chiron to another location is not possible without also moving all of these other .dll files, although a separate path to these support files can be specified in the Chiron config file. Of course, the location or locations of Chiron and its support files can also be added to the PATH environment variable.

Figure 3. This screenshot shows the list of files contained in the bin folder of the Silverlight Dynamic Language SDK. Access to all of these files is required for the proper functioning of Chiron.

While Python and Ruby developers will likely run Chiron from the command line, most C# and Visual Basic.NET developers will probably find it easiest to use Chiron from inside Visual Studio. (See also the section on IronPython Studio, below) Doing so requires setting three parameters in the Start Options of your dynamic language web application. These parameters can be found in your application's property pages on the Start Options page.

Figure 4. This screenshot points out the required Start Options which must be set in order to use Chiron from Visual Studio.

By default, the "Start action" is set to "Use current page". Unfortunately this will not work in a Dynamic Language project because there is no .xap file available. Creating the .xap file is the responsibility of Chiron, whose path must be specified in the first field as the external program to start when the project is run. The command line argument "/b" tells Chiron not only to start the built-in web server but also to launch the user's default browser to display the project's Start Page. The "Working directory" tells Chiron where to find the data files that it will need to build the required .xap file (i.e., the .py (or .rb) and .xaml (if any) files that make up your web application).

Running the sample projects provided with the Silverlight Dynamic Language SDK simply requires opening the folder containing the file "index.html" in Visual Studio (File / Open / Web Site). Right click the Project node in the Solution Explorer and open the Property Pages. Set the Start Options as described above and press F5 to run the project.

During development (using the /b parameter) the .xap file which is created by Chiron is written only to memory and not to disk. This is convenient because it can speed the performance of the application when testing modifications of the dynamic language code. However, for deployment it is preferable to save the .xap file to disk. This can be achieved by running Chiron from the command line and specifying both the source path (/d[irectory]) and the name to be given to the .xap file (/z[ipdlr]). Chiron will then build the project and include both the DLR assemblies and whatever specific language assemblies are required by your project. If necessary, Chiron will also generate an AppManifest.xaml file.

Figure 5. This screenshot illustrates calling Chiron to create the app.xap file where the project files are located in the sourcepath folder. Of course, both "path" and "sourcepath" are aliases for the actual physical paths which would be required in this case.

IronPython Studio
The Extensibility group for Visual Studio has released a product called IronPython Studio designed to facilitate Python development. IronPython Studio comes in two modes: Isolated and Integrated. This means that a licensed copy of Visual Studio 2008 is not required in order for existing Python developers to use IronPython Studio. In cases of that sort, IronPython Studio can be installed on top of the royalty-free Visual Studio 2008 Shell runtime. Existing users of Visual Studio 2008, on the other hand, can take advantage of the Integrated installation mode.

Sample Applications
Fractulator, one of the sample applications included with the Silverlight Dynamic Language SDK, nicely illustrates an application written entirely in IronPython running in a web browser. This application presents a user with an input box into which he is suggested to type a mathematical expression. Client side IronPython code immediately formats this expression into a user friendly layout, calculates the result of the expression and displays the IronPython syntax which could be used to represent this expression.

Figure 6. This Fractulator screenshot shows a user entered mathematical expression, its formatted equivalent, the formatted calculated result and the IronPython eval expression syntax.

Photoviewer is another SDK sample application built entirely without C# or Visual Basic.NET. Photoviewer performs a flickr search using Ruby and then displays the results using Lightbox, an open source JavaScript project. This application very nicely illustrates the interoperability of Ruby, JavaScript and Silverlight.

Figure 7. This screenshot shows the images returned from flickr from a search for "Tiger". Clicking on one of the images will display a larger size photo. Clicking on one of the numbered boxes at the bottom will display another set of 30 images.

Future Developments (C# 4.0)
Microsoft is currently working on some language improvements which will significantly simplify the syntax required to call dynamic language code from C#. Using a process similar to implicit typing, it will be possible to get a reference to a dynamic object by calling some method or function which returns a dynamic object.

Pseudo Code: dynamic d = FunctionWhichReturnsADynamicObject();
C# 4.0 Example: dynamic doc = HtmlPage.Document.AsDynamic();

The significance of a dynamic object is that the C# 4.0 compiler will not check any method calls on a dynamic object at compile time, thus deferring resolution until runtime. While this is standard procedure for dynamic languages, it is highly unusual for a static language like C#. In all other respects, however, C# will remain a static language. The purpose of this change is to facilitate C# interaction with these dynamic objects through syntax simplification which can be illustrated in the following code samples:

C# 3.x
ScriptObject map = win.CreateInstance("VEMap", "myMap");
map.Invoke("LoadMap");
map.Invoke("SetTitle", item.Title);
C# 4.0
dynamic map = win.New.VEMap("myMap");
map.LoadMap();
map.SetTitle(item.Title);

As you can see, methods belonging to a dynamic object can be called directly instead of through a call to Invoke, passing in the actual method as a string as is currently required. This deferral of method dispatch will extend to field and property accesses, indexer and operator calls as well as to delegate invocations. As we all know, cleaner simpler code is easier to write and less error prone. The mere existence of this project signals the importance which has been assigned to dynamic language development at Microsoft.

Summary
Dynamic language support in Silverlight turns out to be a major benefit for existing Python and Ruby developers because it allows them to write Python and Ruby code for web applications, which formerly required them to write JavaScript. As the Fractulator and Photoviewer sample applications illustrate, it is possible to create Silverlight applications without any C# or Visual Basic.NET code.

On the other hand, for the C# and Visual Basic.NET developer, dynamic language support creates the opportunity for a whole new set of developers to build Silverlight applications, many of which will be open source and available for inclusion in non-dynamic Silverlight applications. Additionally, where it is desirable to provide end users with built-in scripting capability, this can best be achieved via the use of a dynamic language. Finally, since the demise of the HTML DOM and since the need for client side scripting does not appear to be on the visible horizon, further developments in scripting support promised for inclusion in the next release of the .NET Framework looks to make the task of interoperability with scripting languages even simpler than it is today.

Special thanks to Michael Foord for making available to me a pre-publication copy of his excellent book, IronPython in Action. In addition to a comprehensive explanation of IronPython in general—including how to take advantage of the .NET Framework, this book contains a very useful chapter outlining the use of IronPython in Silverlight. The estimated publication date is in early 2009.

Links