IronRuby Journey Update #1 – Establishing The Silverlight Environment

9 במאי 2009

אין תגובות

OK, so I’ve started up my project to port a Silverlight application from C# to IronRuby. The special thing about this app is that it also makes some webservice calls, something that isn’t as obvious as it is in C# – you don’t have the wsdl tool to create the proxy class for you.

Well, Ruby is a fun language to code in so I’m sure that the lack of a few things here and there will not be much of a problem (I’m sure some of you nod your heads with a “yea right” look on your faces 🙂 ).

Step #1

The first thing I needed to do was to be able to use IronRuby with Silverlight. This is done by the agDLR project which is a pack of tools to help you integrate Silverlight and the DLR. agDLR version is currently 0.5 which means it’s still a beta version and hopefully will improve until V1. It currently supports Silverlight 2 and Silverlight 3 beta.

I downloaded it – first task is done!

Step #2

Next I needed to create an IronRuby-driven Silverlight application. Among the agDLR files, there is a tool named SL. This is a command line tool that generates a simple Silverlight application with code files written in the selected dynamic language (Ruby and Python are supported). You will find it under the scripts folder where you extracted the agDLR files. The command line parameters are simple:

sl [ruby|python] <ApplicationPath>

Running it looks like that:

Running agDLR SL tool

After the tool is done, it generates a folder with the needed files to start with:

  • D:\IronRuby\WeatherWidget
    • \app
      • app.rb
      • app.xaml
    • \css
      • screen.css
    • \js
      • error.js
    • index.html

I have the project files ready – step #2 is complete!

Step #3

Trying to browse to the index.html file that sl has generated for us will not take us to where we want. We  will simply hit an error telling us that the silverlight file could not be downloaded. This is because the index.html file looks for app.xap, which wasn’t generated by the sl tool.

This is when the Chiron tool comes to our aid.

In the Greek mythology, Chiron was a very wise and kind centaur (a man-horse combination) and the teacher of many heroes like Asclepius the God of medicine, Theseus the legendary king of Athens and the greatest warrior Achilles.

In 2009, Chiron is a local web server which runs directly from the command line. It dynamically generates the silverlight xap file from your dynamic language code. You can run it by using the server.bat file that is located under the scripts folder. Chiron has various different startup options which you can view if you execute it with the /? switch: server /?.

In order to run the Silverlight project, you need to run server /b from the project directory (which means you need it on your PATH list) or by passing the directory using the /d switch. I went on and created a batch file to start the server automatically from the project directory, the batch file has a single line inside:

d:\IronRuby\agdlr-0.5.0\script\server /b /d:d:\IronRuby\WeatherWidget

So now all I need to do is run my batch file! Running it starts the web server on port 2060 and opens the browser with the directory listing:

Browser after running Chiron

Looking at the command line, you can see what chiron has fetched:

Chiron running

Clicking on the index.html file will show you the default Silverlight application that sl has generated for us. It has a built in console where you can write IronRuby code and see the changes live (awesome!):

Default agDLR silverlight application

OK – the environment is ready! step 3 is done.

Update #1 Conclusion

Well, I’ve got to say, this wasn’t easy. I think that this process of establishing the Silverlight environment revealed the Achilles heel of the current status of Silverlight and DLR languages. The process is not even nearly as intuitive and fluent as the C# process from Visual Studio (this whole post would have been one line if it was a C# tutorial – choose New->Silverlight Application and click OK).

.Net programmers have gotten used to intuitive, rich and fluent work process which obviously will not be what they’ll get with DLR languages currently.

I guess that these issues will improve with time. Currently, Microsoft spends time on the core things and not on the nice-to-have things. After IronRuby, IronPython and the DLR core development is done, Visual Studio integration will follow.

For me, I’m not planning on giving up. I really believe in these languages and the great things they bring to the programming world.

Stay tuned!

All the best,

Share: DotNetKicks | DotNetShoutout | DZone

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *