ページ

2011年5月25日水曜日

[WP7] LongListSelector でちょっとはまった

Silverlight for Windows Phone Toolkit に入っている LongListSelector はお手軽にグループ化したリストが作れて便利ですが、ちょっとはまったので記録として。

もっとも単純な形だと、

public class Book
{
    public string Category { get; set; }
    public string Name { get; set; }
}

こんなクラスがあったとすると、

var books = new Book[] {
    new Book() { Category = "Cat1", Name = "Book1" },
    new Book() { Category = "Cat1", Name = "Book2" },
    new Book() { Category = "Cat2", Name = "Book3" },
};

this.LongListSelector1.ItemsSource = from book in books
                                     group book by book.Category into c
                                     select c;

こんな風にすればグループ化して表示できます。

と思ってたんですが、これじゃダメなんですね。これだとグループヘッダーのところに何も表示されません。
この場合、ItemsSource には System.Linq.IGouping<TKey, TElement> のコレクションを渡していて、Key がグループヘッダー、グループの中身は GetEnumerator() で取得することになります。実際に group by で返ってくるのは IGrouping を実装した System.Linq.Lookup.Grouping クラス(リファレンスには載ってない)なんですが、どうやらこれの Key プロパティとうまくデータバインドできない様子。

Toolkit のサンプルを見ると

public class PublicGrouping<TKey, TElement> : IGrouping<TKey, TElement>
{
    private readonly IGrouping<TKey, TElement> _internalGrouping;

    public PublicGrouping(IGrouping<TKey, TElement> internalGrouping)
    {
        _internalGrouping = internalGrouping;
    }

    public override bool Equals(object obj)
    {
        PublicGrouping<TKey, TElement> that = obj as PublicGrouping<TKey, TElement>;

        return (that != null) && (this.Key.Equals(that.Key));
    }

    public override int GetHashCode()
    {
        return Key.GetHashCode();
    }

    #region IGrouping<TKey,TElement> Members

    public TKey Key
    {
        get { return _internalGrouping.Key; }
    }

    #endregion

    #region IEnumerable<TElement> Members

    public IEnumerator<TElement> GetEnumerator()
    {
        return _internalGrouping.GetEnumerator();
    }

    #endregion

    #region IEnumerable Members

    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
    {
        return _internalGrouping.GetEnumerator();
    }

    #endregion
}

こんなクラスを自前で用意して

this.LongListSelector1.ItemsSource = from book in books
                                     group book by book.Category into c
                                     select new PublicGrouping<string, Book>(c);

と言う風に包んであげています。
なぜそんな事に?

var q = from book in books
        group book by book.Category into c
        select c;
var group = q.First();
var key = group.Key;                                    // ちゃんと Key の内容を取り出せる
var propertyInfo = group.GetType().GetProperty("Key");    // null が返る!

こんな風に試してみました。
System.Linq.Lookup.Grouping クラスは DependectyObject ではありませんから、LongListSelector は内部でリフレクションを使ってデータバインドしてると思います。なので、GetProperty(“Key”) で PropertyInfo が取れないとバインドしようが無いと思いますが、実際に試してみると null が返ってきちゃいます。どうやら Grouping クラスは internal なのでリフレクションでアクセスできない様子。
ちなみに、まったく同じコードを .NET Framework 4 のコンソールアプリケーションと Silverlight 4 で試すとまったく問題なく PropertyInfo が取得できます。Silverlight と WP7 は null になるのかと思ったら、WP7 だけが動作が違うんですね。

分かってしまえばどうということは無いんですけど、ちょっとはまりました。
(というか、最初から public に Grouping クラスを用意しておいてくれたらよかったのに)

2011年5月24日火曜日

[WP7] App Hub のアカウントを作ってみた

HTC 7 Trophy を入手したので App Hub アカウントを作ってみました。
(会社の法人アカウントを作ってみようかと思ってたんですが、とりあえず個人にしました)

最近、公式で手順書が公開されたそうですが、私は今のところ特に問題なく進めることができました。

公式の手順書はこちら
App Hub のアカウント作成手順と注意事項

一部、手順書とは違う(メールが日本語だったり)ところもあるので私の場合を書いておきます。

  1. App Hub でアカウントを作成。私は以前から使っていた Live ID で登録。聞いたところによると、Live ID 作成時の国が「日本」になってないとダメとか、誕生日が 18才以上でないとダメとか、注意点があるそうです(あとから変更してもダメで作成時の情報がチェックされるらしい?)。Live ID 作成時のことなんて覚えてませんでしたが、私の場合は特に問題なく作成できました。
  2. ちょっとしたら App Hub から確認のメールが来ました。これはリンクをクリックしてメールアドレスの確認をするだけ。
  3. それから 1日半後くらいの土曜日の早朝に GeoTrust より「Windows Marketplace for Mobile ID XXXXXX」のメールが到着。私のところには日本語のメールが来ました。身分証明書確認のシートもちゃんと日本語です。

    確認シートの部分をプリントアウト
    ・身分証明書には運転免許証のコピーを使用
    ・「ID 番号」欄には運転免許証の番号を記入。
    ・「有効期限」欄には運転免許証の期限を「201X年X月X日」形式で記入。(文面が日本語になってるんだから日本語表記にしてみた)
    ・「発行場所」欄には「日本」と記入。
    ・「署名」欄には氏名、「日付」欄には当日の日付を「2011年X月X日」形式で記入。
    (以上手書き)

    これをスキャンしてメールに添付して送信。送ったのは GeoTrust からメールが来てから数時間後の土曜日の昼くらいです。
  4. 月曜日の昼に GeoTrust より認証手続き完了のメールが来ました。これもちゃんと日本語です。(締めの言葉は Thank you でしたがw)
  5. その翌日、Microsoft から「Windows Marketplace account notification」のメールが来て無事 App Hub アカウントが作れたようです。

結局、6日間でアカウントの作成はできました。途中に土日を挟まなければもっと早くできるのかもしれませんね。

さっそく、HTC 7 Trophy を繋いで Windows Phone Developer Registration を起動。
App Hub アカウントで Register すると無事登録されました。
Visual Studio から実機に繋いでのデバッグも問題なし!

ところで、今のところ有料アプリを作る予定はないんだけど、EIN の取得と W-8BEN の申請はしておいたほうがいいのかな?

2011年2月14日月曜日

[Silverlight] Silverlight を囲む会 in 大阪 #16 に参加してきた

この間も書いたように Silverlight を囲む会 in 大阪 #16 に参加してきました。
Windows Phone 7 がテーマということで、とてもおもしろかったです。
プログラミング生放送の 5zj さんがニコ生でも生放送してくれていました。2011/02/18(金) 23:59:59 までタイムシフトで見ることができます。(タイムシフトはプレミアム会員じゃないとダメなのかな?)
しょっぱなの私のセッションは Visual Studio とエミュレーターのみですが、他の皆さんのセッションは Windows Phone 7 実機を使ってのセッションです。ぬるぬると気持ちよく動くさまが見れます。

もちろん懇親会にも参加。あー楽しかった。

2011年2月7日月曜日

[Silverlight] Silverlight を囲む会 in 大阪 #16

Silverlightを囲む会 in大阪 #16 に参加します。
今回のテーマは 「Windows Phone 7 のための Silverlight 開発講座」 です。
入門のセッションのスピーカーを担当させてもらいます。
Visual Studio と Windows Phone エミュレーターでどんな感じで開発ができるのかといった、入門的なところを主にして話させてもらうつもりです。

まだ、申し込み受付中のようですので興味のある方はぜひ。

2011年2月5日土曜日

[ブログ] FC2 から Blogspot へデータを移行したときの覚え書き

FC2 にあった記事をここ Blogspot へ移行したときの覚え書きです。

■ FC2 → Blogger
まずは、FC2 ブログの管理ページにある「エクスポート」で記事データをエクスポートします。
このデータはどうやら MT 形式みたいです。MT 形式であれば http://movabletype2blogger.appspot.com/ で Blogger 形式に変換できます。
FC2 からエクスポートしたデータは euc-jp になってるので utf-8 にしてやります。
続いて http://movabletype2blogger.appspot.com/ で Blogger 形式に変換、と思ったらちょっと問題が。

  • 日時がすべて変換した時のものになってしまう。
    これは movabletype2blogger が “02/12/2008 09:03:25 PM” という AM/PM 付きの形式を前提としているのに対して FC2 のデータは “02/12/2008 21:03:25” と AM/PM が無いためです。ちなみに、MT 形式のドキュメントを見ると AM/PM を省略したときは 24時間表記とあったので movabletype2blogger の実装が手抜きなんでしょう。本当ならは movabletype2blogger の方を修正するのが筋ですが、手っ取り早く DATE: のところを AM/PM 形式に変換するプログラムを C# でちょこっと作って対応しました。
  • タイトルがおかしくなったり、コメントにゴミが入る。
    これは MT 形式ファイルのコメントのところにある TITLE、SECRET、PASS のせいで、Blogger 形式にしたときにタイトルがコメントのものに置き換わってしまったり、コメントの中に SECRET や PASS の文字列がそのまま残ってしまったりします。MT 形式の仕様上これらがどういうものなのかは調べてませんが、消してしまえばいいようだったので手作業で削除しました。
  • 記事やコメントの日時がずれる。
    FC2 からエクスポートしたデータは JST なのに GMT として扱われるためです。これは Blogger 形式にしたあとで、<ns0:published> と <ns0:updated> の Z を +09:00 に置換して JST にしてやりました。

これで Blogspot にインポートすることができました。

[ブログ] .Text から Blogspot へデータを移行したときの覚え書き

.Text にあった記事をここ Blogspot へ移行したときの覚え書きです。

■ .Text → BlogML
まずは http://www.divakk.co.jp/blog/aoyagi/ で動いていた .Text (dotText : ASP.NET C# で書かれたブログエンジン。.NET Framework 1.1 のころのもの) を BlogML 形式に変換。
BlogML というのはブログデータの形式のことです (ファイル自体は XML)。
.Text、Community Server、Subtext、BlogEngine.NET、DasBlog といった .NET 系のブログエンジンでサポートされていることが多いみたいです。(私は今回初めて知ったので詳しいことはわかりません)

変換には http://www.johnsample.com/ のツールを使わせてもらいました。ソースも載っていますしバイナリもダウンロードできます。このソースでは BlogML 名前空間のクラスを使っていますが、それは http://blogml.codeplex.com/ にあります。

■ BlogML → WXR
続いて BlogML 形式を WXR 形式にします。
WXR 形式は Wordpress が使っている形式です。
BlogML から WXR への変換は Importing BlogML into WordPress こちらにある XSLT を使わせていただきました。

まず、XSLT に合わせて BlogML の最初の方にある xmlns=”http://www.blogml.com/2006/09/BlogML” を消します。
次に、もとの .Text の日付が JST を前提にしてあるため XSLT の <xsl:template name=”topubdate”> のところの +0000 を +0900 にして JST に合わせます。
あとは BlogML のファイルにこの XSLT を適用してやるだけ。

私は、BlogML の 2行目に <?xml-stylesheet href="BlogML2WXR.xsl" type="text/xsl"?> と書いて IE で読み込みました。
もちろん、単に IE で読み込むと XSLT を適用した結果を HTML として解釈したものが表示されるだけです。
XSLT を適用した結果の XML を取り出すのに、私は
Internet Explorer Tools for Validating XML and Viewing XSLT Output
を使ってます。
こいつを実行して解凍すると msxmlvw.htm と msxmlvw.inf が入ってますので、これらを適当なフォルダに入れておいて msxmlvw.inf を右クリックして「インストール」
これで IE を立ち上げなおして BlogML を読み込んだ状態で右クリックすると 「View XSL Output」 が増えてます。
これで XSLT を適用した結果の XML を表示させることができますので、コピー&ペーストして utf-8 で保存してやれば OK です。

こうして作った WXR 形式のファイルを wordpress.com のブログにインポートしてみたら一応きちんとインポートできてました。(ただし試したのは記事 1つ分だけ)

■ WXR → Blogger
WXR 形式を Blogger 形式にします。
wordpress2blogger というツールが http://code.google.com/p/google-blog-converters-appengine/ にあります。このツールは Python で書かれてるみたいです。このツールが http://wordpress2blogger.appspot.com/ で動いてますので、私はこれを使わせてもらいました。(ただし、一度に変換できるのは 1M バイトまで)

ただ、上記の手順で作った WXR を変換しようとしたらエラーになりました。
pubDate が fmt=%a, %d %b %Y %H:%M:%S になっていないと言われます。
とりあえずエラーが出ないように XSLT の <xsl:template name=”topubdate”> のところの <xsl:param name="date" /> の後ろに “Mon, “ と書き足して変換しなおしました。
これだとすべての日付が Mon (月曜日) になってしまいますが、きっと曜日なんて読み飛ばしてるだけでしょうから問題ないでしょう。

■ Blogger 形式のデータを Blogspot にインポート
これで .Text のデータが Blogger 形式になったので Blogspot の設定ページにある 「ブログをインポート」 でインポートします。
ただ、以下の修正が必要でした。

  • ”<ns0:link href=”001” ... ”  のようになっているところがあるので “<ns0:link href="http://www.blogger.com/" ... “ に変更。(いつの間にか href の値がおかしくなっていた。これがおかしいとインポート時にエラーが出て読み込めない)
  • “<ns0:published>2003-07-05T18:18:00Z</ns0:published>” を “<ns0:published>2003-07-05T18:18:00+09:00</ns0:published>” に変更。(JST なのに “Z” となっているためインポートすると時間がずれる。なので “+09:00” としてやる)

これで無事 Blogspot にインポートできました。

2010年12月20日月曜日

[お知らせ] 過去に他のブログに書いた記事をすべてこのブログに持ってきました

今まで使ってきたブログ(技術系)

2003年7月 BlogX を立ち上げてブログ開始。
(BlogX っていうのは C# で作られたブログエンジンです。2004年くらいで更新はストップしてます)


.Text 時代

2004年1月 .Text を立ち上げてブログ開始。
(.Text も C# で作られたブログエンジンです。こちらもずいぶん前に開発は終了してるようです)

BlogX のデータをすべて移行して旧ブログは停止。
2008年4月ごろ 技術系以外の趣味のことを書いていた FC2 のブログに技術系のことも書くようになってきた。
(使い分けが面倒になった)

FC2 時代
2009年1月 .Text のブログの更新を停止して FC2 の方に一本化。
2010年7月 やっぱり技術系と趣味系を分離。
blogspot に技術系のためのブログを作成。それがここ。

(最初は独自ドメインを使った URL で開始したけど 2010/12/14 に普通の blogspot の URL に変更)

blogspot 時代
現在  

と、こんな感じで今までブログを移り変わってきたんですが、特にデータを移行するってことはしてきませんでした。(BlogX → .Text はしましたが)
それを今回、過去に書いた技術系の記事をすべてこのブログに持ってきました。

.Text に書いた記事はすべてここに移行しました。ちょっと面倒なところもありましたが、コメントも含めて無事すべてのデータを移行できました。移行手順については別の記事にまとめるつもりです。
で、この .Text のブログは停止しました。
.Text は開発時期が古いですし、コメントやトラックバックのスパム防止機能がありません。自分でソースをいじってスパムを弾いたり、CAPTCHA を導入したりしてましたが、それでも今でもスパムがやってきます。なので、たまにスパムを消してやったりしないといけないんですが、さすがに面倒になりました。
今回、過去の記事をここに移行してきたのは、この 「.Text にやってくるスパムがうざいから .Text を停止したい」 というのが一番の理由です。

FC2 では技術系のことと趣味系のことがまぜこぜになってますが、今回、技術系の記事をすべてここに移行しました。こちらもコメントも含めて移行できました。この手順についても別の記事にまとめるつもりです。
FC2 の方を消したりはしていないので、技術系の記事に関してはここと FC2 とに同じものが 2つあります。消すのもなんなので、これはこのままにしておくつもりです。

なお、単純に記事を移行しただけで修正などはしていません。なので、リンクが切れたり画像が表示されていないようなところがあるかもしれません。また、スタイルが違うせいで見た目がおかしいところもあるかもしれません。これらはとりあえずそのままにしておくつもりです。あまりにひどいところがあったら修正するかもしれませんけど。

というわけで、

という使い分けで今後もやっていきます。
(最近、どちらもあまり更新してませんが)

2010年12月14日火曜日

[お知らせ] このブログの URL が変わりました

下で書いたとおり、このブログの URL が変わりました。新しい URL は http://shinichiaoyagi.blogspot.com/ です。
RSS の URL も変わりました。 http://shinichiaoyagi.blogspot.com/feeds/posts/default です。

すでに以前の URL ではアクセスできません。
あらためて検索してみたら、あまり多くはありませんが、はてブ、.NET Clips、MSDN フォーラムなどからリンクされていました。これらは完全にリンク切れになってしまいます。申し訳ないです。
なお、URL が変わっただけでブログ内の記事自体は以前とまったく同じです。(各記事の URL もドメイン名部分を “shinichiaoyagi.blogspot.com” に置き換えてもらえばそれ以外は同じままでアクセスできるはず)

2010年12月13日月曜日

[お知らせ] このブログの URL が変わります

このブログの URL が http://shinichiaoyagi.blogspot.com/ に変わります。
あわせて RSS の URL も変わります。( http://shinichiaoyagi.blogspot.com/feeds/posts/default )
URL の変更は 2010年12月14日の午前中を予定しています。(って、もう明日ですが)

なお、変更後は今の URL でのアクセスはできなくなります。リダイレクトなどもされません。
ですので、このブログへのリンクはみんな切れちゃうことになります。すみません。

2010年10月28日木曜日

[VS2010] Help Viewer 1.1 (Visual Studio 2010 SP1 といっしょにリリース予定)

Help Viewer 1.1 Preview Video より。
Visual Studio 2010 SP1 といっしょに Help Viewer 1.1 がリリース予定だそうです。
紹介ビデオはこちら Help Viewer Updates in Visual Studio 2010 SP1

VS2010 では、ローカルのヘルプを見るのにもブラウザ(IE)が使われるようになってました。それが SP1 で専用のヘルプビューワーアプリケーションが追加されるようです。
すでに GrapeCity ヘルプビューワ とかいくつかヘルプビューワーがありますから、とってもイマサラ感がしないでもないですが。

ちなみに、VS2010 の「ヘルプ」-「ヘルプ設定の管理」メニューでオンライン・ローカルのどちらのヘルプを参照するかや、オンライン上のヘルプをローカルにインストールしたりできます。

ところで、”Help Viewer 1.0” というのは、ヘルプシステム全体の名称として使われていたと思います。Microsoft Help 2 の次のバージョンの名前が Help Viewer 1.0 だったはずです。
ということは、今回のアプリは「Help Viewer 1.1 という名前の Help Viewer 1.0 用ビューワーアプリ」ってこと?
上記の記事にも「Q: 既存のヘルプコンテンツに変更が必要なの?」 「A: 必要ない」とか何とかあるので、やっぱりそういうことだよなぁ。
うーむ

2010年10月27日水曜日

[.NET] C# でミニダンプを書き出す方法

Writing Minidumps in C# より。
C# でミニダンプを書き出すコードが紹介されてたので覚え書きとして。

ミニダンプを書き出しておけばあとでそのときの状態(呼び出し履歴とか変数の内容とか)を確認することができます。
特に Visual Studio 2010 ではマネージコードのダンプに対応しているのでちゃんと C# や VB での行番号とかがわかります。(VS2008 とかだと JIT 後のアセンブラレベルのものしか見れないんじゃないかと思います。確認してませんが)

[Silverlight][WP7] PhysicsHelper 4.0 Alpha

PhysicsHelper の 4.0 Alpha がリリースされてました。
http://physicshelper.codeplex.com/

PhysicsHelper とは、C# で実装された物理演算エンジンである Farseer Physics Engine をビヘイビアーで包みこんだものです。おかげでとってもお手軽に XAML の要素に対して物理演算をすることができます。すでに Windows Phone 7 にも対応してるそうです。
とりあえず http://www.andybeaulieu.com/video/PhysicsHelper4Intro.wmv このビデオを見ればどういうものかはわかるんじゃないかと。
(英語ですが、Blend を使ったデモなので見てるだけでもやってることはわかりました)

ただ、まだ Alpha なのでバグもあるし、未実装の部分もあるとのこと。

2010年9月28日火曜日

[Silverlight] Silverlight は Web のためのものでは無くなった

Silverlight…not just for the Web… より。

おぉ、ほんとだ! http://msdn.microsoft.com/en-us/library/default.aspx を見ると

msdnsilverlight_en_us.jpg

このように Silverlight が 「.NET Development」 の下に移動してます。
今までは 「Web Development」 の下でした。
上記記事にあるとおり、out of browser もあるし、Windows Phone 7 もあるんだから Web の下よりは .NET の下の方がいいんじゃないか、っていうことですね。

けど、日本語版 http://msdn.microsoft.com/ja-jp/library/default.aspx の方を見ると

msdnsilverlight_ja_jp.jpg

まだ 「Web 開発」 の下ですね。
きっとそのうち英語版と同じように移動するんでしょう。

2010年9月22日水曜日

[Silverlight] Effect がパフォーマンスに与える影響

Silverlight Performance Tip: Understanding the impact of Effects on performance より。
なるほどぉ。
正確なことは上記記事を見てもらうとして要点のみ。

<Grid x:Name="LayoutRoot" Background="White">
    <Border Width="200" Height="100" Background="LightGray">
        <Border.Effect>
            <DropShadowEffect/>
        </Border.Effect>
        <Grid Width="200" Height="100">
            <TextBox Width="100" Height="30"></TextBox>
        </Grid>
    </Border>
</Grid>

こんな XAML があるとします。表示させると以下のような感じです。

DropShadowEffectPerformance.jpg

DropShadowEffect を使って影を落としていて、真ん中にテキストボックスがあるというごく単純なものです。
で、DropShadowEffect などのエフェクトがかかっていると、その内側の要素に再描画が必要になった場合に DropShadowEffect の部分ごと再描画されるそうです。
この例では中にテキストボックスがあるわけですが、テキストボックスの点滅するキャレットも再描画によって描かれてます。なので、キャレットが点滅するたびに回りの Border ごと再描画されることになります。もちろん、キャレットだけでなく、マウスホバーで色を変えたりするようなボタンとか、進捗にあわせて動くプログレスバーとか、再描画が発生するものはみんな同じことになります。
この例では Border の下にはテキストボックスがあるだけなので特に問題にはなりませんが、コントロールがたくさんあるような場合にはそれらがみんな再描画されることになるので CPU 負荷が高くなったりといった問題が発生するかもしれません。
で、どうすればいいかというと

<Grid x:Name="LayoutRoot" Background="White">
    <Border Width="200" Height="100" Background="LightGray">
        <Border.Effect>
            <DropShadowEffect/>
        </Border.Effect>
    </Border>
    <Border>
        <Grid Width="200" Height="100">
            <TextBox Width="100" Height="30"></TextBox>
        </Grid>
    </Border>
</Grid>

こんな風に Border を 2つに分けてしまえばいいそうです。
実際やってみると確かに見た目は同じになります。
そして、テキストボックスが含まれている方の Border には何のエフェクトも無いことになるので無駄な再描画は発生しないということですね。
なるほどなぁ。

なお、再描画が発生する範囲は Silverlight を貼り付けている HTML の方に

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
  <param name="enableRedrawRegions" value="true"/>
:
:

enableRedrawRegions を指定すれば可視化することができます。

2010年9月14日火曜日

[Silverlight][Twitter] Seesmic Desktop 2 って MEF で機能追加できるようになってるのか

Twitter クライアントの一つ、Seesmic Desktop 2 ですが、これって Silverlight 4 なんですね。Silverlight 4 ですが、ブラウザ上で動かすのではなくクライアント PC にインストールして実行する形態になっています。(out-of-browser です)

そして、
Writing plugins for Seesmic Desktop
(Microsoft の Silverlight チームのプログラムマネージャーの Tim Heuer 氏のブログ)
によると Seesmic Desktop 2 は Managed Extensibility Framework(MEF)によって拡張可能になっているそうです。Visual Studio 2010 用のテンプレート Seesmic Desktop Platform Developer Templates なんてのもありますし、Seesmic Desktop Platform Plugins には Tim 氏が作ったプラグインが紹介されています。
結構拡張性も高そうで、なかなかおもしろそうです。

# といいつつ、インストールしてちょっと使ってみたけど、イマイチ自分には合わず。
# 結局、TweetDeck に戻っちゃいました。
# 一時期は Seesmic Web を使ってたけど、最近 TL が更新されない病が発生してて使い物にならず。

2010年9月13日月曜日

[.NET] MTA では OpenFileDialog が動かない?

たまたま見かけてちょっと気になったので覚え書きとして。。。

Current thread must be set to single thread apartment (STA) mode before OLE calls can be made」 より。
Visual Studio セットアッププロジェクトでインストーラーを作るときにインストーラークラスのカスタムアクションで System.Windows.Forms.OpenFileDialog を使うとエラーが出ちゃうそうです。Win XP や 2003 ではちゃんと動くけど、Vista やそれ以降の Windows で発生するとのこと。
デバッガーにアタッチしておくと、"Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it. This exception is only raised if a debugger is attached to the process." というエラーメッセージが出るそうです。原因はこのメッセージのまんまで、MSI が MTA で動いてるからで、OpenFileDialog なんかは STA じゃないと動かないかららしい。

へぇ、OpenFileDialog とかって MTA じゃ動かなかったんだ。知らんかった。

上記の記事では対策方法も紹介されています。
別のスレッドを作って、そいつを Thread.SetApartmentState(ApartmentState.STA) してから OpenFileDialog を ShowDialog() してやればいいようです。

2010年9月10日金曜日

[C#] yield return はスレッドセーフなのか? 追記

昨日の 「[C#] yield return はスレッドセーフなのか?」 に匿名さんからコメントを頂きました。
昨日の記事の最後のところにまとめとして 「lock { ~ } の中で yield return を使うのはやめておいた方がよさげ」 と書きましたが、ちょっと乱暴なまとめだと思ったので追記します。
(最初は昨日の記事に追記するつもりだったんですが、長くなったので別記事にしました)

えーと、もともと 「lock { ~ } の中で yield return を使うのはやめておいた方がよさげ」 と私が思ったのは 「ロックが解除されるタイミングが呼び出し元に依存するから」 というのが理由です。
お仕事で lock { ~ } の中で yield return を使うコードを書いていたときに、ふと、「これってちゃんとロックかかるの?」 と疑問に思ったのが発端で今回のことを調べたんです。このとき書いていたコードは 「なるべく早くロックを解除して他のスレッドが動けるようにしたい」 というものだったので、自然とロック解除のタイミングが呼び出し元に依存するのは避けたいと思ってました。
そういう前提があったので 「lock { ~ } の中で yield return を使うのはやめておいた方がよさげ」 と、まとめのところに書きました。けど、そういう前提であることをあまり明確にせずにこうまとめちゃうのはちょっとまずかったですね。

-- 9/10 13時追記 ここから
前の記事にもちょこっと追記しましたが、指摘を頂いたのでこちらにも追記しておきます。
すっかりロックが解除されるのは Enumerator の Dispose() が呼び出されたときだけかのように書いちゃってますが、実際には MoveNext() が false を返すときにも Dispose() と同じ処理が行われるようになっています。なので、Enumerator の Dispose() メソッドを呼び出したときか、MoveNext() が false を返して列挙が終わるときにロックが解除されることになります。
もちろん、以下に書いたファイルの例でも同じです。
-- ここまで追記

ということで、また他の例を。

コメントで頂いたように using { ~ } や try ~ finally でも lock { ~ } と同じことが起こります。
たとえば、以下のようなコード。

private IEnumerable<string> GetLines()
{
    using (var stream = new FileStream("test.txt", FileMode.Open, FileAccess.Read, FileShare.None))
    using (var reader = new StreamReader(stream))
    {
        var text = reader.ReadToEnd();
        var lines = text.Split('\n');
        foreach (var line in lines)
        {
            yield return line;
        }
    }
}

これはファイルをオープンするときに FileShare.None を指定してファイルをアクセス禁止にしています。
yield return が無ければ using のスコープを抜けるときに stream.Dispose() と reader.Dispose() が呼び出されてファイルがクローズされます。もちろん、このときにファイルのアクセス禁止も解除されます。
しかし、yield return によって出来上がるコードは lock { ~ } のときに見たのと同じようなものですから、stream.Dispose() と reader.Dispose() が呼び出されるのは Enumerator の Dispose() メソッドからになります。
呼び出し元が foreach を使っているときは、以下のような感じになるわけです。

foreach (var line in GetLines())
{

    ... line を使って何か処理 ...

}
// foreach を抜けたときに Enumerator の Dispose() が呼ばれて test.txt のアクセス禁止が解除される

このように GetLines() から返ってきた Enumerator での列挙が終わったあとに、foreach によって作られた Enumerator.Dispose() の呼び出しが行われて、ファイルクローズおよびアクセス禁止解除ということになります。

では、yield return を使わない場合はどうなるでしょうか?
以下のようなコードです。

private IEnumerable<string> GetLines()
{
    using (var stream = new FileStream("test.txt", FileMode.Open, FileAccess.Read, FileShare.None))
    using (var reader = new StreamReader(stream))
    {
        var text = reader.ReadToEnd();
        var lines = text.Split('\n');
        return lines;
    }
}

この場合は、GetLines() メソッドから return する時点で using のスコープを抜け、stream.Dispose() と reader.Dispose() が呼び出されてファイルがクローズされ、アクセス禁止が解除されます。
ですから、呼び出し元が上記と同じ foreach を使ったものであっても、foreach の列挙が始まるときにはすでにファイルがクローズされている状態になっています。

で、これはどちらが正しいとか言えるようなたぐいのものではありません。
前者は 「列挙が終わって Enumerator の Dispose() メソッドを呼び出すまでファイルがアクセス禁止になる」、後者は 「Enumerator を作成する間だけファイルがアクセス禁止になる」 ということになるわけですが、どちらにしたいかなんてことはケースバイケースです。
ただ、今回取り上げたような yield return の動作を知らないと 「yield return のところで using のスコープを抜けてファイルはクローズされるんじゃないの?」 と勘違いしやすいとは言えると思います。

というわけで、結局のところ、lock { ~ }、using { ~ }、try ~ finally などスコープに重要な意味があるものの中に yield return を書くときはちょっと注意が必要ではあると思うけど、yield return でいいかどうかなんてことはケースバイケース、という感じですね。

それにしても、yield return についてちゃんと考えたのなんて今回が初めてなんですが、なかなか興味深かったです。

2010年9月9日木曜日

[C#] yield return はスレッドセーフなのか?

スレッドセーフと言ってもいろいろ意味がありますが、ここでは以下のようなコードのことを指してます。

class YieldTest
{
    private List<Hoge> list = new List<Hoge>();

    public IEnumerable<Hoge> GetHoges1(string s)
    {
        lock (this.list)
        {
            var result = new List<Hoge>();
            foreach (var x in this.list)
            {
                if (x.Value == s)
                {
                    result.Add(x);
                }
            }
            return result;
        }
    }

    以下略

見てもらったまんまですが、何かの List があって、この List は別のスレッドからも操作されるからアクセス時には必ず lock すること、というような場合です。
で、上記の GetHoges1() メソッドは以下のように yield return を使って書いてもほとんど同じ意味です。

    public IEnumerable<Hoge> GetHoges2(string s)
    {
        lock (this.list)
        {
            foreach (var x in this.list)
            {
                if (x.Value == s)
                {
                    yield return x;
                }
            }
        }
    }

さて、この yield return を使った GetHoges2() メソッドはスレッドセーフなんでしょうか?

yield return っていうのは、魔法の力で動いているわけではなく、C# コンパイラが自動的に IEnumerator を実装したクラスを作成してくれて動いてるわけです。どんなコードが作成されるのかを言葉で説明するのは難しいですが、yield return や yield break のところでバラバラに分割してうまいこと MoveNext() に収め直すというような感じです。ですから、普通に考えると lock のスコープを抜けてしまいきちんと排他されないんじゃないか?と思えるわけです。
C# 言語仕様」 の 「8.14 yield ステートメント」 を見ると try ~ catch の中に yield は書けない、というようなことが書いてあります。しかし lock に関することは何も書いてありません。

というわけで、実際に生成されたコードを Reflector で見てみました。
すると以下のようになってました。

private class Enamerator : IEnumerator<Hoge>, IDisposable
{
    private List<Hoge> list = (this.list がセットされる)
    private IEnumerator<Hoge> enumertor;
    private bool lockToken = false;

    public Hoge Current { get; set; }

    public bool MoveNext()
    {
        if (最初の実行)
        {
            Monitor.Enter(this.list, ref this.lockToken);
            this.enumertor = this.list.GetEnumerator();
        }
        while (this.enumertor.MoveNext())
        {
            if (条件判定)
            {
                this.Current = this.enumertor.Current;
                return true;
            }
        }

        // 9/10 13時追記
        // コードは省略しますが、ここで下の Dispose() メソッドと同じ処理(Monitor.Exit の呼び出し)が行われます。

        return false;
    }

    public void Dispose()
    {
        if (this.lockToken)
        {
             Monitor.Exit(this.list);
        }
    }
}

上記のコードは意味的にはこんな感じになっているという例であって、実際の自動生成されたコードとはかなり違うんですが、まぁ、こんな感じです。
どうでしょう?ちゃんと、初めて MoveNext() メソッドが呼ばれたときに Monitor.Enter で list に対してロックをかけ、Dispose() メソッドで Monitor.Exit でロックを解除しています。

-- 9/10 13時追記 ここから
上にも書き足しましたが、MoveNext() が false を返すときにも Dispose() と同じ処理が行われるようになっています。なので、Enumerator の Dispose() メソッドを呼び出したときか、MoveNext() が false を返して列挙が終わるときにロックが解除されることになります。
-- ここまで追記

すげぇ!C# コンパイラは lock のことまで考慮して yield return の処理をしてるのか!

。。。と、思いましたが、実は違いますね。
まず、lock ステートメントは C# のシンタックスシュガーで、コンパイルすると Monitor を使ったコードが出来上がります。yield return と違ってそんなにややこしくなく、以下のような try ~ finally で Monitor.Enter と Monitor.Exit を囲んだコードに変換されるだけです。全体を try { ~ } で囲み、finally で Monitor.Exit() を呼び出すことによって途中で例外が発生しようが何しようがスコープを抜けるときには確実にロックが解除されるようになっているわけですね。

lock (this.list)
{
    ...
}

---- 上記をコンパイルすると下記のコードができあがる ----

bool lockToken = false;
try
{
    Monitor.Enter(this.list, ref lockToken);

    // ここに lock { ... } の ... 部分が入る
}
finally
{
    if (lockToken)
    {
        Monitor.Exit(this.list);
    }
}

また、「C# 言語仕様」 の 「8.14 yield ステートメント」 に try ~ catch の中に yield は書けないとありますが、try ~ finally の中には書けるとあります。
で、try ~ finally の中に yield が書いてある場合は、finally の部分が自動生成された Enumerator の Dispose() メソッドの中で実行されるわけですね。
だから、C# コンパイラはいつもどおりに lock ステートメントを解釈し、いつもどおりに yield return を解釈すると、自動的に正しく lock が働くコードが生成されるわけです。

というわけで、まとめ。

lock { ~ } の中で yield return を使ってもきちんとロックされる。

ただし、重要な注意点があります。
上記の自動生成されるコードを見れば明らかですが

lock { ~ } の中で yield return を使った場合は、返された Enumerator の Dispose() メソッドを呼ぶまでロックが解除されない。

なお、多くの場合、yield return で返された Enumerator は foreach で使われるんじゃないかと思います。
foreach ステートメントは Enumerator が IDisposable を実装している場合は自動的に Dispose() メソッドを呼び出すようになっています。(「C# 言語仕様」 の 「8.8.4 foreach ステートメント」。これは C# の最初のバージョンからそういう仕様だったと思います) だから foreach で使う分にはきちんと Dispose() が呼ばれますから何も問題ありません。
というか、Enumerator は多くの場合に IDisposable を実装していますから、それをチェックしてきちんと Dispose() メソッドを呼び出してやらないとまずいことになる可能性大です。foreach を使わずに Enumerator を受け取るときは using を使うなりしてちゃんと Dispose() を呼び出してやりましょう。

そして、ロックが解除されるタイミングが違うというのも大きな違いですね。
最初の例の GetHoges1() では lock のスコープを外れた時点でロックが解除されます。
それに対して GetHoges2() では Enumerator を受け取った側で Dispose() を呼び出した時点でロックが解除されます。ということは、ロックが解除されるタイミングが呼び出し元の処理に依存してしまうわけですね。
なるべく早くにロック解除してやって他のスレッドが動けるようにしてやりたいというのが普通でしょうから、呼び出し元に依存しちゃうのは避けたい場合が多いんじゃないかと思います。

というわけで、本当のまとめ。

lock { ~ } の中で yield return を使ってもきちんとロックされる。しかし、Enumerator の Dispose() が呼ばれるまでロックが解除されないし、いつ Dispose() が呼ばれるかも呼び出し元に依存することになる。
だから lock { ~ } の中で yield return を使うのはやめておいた方がよさげ。

9/10 追記を書きました。
[C#] yield return はスレッドセーフなのか? 追記

2010年9月8日水曜日

[VS] Visual Studio の色設定

へぇ、こんなサイトがあったんですね。
http://studiostyles.info/

Visual Studio 用の色設定がたくさん投稿されています。
背景が黒いやつの方が人気あるみたいですねぇ。私はデフォルトの白背景のまま使ってるから、黒背景は違和感あるなぁ。

ちなみに、使い方は Visual Studio の「ツール」メニューの「設定のインポートとエクスポート」でインポートするだけです。インポートする前に今の設定をエクスポートしておけばあとで元に戻せます。(VS2010 ではインポートするときに今の設定を保存しておくか聞いてくれます)

おまけ
これは有名だと思いますが、VS2010 では Visual Studio Color Theme Editor を入れてやるとメニュー、ツールバー、タブ、タイトルバー、などなどの色を変更することができます。(メニューに「Theme」が追加されます)

2010年9月2日木曜日

[Silverlight] XAP の最適化ツール (と、VS2010 アドインの作り方)

Xaps Minifier. A Step Forward. New Options and New Features」 より。
おぉ、こりゃなるほどだ。

Xaps Minifier という VS2010 のアドインが紹介されています。(私はまだ試してませんが)
どういうものかは part 1 の記事で解説されていますが、ここでも簡単に概要を書いときます。
part 1 の記事の最初がやろうとしてることの解説、残りの大部分は Visual Studio 2010 アドインの作り方の解説になってます)

Silverlight のアプリでも規模が大きくなってくると複数のプロジェクトにわけたりします。Visual Studio では XAP ファイルはプロジェクトごとにできるようになってますから、プロジェクトの数だけ XAP ファイルが出来上がります。
で、XAP ファイルの中にはそのプロジェクトが使っているアセンブリ (DLL) がすべて入っています。なので、他のプロジェクトを参照していたり、共通で使うアセンブリがあったりした場合は、同じアセンブリがあちこちの XAP ファイルの中に入っていることになります。
というか、複数プロジェクトの場合、プロジェクト参照しながらの方が普通だと思うので、ほとんどのアセンブリがダブって入っていると思ったほうがいいくらいじゃないかと思います。
(XAP ファイルは ZIP の拡張子を変えたものですから、拡張子を ZIP にして解凍してみれば簡単に確認できます)

しかし、実行時には同じアセンブリが重複して読み込まれることはありません。
なので、複数の XAP ファイルの中に同じアセンブリを入れておく必要はありません。最初に読み込まれる XAP ファイルにだけ入れておけば十分です。
けど、XAP ファイルが読み込まれる順番はプログラムの作り方次第なのでどれが最初かなんてわかりません。
ただ、スタートアップに指定されている XAP は必ず最初に読み込まれるわけですから、これに含まれているアセンブリは他の XAP に入れておく必要がないことは明らかです。

というわけで、この 「スタートアッププロジェクトに含まれているアセンブリを他の XAP に入らないようにする」 という設定をしてくれるのが Xaps Minifier です。
ほんと、そりゃそうだって感じです。
(もちろん、こういうことが出来るのは他に配布したりする予定がない XAP ファイルだけですが)

あと、複数のプロジェクトで使われているアセンブリをスタートアップの XAP に含めるようにしてもくれるようです。こうすればトータルサイズは当然小さくなりますね。
ただ、これは 「[Silverlight] Silverlight アプリケーションの起動時に関するベストプラクティス」 にある 「起動時間を早くするにはスタートアップの XAP ファイルを小さくしろ」 っていうのの真逆になっちゃいますが。
この辺はケースバイケースで考えるしかないでしょうね。

2010年9月1日水曜日

[IE9] コンテンツ領域が 2 ピクセルくらいサイズが変わるらしい

Making Sites Look Their Best in Standards Mode」 より。
今までまったく気づいてませんでしたが、IE8 まではコンテンツ領域の回りに 2 ピクセルのボーダーがあったんですね。言われてみると確かにあるw

で、どうやら IE9 ではこの 2 ピクセルが無くなるらしい。
ただし、無くなるのはスタンダードモードのときだけで、レガシーモードのときは今までと同じに 2 ピクセルのボーダーがあるとのこと。
スタンダードモードかレガシーモードかはどうやら doctype が HTML5 になってるかどうかで判断するみたい。

いやぁ、やっぱり IE くらいのアプリケーションになると、ここまで後方互換性を気にしてるんだなぁ、と素で感心。というか、こっそり変えちゃっても誰も気づかないんじゃない?ww

9/6 追記
ちゅきさんに頂いたコメントでタイトルが間違ってることに気づきました。
「2ピクセル小さくなる」ってタイトルでしたが、ボーダーが無くなるんだから小さくなるんじゃないですね。けど、右のスクロールバーとか下のステータスバーとかのところにボーダーがあるのかよくわからなかったので、とりあえず「2ピクセルくらいサイズが変わるらしい」というタイトルに変更しました。

[Silverlight][3DCG] SilverMotion (Silverlight 用の 3DCG 描画エンジン)

SilverMotion
Silverlight 用の 3DCG 描画エンジンだそうです。
PostVision という会社の商品みたいですね。(フリー版もあるようです)

Silverlight 自体には 3D 描画機能はありませんから全部自前で(おそらくは C# で)実装したんですね。
デモページ で動いているところが見れます。
私の環境だと、複数ライト + テクスチャマッピング + ノーマルマッピング + 環境マッピングで総ポリゴン数 9万くらいのカエルさんが 45fps くらいで描画できてました。
(オープンソースの Silverlight 用 3DCG 描画エンジンなんかもあったと思いますが、私はそれらのことを知らないので、それらに比べてどうなのかとかはわかりません)

ちなみに Blender, 3DS Max, Maya, MilkShape などからエクスポートした .3DS ファイルに対応しているそうです。


[Silverlight][3DCG] SilverMotion (Silverlight 用の 3DCG 描画エンジン)

SilverMotion
Silverlight 用の 3DCG 描画エンジンだそうです。
PostVision という会社の商品みたいですね。(フリー版もあるようです)

Silverlight 自体には 3D 描画機能はありませんから全部自前で(おそらくは C# で)実装したんですね。
デモページ で動いているところが見れます。
私の環境だと、複数ライト + テクスチャマッピング + ノーマルマッピング + 環境マッピングで総ポリゴン数 9万くらいのカエルさんが 45fps くらいで描画できてました。
(オープンソースの Silverlight 用 3DCG 描画エンジンなんかもあったと思いますが、私はそれらのことを知らないので、それらに比べてどうなのかとかはわかりません)

ちなみに Blender, 3DS Max, Maya, MilkShape などからエクスポートした .3DS ファイルに対応しているそうです。

2010年8月26日木曜日

[.NET] MSDN ライブラリのクラスリファレンスがバージョン選択できるようになってる!けど、、

Improved Topic Versions Now In MSDN Library
を見て知りました。

MSDN ライブラリのクラスリファレンスのところで .NET Framework のバージョンが選択できるようになっています。上記記事によると 8/16 の週の前半に機能追加されたみたいですね。

たとえば、 http://msdn.microsoft.com/ja-jp/library/system.aspx だと以下みたいな感じ

MSDN.jpg

ただし、対応してるのはライトウエイト表示のときだけみたいです。

クラシック表示のときにもできて欲しいなぁ。
確かにクラシック表示の時には左側にツリーがあってそこでバージョンを選べますから、最初からみたいバージョンが決まってる時は不自由しません。けど、.NET Framework 4 と Silverlight 4 を見比べたいなんてこともありますし、他サイトのリンクからやってきて 「あっ、バージョンが違う」 なんてこともありますし。

URL を書き換えてやれば違うバージョンに飛ぶことは出来ることは出来るんですが。
たとえば、 http://msdn.microsoft.com/ja-jp/library/system.aspx のときは

  • http://msdn.microsoft.com/ja-jp/library/system(v=VS.100).aspx とすると .NET Framework 4
  • http://msdn.microsoft.com/ja-jp/library/system(v=VS.95).aspx とすると Silverlight

というように .aspx の前でバージョンを指定できます。(”v=” は省略してもいいみたい)
けど、正直めんどくさい。
各バージョンの対応は以下のようになってるみたいです。

.NET Framework 4 (v=VS.100)
.NET Framework 3.5 (v=VS.90)
.NET Framework 3.0 (v=VS.85)
.NET Framework 2.0 (v=VS.80)
.NET Framework 1.1 (v=VS.71)
Silverlight (v=VS.95)

2010年8月25日水曜日

[Silverlight] MEF を使って XAP を動的に読み込む その2

[Silverlight] MEF を使って XAP を動的に読み込む その1」 の続きです。

今回は XAP を動的に読み込んでみる例です。

なお、Visual Studio 2010 のソリューションを http://cid-ca42d76a68f54d16.office.live.com/self.aspx/Public/Sample/MefSample.zip に置いておきます。
ZIP ファイル内の MefSample02 フォルダが以下の例です。
この例では、本体である MefSample02 が Page1.xap、Page2.xap を読み込んでいます。そしてボタンクリックで Page1.xap や Page2.xap に入っているコントロールを表示しています。

まずは本体側の XAML と C# コードです。

<UserControl x:Class="MefSample02.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400"
    Loaded="OnLoaded">

    <StackPanel x:Name="LayoutRoot" Background="White">
        <StackPanel Orientation="Horizontal">
            <Button x:Name="button1" Content="Page1" Click="button1_Click"/>
            <Button x:Name="button2" Content="Page2" Click="button2_Click"/>
        </StackPanel>
        <StackPanel x:Name="panel1"/>
    </StackPanel>
</UserControl>
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.Windows;
using System.Windows.Controls;

namespace MefSample02
{
    public partial class MainPage : UserControl
    {
        [ImportMany("Page", AllowRecomposition = true)]
        public List<FrameworkElement> controls = new List<FrameworkElement>();

        public MainPage()
        {
            InitializeComponent();
        }

        private void OnLoaded(object sender, RoutedEventArgs e)
        {
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(CreateCatalog("Page1.xap"));
            catalog.Catalogs.Add(CreateCatalog("Page2.xap"));
            var container = new CompositionContainer(catalog);
            container.ComposeParts(this);
        }

        private DeploymentCatalog CreateCatalog(string uri)
        {
            var deploymentCatalog = new DeploymentCatalog(uri);
            deploymentCatalog.DownloadCompleted += (s, e) => { /*ダウンロード完了イベント*/ };
            deploymentCatalog.DownloadProgressChanged += (s, e) => { /*ダウンロード進行中*/ };
            deploymentCatalog.DownloadAsync();
            return deploymentCatalog;
        }

        private void button1_Click(object sender, RoutedEventArgs e)
        {
            NavigatePage("Page1");
        }

        private void button2_Click(object sender, RoutedEventArgs e)
        {
            NavigatePage("Page2");
        }

        private void NavigatePage(string pageName)
        {
            this.panel1.Children.Clear();
            foreach (var page in this.controls)
            {
                if (page.Name == pageName)
                {
                    this.panel1.Children.Add(page);
                    break;
                }
            }
        }
    }
}

controls フィールドに ImportMany 属性を付けて、ここにインポートされるようにしています。前回と違って controls は FrameworkElement のコレクションなので Import では無く ImportMany 属性を使っています。
そして、インポートの解決をしているのが OnLoaded イベントの

var catalog = new AggregateCatalog();
catalog.Catalogs.Add(CreateCatalog("Page1.xap"));
catalog.Catalogs.Add(CreateCatalog("Page2.xap"));
var container = new CompositionContainer(catalog);
container.ComposeParts(this);

の部分です。
カタログは CreateCatalog() メソッドで作っています。DeploymentCatalog クラスという、XAP を読み込んでインポート元として使えるようにしてくれるそのものズバリなクラスが用意されていますからそれを使っています。なお、DeploymentCatalog クラスは今のところ Silverlight 4 にしかありません。(MEF は .NET Framework 4 にも入ってますが DeploymentCatalog クラスは .NET Framework 4 には無いみたいです)
AggregateCatalog は複数のカタログをひとつに束ねるカタログです。
そしてコンテナを作り、this へのインポートを実行を依頼しています。

前回紹介したようにデフォルトのコンテナを使うこともできます。
その場合は以下のようになります。

var catalog = new AggregateCatalog();
catalog.Catalogs.Add(CreateCatalog("Page1.xap"));
catalog.Catalogs.Add(CreateCatalog("Page2.xap"));
CompositionHost.Initialize(catalog);
CompositionInitializer.SatisfyImports(this);

実は CompositionHost.Initialize() メソッドには複数のカタログを渡せるようになっているので、それを使うと AggregateCatalog で束ねてやる必要も無くなります。以下のような感じ。

CompositionHost.Initialize(
    CreateCatalog("Page1.xap"),
    CreateCatalog("Page2.xap"));
CompositionInitializer.SatisfyImports(this);

ソースの説明に戻って、残りの部分はボタンクリックイベントでコントロールを表示しているだけです。
button1_Click()、button2_Click() イベントで、MEF が controls フィールドに格納してくれた Page1.xap、Page2.xap の中のコントロールを名前で探して panel1 に配置しています。(名前で探せるように Page1.xap、Page2.xap の中の UserControl には x:Name=”Page1” のように名前を付けてあります)

本体側でやっているのは以上です。
続いてエクスポートする Page1、Page2 側。

Page1 という名前の Silverlight アプリケーションのプロジェクトを作ります。これをビルドすると Page1.xap という名前の XAP ファイルができあがることになります。
その Page1 の XAML とコードは以下のような感じです。

<UserControl x:Class="Page1.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400"
    x:Name="Page1">

    <Grid x:Name="LayoutRoot" Background="Blue">
        <TextBlock>Page1</TextBlock>
    </Grid>
</UserControl>
using System.ComponentModel.Composition;
using System.Windows;
using System.Windows.Controls;

namespace Page1
{
    [Export("Page", typeof(FrameworkElement))]
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
        }
    }
}

見ての通りかなり簡単なものです。
MEF のためにやっていることと言えば MainPage クラスに Export 属性を付けていることだけです。
Export 属性に typeof(FrameworkElement) と書いていますが、これには意味があります。MEF では名前と型でインポート・エクスポートの解決を行うようです。Import の側が List<FrameworkElement> と FrameworkElement のコレクションになっていますので、Export する側でも typeof(FrameworkElement) として FrameworkElement 型でエクスポートすることを明示してやらないといけません。これがないと MainPage 型としてエクスポートすることになってしまい、インポートする側と型が一致しないのでインポートしてくれなくなっちゃいます。
あと、ボタンクリック時に名前で探せるように XAML の UserControl に x:Name=”Page1” を追加してあります。

Page2.xap も内容的には同じようなものです。

こんな風にすると XAP を読み込んでその中のクラスやプロパティをインポートすることができます。
今回は UserControl をエクスポートしていますが、MEF は単に 「クラスやプロパティをエクスポート・インポートする仕組み」 ですから使い方次第でいろんなことに応用できるんじゃないかと思います。

ちょっと注意
DeploymentCatalog は非同期で XAP をダウンロードします。
なので、上記のサンプルで言うと container.ComposeParts(this) を実行したからと言ってその直後に controls フィールドが更新されるとは限りません。XAP のダウンロードに時間がかかった場合には遅れて非同期で controls フィールドが更新されます。また、順序もダウンロードが速く終わった順になるようです。なので controls フィールドの内容は Page1、Page2 の順かもしれませんし、Page2、Page1 の順かもしれません。
必要であれば、DeploymentCatalog の DownloadCompleted イベントなんかを使えばダウンロード完了を知ることができます。(サンプルでは何もしない空のハンドラを指定してるだけですが)

なお、サンプルでは名前でコントロールを探すようにしているのでダウンロードに時間がかかってまだ該当するコントロールが読み込まれていない場合にもエラーにはならず単に何も表示されないだけとなります。また、名前で探すので controls の格納順も問題になりません。
ダウンロードに時間がかかるさまをテストしたい場合は Page1 プロジェクトなどに何でもいいのでサイズの大きいファイルを追加して、そのファイルのビルドアクションを 「コンテンツ」 にすればいいんじゃないかと思います。こうすると XAP ファイルにそのファイルが含まれるので XAP ファイルのサイズを簡単に大きくすることができます。

ん?あれ?
よくよく考えたら、これって非同期で controls フィールドの内容が更新されるってことだよな。
ということは何も考えずに controls フィールドにアクセスしちゃまずいってことになるな。
MEF って controls フィールドを更新するときに SyncRoot で look してくれてるのかな?そうじゃないとどうしようも無くなってしまうような気がする。うーん、どうなんだろ?

最後に
と、MEF の基本的なところと XAP を動的にダウンロードして読み込むサンプルを示してみました。
ざっくりしたものではありますが、MEF がどんなものなのかはわかって頂けるんじゃないかと。
私もよくわかってませんが、他にもいろいろとできたりします。今回は Import 属性、Export 属性を使うやり方にしましたがリフレクションベースで指定する方法もあるようです。あとは、Lazy<T> を活用するとより柔軟なインポートができるとかなんとか。。。
あっ、そうそう、メソッドを Export することもできます。この場合の Import の型は Action、要するにデリゲートで受け取ることになります。使い方によってはおもしろいかもしれません。