AgDLR 0.5


I mentioned yesterday that it looked like a new release of AgDLR was eminent and sure enough here it is. There are some really cool new features including Silverlight 3 Transparent Platform Extension support, In-Browser REPL and In-Browser testing of Silverlight apps. As with IronRuby 0.3, Jimmy has the a summary of the new AgDLR release.

One feature of the new release I did want to highlight was XapHttpHandler because I’m the one who wrote it! 😄

The Silverlight versions of IronPython and IronRuby ship with a tool called Chiron that provides a REPL-esque experience for building dynamic language Silverlight apps. John Lam had a good write-up on Chiron when we first released it last year, but basically the idea is that Chiron is a local web server that will auto-generate a Silverlight XAP from a directory of Python and/or Ruby files on demand. For example, if your HTML page requests a Silverlight app named app.xap, Chiron automatically creates the app.xap file from the files in the app directory. This lets you simply edit your Python and/or Ruby files directly then refresh your browser to get the new version without needing an explicit build step.

The problem is that, unlike IIS and the ASP.NET Development Server, Chiron doesn’t integrate with ASP.NET. So it’s fine for building Silverlight apps that stand alone or talk to 3rd party services. But if you want to build a Silverlight app that talks back to it’s ASP.NET host, you’re out of luck. That’s where XapHttpHandler comes in. XapHttpHandler does the same exact on-demand XAP packaging for dynamic language Silverlight applications that Chiron does, but it’s implemented as an IHttpHandler so it plugs into the standard ASP.NET pipeline. All you have to do is put the Chiron.exe in your web application’s bin directory and add XapHttpHandler to your web.config like so:

  <!--remaining web.config content ommitted for clarity-->
      <add verb="*" path="*.xap" validate="false"

The new AgDLR drop includes a sample website that shows XapHttpHandler in action.

Quick note of caution: by design, XapHttpHandler does not cache the XAP file – it’s generated anew on every request. So I would highly recommend against using XapHttpHandler on a production web server. You’re much better off using Chiron to build a physical XAP file that you then deploy to your production web server.


Hi Harry - A few questions :) ... 1) Is Chiron restricted to IronRuby/Python or is it extensible somehow? (saw it in DLR sources but ignored so far) 2) When the XapHttpHandler references it, is it forced to go out of process? Is that the only way to build Silverlight assemblies from within a .NET process, or are there alternatives? (separate appdomain maybe). 3) Related to (2), what kind of performance overhead is there? Caching or not, I'm curious about any out-of-process hit... For some projects I'm working on, I've been kicking around the idea of dynamic server-compiled DLR assemblies (but using custom stuff instead of IronRuby/Python). It'd be interesting to know what options I have :o) Any suggestions / ideas appreciated!
@Chris: 1. Chrion is extensible in that you can add dynamic languages and change the default AppManifest.xaml file that gets generated. Check out Chiron.exe.config for more information. 2. No, when you use XapHttpHandler you're loading Chiron as a library - yes, even though Chiron's an EXE. It's kinda wierd, but the only difference between a managed DLL and EXE is the inclusion of an entrypoint in the EXE. 3. Given that it's only recommended for use in your dev environment, I haven't done any perf testing on it at all. If you needed something faster, you could always take the source code and make your own improvements. Good luck with your project. I'd love to hear more about it when you get a chance.