[MD3]動的言語とSilverLight1.1アルファの関係

DLRを利用する環境として、IronPythonとASP.NET Futures、そしてSilverLight1.1アルファがあることを既に説明しました。今回は、SilverLight1.1アルファとDLRの関係を考えてみたいと思います。4月のMIXで発表されたSilverLight1.1アルファを構成しているアセンブリは、以下のような構造になっています。

SilverLightはブラウザのプラグインとして動作します。そして「coreclr.dll」を起動します。coreclr.dllが、SilverLight用の共通言語ランタイム(CLR)となります。このCLRがWindows用とMacOS X用に用意されるのが、SilverLightの実行環境です。そしてプログラミング言語として、IronPython、Managed JScriptをサポートしています。このプログラミング言語がDLRに対応しているわけですが、SilverLightからDLRを利用する仲介役を果たしているのが、「Microsoft.Scripting.SilverLight.dll」アセンブリになります。このアセンブリを使って、「Microsoft.Scripting.dll」というDLRそのものを活用しています。

もう一度、図のアセンブリの構造を見てください。SilverLight用のCLRの上で基本となるクラスライブラリ(BCLとかFCLｌと呼びます)を利用しているのがわかります。そしてCLRを利用しているということは、アセンブリをロードするのにセキュリティリスクを意識しないわけには行きません。何が言いたいかといえば、SilverLight用に提供されているmscorlib.dllは、通常のmscorlib.dllと異なるアセンブリ識別子を持つということです。このことは、Microsoft.Scripting.dllがキーペアによる署名を持っていることを表しており、IronPython 2.0A2で提供されるDLRはキーペアによる署名を持っていないということを表しています。

よってIronPython 2.0A2のリリースノートに記述されているように含まれているDLRをSilverLight1.1アルファで使用することができないということになるのです。このことを考えていくとDLRとSilverLightのバージョンアップの頻度がどうなるのかな? という疑問を持たざるを得ません。何故なら、以下のような違いがあるからです。

• DLR自体は、ソースコードを公開するオープンソースに近いモデルで開発が進められていく。つまり、フィードバックなどによって素早いバグフィックスが行われていくことが予測できる。
• SilverLightはセキュリティリスクに対応するためにキーペアによる署名を持つ。従って、緊急時のセキュリティ対応以外は、頻繁バグフィックスが行われないのではないかと考えられます。

もちろんDLRに何を取り込むかを決定するのは、Jim Hugunin氏が率いるDLRチームが決定しますから、定期的にSilverLightにもフィードバックが行くと考えれます。その証拠にIronPython 2.0A2のソースコードを見ると、あちらこちらに「 #if !SILVERLIGHT」という記述を見つけることができます。これは明らかにIronPython用のDLRと同じソースコードでSilverLight用のDLRが開発されていることを示しています。このように提供されているソースコードには、色々な情報が含まれていますから、見て調べることによって気がついていない使い方を発見できるかもしれません。

PS:IronPythonの「clr.Use」の使い方は「ClrModule.cs」から見つけました。そして前回のメソッド呼び出しがデリゲートに委譲していることは「CallTargets.cs」から見つけています。