SL runtime assemblies vs. SDK assemblies - in moonlight
最近Moonlight 2.0でWCFまわりの面倒を見てくれと頼まれて、dblinq/L2SQL方面がいじれないなあっていうかnunitテストが落ち着かなくなるなあ…とか思いながら、moonlightの開発に混ざっているのだけど、少々面倒くさい話が出てきてしまった。
Silverlight2には、ランタイムに含まれるアセンブリの他に、SDKに含まれるアセンブリがある。これらのSDKアセンブリを使ったアプリケーションは一度もいじったことがなかったので（というかmoonlight立ち上げ当時にちょっと関わった程度で、Silverlight自体ほとんどいじっていなかったりして）、その位置付けも対象ランタイムも全く知らなかったのだけど、どうやらこれらはアプリケーション作成時に参照することができて、xap作成時にはアプリケーションに同梱されるらしい。ランタイムは出来るだけ小さくなるようにしているんだから、誰もが使いたいわけでもないSDKアセンブリについては、ダウンロードさせるコストは開発側が負ってちょうだい、というわけだ。
SDKのアセンブリには、たとえば以下のようなものが含まれる。
- System.Xml.Runtime.Serialization.dll
- System.Xml.Linq.dll
- System.Json.dll
- System.Runtime.Serialization.Json.dll
- System.ServiceModel.Syndication.dll
- System.Data.Services.Client.dll
- Silverlight Controls
で、このモデルはSilverlightだと問題なく動くのだけど、Moonlightに持ってくると話がややこしくなる。一番困るのは、System.Xml.Linq.dllやSystem.Xml.Serialization.dllといったものについては、.NET（正確には違うけど）の実装をMono（の2.1プロファイル）の上で動作させなければならなくなるところだ。これらはAPIではなく実装なので、少なくとも共働するようには作られていない。
この辺を摺り合わせるのは面倒なので（特にわたしはAPIを越えた実装の違いを吸収する作業にあまり積極的ではないので）、dllmapみたいなものを作ってMSアセンブリはMonoアセンブリで実行するようにしてしまおうかという案もある。しかし、いつまでそれが続けられるかは分からず、やっつけ以上のアプローチにはならない可能性も小さくはない。
かといって、じゃあ実装の違いは吸収するようにしましょうとかいう話になると、上記のアセンブリリストを見てもらえると分かるかもしれないけど、Silverlight Controls以外は全部XMLとWCFまわりで、要するに全部僕のところに降ってきてしまう(w 出来る限りそういう不毛な作業はやりたくない…というかそんなことをしていたらL2SQLを含め、他の作業ができなくなる。（L2SQLも死滅説の僕が作業を引き継いでいるというのは何とも皮肉である。）
さてどうしたもんだか。困った困った。
