2017年3月20日月曜日

.NET Coreが動くまで

(なんかこのネタ、誰かがやってそうな気がしつつ)

一部ではバージョンがわかりづらいなどとも言われている .NET Core の起動の仕組みについて、適宜ソースコードを眺めつつ、整理したいと思います。私は中の人ではなく、コードを解析しながら書いているので、おかしな点がありましたら twitter 等で教えていただけると嬉しいです。

構造

ご存知のように、.NET Core は、コンパイル結果の実行可能アプリケーションまたは dotnet コマンドから実行します。
その時の動作の流れを図にすると、以下のようになっています。

この図において、長方形はファイル、角丸四角形はレイヤー、青の長方形は説明のためのグルーピングです。
この図の要素を簡単に説明すると、以下のようになります。

  • dotnet コマンド。別名 .NET CLI と言われているのはこれ(のはず)です。muxer と呼ばれることもあります。実体としては、以下の 2 つになります。
    • dotnet。Windows の場合は dotnet.exe になります。これは後述するアプリケーションランチャーです。
    • dotnet.dll。.NET CLI の本体です。.NET CLI のリポジトリにあるソースコードをビルドすると生成されます。
  • app。特定のランタイム向けに dotnet publish すると生成される実行可能ファイルです。
  • corehost。Windows の場合は corehost.exe となります。コマンドラインプログラムとしての .NET Core のランチャーです。
  • hostfxr。Windows の場合は hostfxr.dll、Mac OS X の場合は libhostfxr.dylib、Linux の場合は libhostfxr.socorehost の実体になります。
  • hostpolicy。Windows の場合は hostpolicy.dll、Mac OS X の場合は libhostpolicy.dylib、Linux の場合は libhostpolicy.so。CoreCLR ホスティング API に渡すための各種情報を初期化します。まさに、「ホスティングポリシー」です。
  • Hosting API。CLR の Hosting API の CoreCLR 版。COM に準拠した CLR の Hosting API に対して、CoreCLR の Hosting API は UNIX の関数に近い形になっています。ICLRRuntimeHost2 のラッパーとしての C 言語の関数です。
  • ICLRRuntimeHost2。CoreCLR の Hosting API の実体です。ちなみに、CLR の Hosting API は ICLRRuntimeHost インターフェイスです。

これらは、ホスティング API(ICLRRuntimeHost2 とラッパーである Hosting API)と、CoreHost(corehosthostfxrhostpolicy に加え、この後説明する dotnet も含まれます)に大別されます。

ホスティング API

ホスティング API は、その名の通り CoreCLR(.NET Core のランタイム)をプロセスにロードして、実行するための API です。.NET Core のプログラムを実行する場合、このホスティング API を何らかの形で実行する必要があります。

.NET Core の場合、以下の 4 つの関数が定義されています。ここで、文字列は、Windows の場合は ANSI、それ以外の場合は UTF-8 で渡します。

// CoreCLR を初期化。戻り値は HRESULT。
int coreclr_initialize(
    const char* exePath,                    // 実行する exe のパス。
    const char* appDomainFriendlyName,      // 初期 AP ドメインの名前。
    int propertyCount,                      // CoreCLR プロパティの数。つまり、propertyKeys と propertyValues の要素数。
    const char** propertyKeys,              // CoreCLR プロパティキー文字列の配列。
    const char** propertyValues,            // CoreCLR プロパティキー値の配列。
    void** hostHandle,                      // ホストへのハンドルが格納される(実体は ICorHost2)
    unsigned int* domainId                  // 初期 AP ドメインの ID が格納される。
);

// CoreCLR のシャットダウン。戻り値は HRESULT。
int coreclr_shutdown(
    void* hostHandle,                       // coreclr_initialize で返されたホストハンドル。
    unsigned int domainId                   // アンロードする AP ドメインの ID。
);

// 任意の静的メソッドへのデリゲートを作成し、それを呼び出すための関数ポインターを取得する。
int coreclr_create_delegate(
    void* hostHandle,                       // coreclr_initialize で返されたホストハンドル。
    unsigned int domainId,                  // 対象のメソッド(を定義する型)がロードされている AP ドメインの ID。
    const char* entryPointAssemblyName,     // 対象のアセンブリの名前。
    const char* entryPointTypeName,         // 対象の型の名前。
    const char* entryPointMethodName,       // 対象のメソッドの名前。
    void** delegate                         // 関数ポインターが格納される。
);

// アセンブリのメインエントリポイント(Main)を実行。戻り値は HRESULT。
int coreclr_execute_assembly(
    void* hostHandle,                       // coreclr_initialize で返されたホストハンドル。
    unsigned int domainId,                  // 対象のメソッド(を定義する型)がロードされている AP ドメインの ID。デフォルトドメインでなければなりません。
    int argc,                               // argv の要素数
    const char** argv,                      // Main メソッドに渡す引数の配列。
    const char* managedAssemblyPath,        // Main を定義するアセンブリへのファイルパス。
    unsigned int* exitCode                  // Main の戻り値。`void` だった場合は `0`。
);

ホスティング API の動き

ホスティング API の実装は、 C 関数版である unixinterface.cpp と、
そこから呼び出す ICLRRuntimeHost2 COM インターフェイスの実装である CorHost2 クラスです

使い方については、ホスティング API のドキュメント を参照しつつ、以下のソースコードを参照するといいでしょう。

  • corerun。CoreCLR に付属する、テスト用の簡易コマンドラインランチャーです。これを使うことで、.NET CLI の開発が追い付いていない状態でも coreclr の開発版を実行できます。
  • Azure IoT Gateway SDK .NET Core Binding。IoT のシステムで、よりセンサーに近いモノ側に配置するプログラム用(いわゆるエッジコンピューティング用)のフレームワークです。.NET Core 以外からのホスティング API の使用例として参考になるでしょう。設計ドキュメントもあるので、こちらの方がわかりやすいかもしれません。
    • 余談ですが、Node.js や Java や CLR をロードするサンプルプログラムとしても面白いかと。

ホスティング API の動きを簡単に説明すると、以下のようになります。

coreclr_initialize

  1. PAL(Platform Abstraction Layer)を初期化します。
  2. ICLRRuntimeHost2::SetStartupFlags() で初期化フラグを設定します(具体的には、*.runtimeconfig.json にある System.GC.Concurrent System.GC.ServerSystem.GC.RetainVM
  3. ICLRRuntimeHost2::Start() でランタイムを起動します。
    • 内部的には、ランタイムの起動カウントをインクリメントし、 InitializeEE() を呼び出します。
    • なお、シャットダウン済みの場合は単に失敗します。
  4. ICLRRuntimeHost2::CreateAppDomainWithManager() を使用して、以下のように AP ドメインを初期化します。
    • APPDOMAIN_ENABLE_PLATFORM_SPECIFIC_APPS を指定して、Any CPU でないアセンブリの実行を許可します。
    • APPDOMAIN_ENABLE_PINVOKE_AND_CLASSIC_COMINTEROP を指定して、P/Invoke と COM Interop を許可します。
    • APPDOMAIN_ENABLE_PLATFORM_SPECIFIC_APPS を指定して、コードアクセスセキュリティを無効化します。
    • AP ドメインマネージャーは指定しません。

coreclr_shutdown

  1. ICLRRuntimeHost2::UnloadAppDomain() で AP ドメインをアンロードします。
  2. ICLRRuntimeHost2::Stop() でランタイムを停止します。
    • 内部的には、ランタイムの起動カウントをデクリメントし、0 になったらシャットダウン済みフラグを設定します。
  3. PAL をシャットダウンします。

coreclr_create_delegate

  1. ICLRRuntimeHost2::CreateDelegate() を呼び出します。
    • 呼び出すメソッドには以下の制限があります。
    • 静的でなければなりません。
    • ジェネリックメソッドであってはなりません。
    • [AllowReversePInvokeCallsAttribute] で修飾されていなければなりません。
    • メソッドはオーバーロードされていてはいけません。

coreclr_execute_assembly

  1. ICLRRuntimeHost2::ExecuteAssembly() を呼び出します。
    • Assembly::ExecuteMainMethod() を呼び出します。
    • メタデータからエントリポイントを探し、現在のスレッドをフォアグラウンドスレッドにし、エントリポイントを実行します。

CoreHost

さて、ホスティング API は API なので、シェルから直接実行するには、何らかの CLI プログラムが必要になります。それがここで紹介する CoreHost です(正式名称ではない気がしますが、そこは目を瞑ってください)。なお、「dotnet は?」とか「publish すると実行可能ファイルが作れるじゃん」とかいう疑問はちょっとわきに置いておいてください。この後ちゃんと説明します。

CoreHost はホスティング API を呼び出す「コマンドラインランチャー」であり、「マルチプレクサー(muxer)」です……意味が分かりませんね。基本的に、このコマンドは corehost <アプリケーション.dll> <引数> という形式でアプリケーションを実行するためのものです(まさに「ランチャー」です)。

そして、以下のように、corehost の実際の動作は、状況に応じて変わります。

  • <自ファイル名>.dll ファイルがあり、かつ以下の条件を満たす場合、「スタンドアローンモード」になります。
    • <自ファイル名>.deps.json が存在する
    • <自ファイル名>.deps.json<自ファイル名>.runtimeconfig.json も存在しない
  • そうではなく、同じディレクトリに coreclr.dll(または libcoreclr.solibcoreclr.dylib)がある場合、「分離 FX モード」になります。
  • そうでない場合、Muxer モードになります。

この後、各モードの詳細について見ていきますが、もう一つ説明しておくことがあります。それは、corehost はそのままではなく リネームして使用 されるということです。
具体的には、以下のようにリネームされて使用されます。

  • <アプリケーション>[.exe]dotnet publish した結果生成される実行可能アプリケーション。
  • dotnet[.exe]。SDK のルートディレクトリに配置される、.NET CLI と呼ばれるものです。

つまり、これまで実行可能アプリケーションや dotnet コマンドだと思っていたものの実体は、単一の corehost だったということです。

それでは、それぞれのモードについて、その使われ方とともに詳細に見ていきましょう。

各モードについて

CoreHost は、前述のように、自分自身のファイル名がどうなっているかと、同じディレクトリにどのようなファイルがあるかによって 3 つのモードがあり、それぞれ動作が変わります。

分離 FX モード

これがおそらく最も基本的なモードです。コード上は split_fx というシンボルになっています。

以下のように、引数で指定された .NET Core のプログラム(マネージドアセンブリ)を実行するモードです。
dotnet <アプリケーション>.dll から実行するときのモードでもあります。

  • 第1引数で指定されたマネージドアセンブリを実行します。
  • 引数として、--depsfile--runtimeconfig をサポートします。

つまり、dotnet app.dll を実行すると、以下のように動作します。

  1. dotnet.exe という名前の corehost.exe が、分離 FX モードで app.dll を実行します。
  2. dotnet.exe はホスティング API を使用して、app.dll に定義されたエントリポイントを呼び出します。

スタンドアローンモード

これは最も基本的ではないモードなのですが、3 番目のモードが複雑なので先に説明します。

これはあたかも自分自身が .NET Core アプリケーションのように動作するモードで、コンパイルした <アプリケーション>.exe を実行するときのモードでもあります。

  • <自ファイル名>.dll という名前のマネージドアセンブリを実行します。
  • 引数として、--depsfile--runtimeconfig をサポートします。

つまり、dotnet publish で生成される app.exe を実行すると、以下のように動作します。

  1. app.exe という名前の corehost.exe が、スタンドアローンモードで app.dll を実行します。
  2. app.exe はホスティング API を使用して、app.dll に定義されたエントリポイントを呼び出します。

Muxer(マルチプレクサー)モード

これは、2 番目に基本的で、おそらく最も目にすることが多いモード、.NET CLI 用のモードです。

  • 第 1 引数が exec というコマンドが実行された場合、第 2 引数のマネージドアセンブリを実行します。つまり、分離 FX モードとして動作します(exec モード)。
  • 引数として、--fx-version--roll-forward-on-no-candidate-fx をサポートします。
  • そうでない場合、(--fx-version で指定された)coreclr 本体と同じディレクトリにある dotnet.dll を実行します
  • これは、dotnet コマンドで CLI を使用するときのモードです。
    • スタンドアローンモードで dotnet を実行する場合、CoreCLR 本体と dotnet.dlldotnet[.exe] 同じディレクトリに存在する必要があり、バージョン切り替えができなくなるのでこのようになっているのでしょう。

つまり、dotnet run app a b c を実行すると、以下のように動作します(説明を簡単にするため、アプリケーションはビルド済みとします)。

  1. dotnet.exe が Muxer モードで動作し、run に拡張子がないため、dotnet.dll を呼び出します。
  2. dotnet.dll は組み込みコマンド run を認識し、RunCommand オブジェクトを初期化します。
  3. RunCommand はプロジェクトファイルを msbuild の API でロードしします。
  4. msbuild は、RunProgram プロパティとして dotnet を、RunArgument プロパティとして exec path/to/bin/app.dll a b c を設定します。
  5. RunCommand RunProgram プロパティと RunArgument プロパティからコマンドラインを生成します。
    • つまり、dotnetexec path/to/bin/app.dll a b c を生成します。
  6. 外部プロセスとして、dotnet exec path/to/bin/app.dll a b c を実行します。
  7. dotnetcorehost)が exec モードの Muxer モードとして、ホスティング API を使用して、path/to/bin/app.dll に定義されたエントリポイントを呼び出します。

補足:CoreHost とアセンブリプロービング

.NET Core におけるアセンブリのプロービングは CLR のものとは異なります。
具体的には、ホスティング API で指定するプロパティによってその動作が変わります。
通常、ホスティング API を呼び出すのは、dotnetcorehost)になるため、プロービングの動作は、corehost の実装に依存することになります。

ざっくりいうと deps.json にない値はカレントディレクトリからロードしません。
具体的に言うと、Assembly.Load などで動的にロードする分には問題ないのですが、そのロードしたアセンブリが参照するアセンブリはロードできません。
詳細についてはこちらを参照してください

プロービングの詳細については、今回は説明しません(また機会があれば……)。
ただ、プロービングの動作がホストプログラムに依存すること、dotnetcorehost)の仕様は coreclr ではなく cli のドキュメントとして存在すること、
そして具体的な動作を調査するための corehost のコードは(なぜか)インストーラー(core-setup)のリポジトリにあることを覚えておいてください。

ランチャーの動作から言えること

これまでの説明をもとに、いくつかの動作が説明できます。

.NET Core 実行可能アプリケーションとは

スタンドアローンモードで説明したように、<アプリケーション名>.exe(Windows 以外では <アプリケーション名>)という名前にリネームされ、スタンドアローンモードで実行される corehost です。
(リネーム処理は .NET Core SDK の Microsoft.NET.Publish.targets ファイルに書かれています)

.NET CLI とは

Muxer モードで動作する corehost.exedotnet.dll に実装されたコマンドフレームワーク(と組み込みコマンド)です。

実行可能ファイルが RID(ランタイム ID)を指定した publish でしか生成されない理由

corehost は配布先のプラットフォーム依存だからですね。

dotnet と dotnet help の違い

しばやんさんのブログでの .NET Core のバージョンが難しいの中で出た、CLI のバージョン番号がよくわからないという話も、これまでの説明にちょっと引数パースの仕様を加えることで、説明できます。

  • dotnet を実行した場合、corehost の必須引数が足りないため、corehost のヘルプが表示されます。そのため、CoreCLR(のランチャーである hostfxr)のバージョンが表示されます。
  • dotnet help を実行した場合、corehost dotnet.dll help 扱いになり、CLI の HelpCommand が実行されます。そのため、.NET CLI のバージョンが表示されます。

まとめ

  • .NET Core プログラムを実行するということは、Hosting API を実行するということ。
  • 通常、Hosting API は corehost[.exe] から実行する。
  • dotnet[.exe] コマンドはリネームされた corehost[.exe] である。
  • 実行可能アプリケーションもリネームされた corehost[.exe] である。
  • corehost はその配置場所に応じて動作を変える。これによって、.NET CLI としての動作や、汎用ランチャーとしての動作、実行可能アプリケーションとしての動作を使い分けている。

参考文献

2016年12月2日金曜日

.NET Standard のおさらい

この記事は、.NET Core Advent Calendar 2016の2日目です。

あまり目新しい内容ではありませんが、.NET Standard と言われるものについて、いまいち情報が整理されていないように思うので、ここで整理してみようと思います。
結構長くなっていますので、時間のない方は まとめ だけどうぞ。

3 つの .NET Standard

個人的な分類 ですが、.NET Standard と言われているものは 3 つあると思っています。

  • 仕様としての .NET Standard
  • TPM としての .NET Standard
    • TPM(Target Platform Moniker)は、NuGet での対象プラットフォームを表す識別子です。
  • NetStandard.Library パッケージ

話をするとき、何かの記事を読むときには、今相手がどの「.NET Standard」のことを言っているのか意識するといいでしょう(xx設計とかxxテストとか、標準化されているようでその実文脈依存な用語には慣れっこですよね)

仕様としての .NET Standard

仕様としての .NET Standard は、CLI の実装系が持つ べき API のセットを定義します。あくまで べき(SHOULD) なので、実装系はその API を実装しない、または実装できないかもしれません。たとえば、.NET Standard の中には実行時 IL 生成の機能がありますが、これは AOT 環境では動作しません。実際、OS で動的コード生成が禁止されている iOS 上で動作する Xamarin.iOS はもちろん、.NET Native でも動作しません(PlatformNotSupportedException がスローされるはずです)。

この仕様としての .NET Standard は、「.NET 互換を名乗るならこのくらいの API を用意しておいてね」くらいの意味合いです。それぞれのバージョンで定義すべき API のセットはgithubで公開されています

より高いバージョンの .NET Standard をサポートするプラットフォームほど高機能と言えるでしょう。

TPM としての .NET Standard

TPM としての .NET Standard は、その NuGet パッケージがどのプラットフォームをサポートできるのかを定義します。
言ってみれば PCL(のプロファイル)の後継です。TPM で .NET Standard を宣言しているということは、2 つのことを意味します。

  • その NuGet パッケージは、宣言したバージョンの .NET Standard で定義されている標準ライブラリのみを使用して動作すること。
  • その NuGet パッケージは、宣言したバージョンの .NET Standard をサポートしているプラットフォーム用のアプリケーションから使用できること。

より低いバージョンの netdstandard TPM でビルドされたライブラリほど、サポートできるプラットフォームが多い、と言えます。

NetStandard.Library パッケージ

さて、NuGet パッケージとしての .NET Standard(NetStandard.Library)は、仕様としての .NET Standard の実装です。個人的には、このパッケージの存在が混乱の元だと思っています。
以前に .NET Fringe Japan 2016 で荒井さんが説明していたように、実体としては、.NET Core 用の実装または既存のプラットフォーム用のファサードアセンブリとなっている様々なパッケージ(System.Runtime など)を参照するメタパッケージです。

なぜこのようなものが必要になったのか、少し歴史を振り返ってみましょう。

当初、.NET Framework のクラスライブラリが出た当初、アセンブリをどう分けるかという方法論はあまりなかったように思います。事実、mscorlib と System が相互参照していたり、Queue や Stack はジェネリック版が mscorlib ではなく System にあったりします。当時は、とにかく mscorlib や System にどんどん型を載せていきました。その結果、アセンブリの肥大化やアセンブリ間の依存関係が複雑化してきてため、モダンアプリケーションの基盤となる Windows Runtime 向けのライブラリ群ではパッケージの分割が行われました。そして、.NET Core でも、パッケージ分割の方針を進めていきました。
しかし、やはりそれではアプリケーションを作るのに多数のパッケージを都度参照させる必要があるため、アプリケーション作成から見ると煩雑になりました。そのため、.NET Standard の仕様で定義された範囲内の corefx パッケージをまとめて参照できる便利パッケージとして、NetStandard.Library メタパッケージが生み出されました。これにより、.NET Standard に含まれるパッケージ群を一発で参照できるようにしたものです。

netstandard.dll

さて、この NetStandard.Library ですが、次にリリースされる .NET Core で実装されると思われる .NET Standard 2.0 では、netstandard.dll というファサードアセンブリになる予定です。つまり、NetStandard.Library がメタパッケージではなく、単一のファサードアセンブリになり、全プラットフォーム向けに提供されるようになるのです。
これが何を意味するのかについて、考察します。

興味がない場合は、次の節まで読み飛ばすことをお勧めします。

.NET Standard 2.0

さて、ここで少し未来に目を向けて、 .NET Standard 2.0 の話をしましょう。github のリポジトリMyGet からダウンロードできるパッケージをもとに、できる限り正確な内容や、それに基づく考察を述べますが、2016/12/2 時点でまだ開発中の内容であり、実際には異なる形でリリースされる可能性があります。

.NET Standard 2.0 は、最近(といっても数か月前ですが)発表された、.NET Standard の新しいバージョンです。
これまでの .NET Standard は、過去の .NET Framework Class Library(FCL)での設計上の過ちや、クロスプラットフォーム対応を考慮し、「本来あるべき」API セットを実装した corefx に対し、既存技術を対応させる形でバージョンを付けているように見えます。
その結果、.NET Standard 1.x による制約は、既存のライブラリの .NET Core 対応に対して大きな制約がありました。たとえば、

  • リフレクション API の設計改善に伴う非互換性。ライブラリやフレームワークはリフレクションを使用するものも多く、単に互換性のない API は移行の障壁となりました。
  • ADO.NET 周りのインターフェイスの廃止に伴う、既存 ORM への影響。
    これは ORM の API として使われているインターフェイスもあり、.NET Core に対応するために、実装だけでなく API の仕様も変えざるを得ないということであり、すなわちそれを利用するアプリケーションにも影響があるということです。
  • 不足する機能。たとえば CodeDOM は Roslyn によって置き換えらえる過去の技術とされていましたが、実際には言語非依存(と言っても実質的には VB と C# を同時サポート)のコード生成技術という点で、CodeDOM は Roslyn を置き換えるものではありませんでした。
  • その他既存のプラットフォームにあったライブラリ(System.Json とか、BinaryFormatter とか)

当初、パッケージ分割や API の整理による利点のメリット(たとえば API の分かりやすさ)は大きく、さらに OSS や SDK などのエコシステムは .NET Core の普及に伴い、自然と新しい API に移行する、と思われていたのでしょう。

しかしながら、.NET のエコシステムは既に想定以上に広がっていました。そして、メジャーなプラットフォームは(Unity を除けば)やはり .NET Framework であり、さらに Xamarin もベースとしている Mono が .NET Framework 互換のため、多くのライブラリは .NET Framework 用にリリースされていました。それらは当初の目論見のように付いていくことはできませんでした。彼らはそもそも毎日のように新しいサービスのために SDK をバージョンアップしたり、余暇を割いて OSS に貢献していたりして、それほど余裕がなかったのかもしれません。

そこで、これまでの欠点を補い、エコシステムを活用できるようにするため、新しい .NET Standard の仕様、実装、ライブラリである .NET Standard 2.0 が提唱されました。
(なお、現状、corefx や .NET Standard のリポジトリでは netstandard1.7 という TPM で表されています)

仕様としての .NET Standard 2.0

さて、.NET Standard 2.0 の目的を果たすためには、仕様の観点から 2 つやることがあります。

  • .NET Standard の範囲を広げ、従来の .NET Framework の API をより多くサポートすること。
  • 既存の .NET Framework 向けのライブラリを .NET Core(など)でそのまま動作できるようにすること。

.NET Standard の範囲の拡大

仕様として、.NET Standard 2.0 には以下のようなライブラリ群が追加されています。

  • BinaryFormatter と、それに伴うインターフェイスやカスタム属性。BinaryFormatter を使う機会が新規にどの程度あるのかについてはコメントを差し控えますが、[Serializable] 属性や ISerializable を実装した型(例外型など)を持つライブラリにとっては朗報でしょう。
  • DataSet。既存 ORM への配慮やもちろん、DbConnection.GetSchema() のサポートができるようになりました。DataSet を使うサーバーアプリケーションの移行先としての価値も上がったかもしれません(WebForm を使っていそうな気もしますが)。

既存ライブラリを使用可能に

.NET Standard 2.0 では、既存の .NET Framework 向けライブラリを(主に .NET Core 上で)実行できるように、FCL 互換のファサードアセンブリが追加されています。
これらは [TypeForwardedTo] 属性が大量に宣言されており、実行時に本来の FCL のアセンブリの型に転送することで、TypeLoadException などで落ちないようにする役割を持ちます。
具体的には、.NET Standard のリポジトリによれば、以下のアセンブリです。

  • mscorlib
  • System
  • System.ComponentModel.Composition
  • System.Core
  • System.Data
  • System.Drawing
  • System.IO.Compression
  • System.IO.Compression.FileSystem
  • System.Net.Http
  • System.Numerics
  • System.Runtime.Serialization
  • System.Web
  • System.Xml.Linq
  • System.Xml

ここにないものは対応していないか、または拡張パッケージということになります。Windows に強く依存している機能(を使うライブラリやアプリケーション)なので、.NET Standard に移行するモチベーションもないだろうということなのでしょう。たとえば、System.EnterpriseServices、ADSI.NET 周りはありません。レジストリや WMI.NET のカスタム属性、CodeDOM や System.Transactions などは、使用頻度が多いからか、拡張ライブラリとして別途互換パッケージが提供されるようです。リポジトリ を見る限り .NET Remoting や Code Access Security もあるようですが、.NET Core で実装される可能性は低いと思われます(もっとも、coreclr のリポジトリを見ると、ランタイムの中に .NET Remoting や Code Access Security 用のコードがそのまま残っているように見えますが)。

TPM としての .NET Standard 2.0

これは素直に netstandard2.0 になると思われます。

corefx の内容を見る限り、新しく corefx に加わる拡張ライブラリ群は netstarndard2.0 向けになるようなので、新しく実装が加わったパッケージに依存するライブラリやフレームワークはこの TPM を使うことになるでしょう。たとえば MS-DTC を使わずに XA トランザクションを実装するライブラリとか、業務アプリケーション用の社内フレームワークとか。拙作 MsgPack for CLI も、CodeDOM を使ったソースコード生成を別パッケージに切り出し、Mac 上の開発環境や Linux 上の CI 環境などでもソースコード生成ができるようにしようと考えています(今でも mono で動かしてもらえば問題なく動くはずですが、古いバージョンだったりするとうまく動かないこともあるようです)。

ORM や Data Provider も、netstandard2.0 向けビルドにしてより多くの API が(.NET Framework 向けビルドと同じくらい)提供されるようになるでしょう。

パッケージとしての .NET Standard 2.0

これまではメタパッケージでしたが、これからは netstandard.dll というファサードアセンブリが提供されるようになる予定です。

なぜでしょうか。blog や github の説明だけだといまいちよくわかりませんが、現状 MyGet に出ているパッケージやソースコードも併せて見ると、以下のようなものと考えられます(あくまで解釈です)。

新規にビルドするアプリケーションが、既存のライブラリを活用するとしましょう。しかも、ライブラリのうち、あるものは .NET Framework 向け、別のものは .NET Standard 1.x 向けにビルドされていたとしましょう。.NET Standard 2.0 なら、それらの両方の API をサポートしているため、すぐに両方が使えるようになる……と言いたいところですが、そうはなりません。なぜならば、使用している型のアイデンティ(ここでは、アセンブリ名と名前空間と名前の組み合わせ)が異なるからです。
たとえば、それらのアセンブリが、System.String を受け取るインターフェイスを持っていたとします。.NET Framework 向けのライブラリは、System.String は(ILDasm 風に書くと)mscorlib!System.String 型だと主張し、.NET Standard 1.x 向けのライブラリは System.Runtime!System.String 型だと主張するでしょう。そうすると、型のアイデンティティが異なるので、片方から返された System.String をもう片方のライブラリに渡せないことになります。
これでは実用になりません。これを解決するために、新しい .NET Standard 2.0 のパッケージには、以下のものが含まれています。

  • FCL 互換の Facade アセンブリ。これらは大量の [TypeForwardedTo] を持ちます。その転送先は netstandard.dll です。
  • 現在の NetStandard.Library メタパッケージに含まれているのと同じ名前の Facade アセンブリ(System.Runtime など)。これらも大量の [TypeForwardedTo] を持ちます。その転送先は netstandard.dll です。
  • netstandard.dll。なお、API の宣言のみがあり、実装はありません。

この仕組みにより、アプリケーションのビルド時には .NET Framework 用のライブラリが主張する型も、.NET Standard 用のライブラリが主張する型も、netstandard.dll にフォワードされます。つまり、先ほどの例で言えば、アプリケーション(のアセンブリ)は、「結局どちらも netstandard!System.String のことを言っているんだな」と解釈します(そのように TypeRef が解決されるはずです)。

現在のところ、MyGet からダウンロードできる、この新しい NetStandard.Library パッケージには実装(つまり lib フォルダー)がありませんが、.NET Standard のリポジトリや MSDN Blog の記事を見る限り、何らかの方法で、以下のような実行時の型転送用の netstandard.dll が提供されると想定されます。

  • .NET Framework や Xamarin 向け
    • FCL のアセンブリへの [TypeForwardedTo] を大量に持つ、.NET Framework や Xamarin 向けにビルドされたアセンブリの実行用の netstandard.dll
    • netstandard.dll へのアセンブリへの [TypeForwardedTo] を大量に持つ、.NET Core 向けにビルドされたアセンブリの実行用の System.Runtime.dll 等のアセンブリ群(最終的には mscorlib.dll などに転送されます)。
  • .NET Core や UWP 向け
    • corefx のアセンブリへの [TypeForwardedTo] を大量に持つ、.NET Core や UWP 向けにビルドされたアセンブリの実行用の netstandard.dll
    • netstandard.dll へのアセンブリへの [TypeForwardedTo] を大量に持つ、.NET Framework や Xamarin 向けにビルドされたアセンブリの実行用の mscorlib.dll 等のアセンブリ群(最終的には System.Runtime.dll などに転送されます)。

具体的に言うと、実行時、アプリケーションアセンブリを JIT コンパイルする(ために型をロードする)タイミングで、ランタイムのタイプローダーが netstandard!System.String を、mscorlib!System.StringSystem.Runtime!System.String としてロードするわけです。そして、この動作は、参照先のライブラリアセンブリ内のコードが JIT コンパイル/型ロードされる場合も同じです(こちらは、いったん netstandard に転送された後、再転送されるでしょう)。

アプリケーション開発者が知っておくべきこと

アプリケーション開発者が考えるべきことはシンプルです。
「で、結局どれが使えるの?」
これだけですよね。

一覧表を見ればわかりますが、ざっくりいうとこんな感じです。

  • .NET Core と Xamarin で動けばいいよね!
    • netstandard 対応であればどんなライブラリでも動きます。
  • 最新のサーバーで動けばいいや。
    • netstandard1.5 まで行けます。.NET Framweork 4.6.1 ならサポートできるからです。
  • UWP です。
    • netdstandard1.4 まで行けます。
  • .NET 4.6.0 をサポートする必要があるんだよね。
    • netdstandard1.3 まで使えます。
  • .NET 4.5.1 をサポートする必要があるんだよね。
    • netdstandard1.2 まで使えます。
    • Windows 8.1(Phone を含む)をサポートする必要がある場合も同じ。
  • .NET 4.5.0 をサポートする必要があるんだよね。
    • netdstandard1.1 まで使えます。
    • 実は Windows 8.0 があって……という場合も同じ。
  • Windows Phone Silverlight 8.0 です。
    • netdstandard1.0 なら使えます。
  • Unity|.NET 3.5|Silverlight5です。
    • 使えません。

また、.NET Core アプリケーションから、従来の .NET Framework 向けのライブラリを使うことはできません。.NET Standard と互換性のある PCL なら大丈夫ですが、パッケージの依存関係によっては PCL 同士の相性がかみ合わない
(もう少し正確に言うと、対象バージョンフラグの論理積が空になり)場合など、うまくいかないことがあります。

そうすると結構なライブラリ(Azure 系の SDK とか)が使えなくなるので、先ほど述べたように .NET Standard 2.0 が実装されようとしているのでした。

あと、標準ライブラリのうち、どのパッケージを参照すればいいの? という問いに対しては、dotnet new で作られる project.json(今後は csproj)では、前述の NetStandard.Library パッケージを間接的に参照している状態で作成されるため、大体の場合は気にしなくていいはずです。

ライブラリ開発者が知っておくべきこと

ライブラリ開発者が考えるべきことは、いかに多くのユーザーに使ってもらえるかです。素敵なライブラリを作ったとしても、多くのユーザーに使ってもらえなければ意味がありません。そのため、これから作成するのであれば、netstandard1.x の、しかもできる限り小さなバージョンでビルドしましょう。

さて、ここで残念なお知らせがあります。

今や .NET ユーザーの大多数を占める(と思われる)Unity ですが、ご存知のように、.NET 3.5 互換です(2016/11/30 現在)。つまり、たとえ netstandard1.0 向けであっても、Unity では動きません。Unity 向けのライブラリを作りたい場合は、素直に .NET 3.5(正確には Mono 2.6)で動くライブラリを .NET 3.5 用にビルドしましょう。ただし、希望はあります。(Mono ランタイムが MIT ライセンスになったこともあり)Unity は .NET 4.6 相当の機能が使えるように改善を計画中で、.NET Standard への対応を進めているようです。あなたのライブラリの開発が終わり、netstandard 環境で十分に有名になったころには、Unity も追いついているかもしれません。

これだけだと何なので、netdstandard1.x の選び方の簡単な基準を書いておきます。

  • 純粋なアルゴリズムのみのようなライブラリであれば、netstandard1.0 にできるでしょう。
  • そうでなくても、多くの場合、netstandard1.1 でビルドできるでしょう。ZIP、HTTP 通信、同時実行コレクションなどがサポートされます。
    • netstandard1.2 は P/Invoke 用の API やタイマーなど多少増えていますが、大差ありません。最も、1.1 は使えるが 1.2 は使えないプラットフォームは .NET 4.5.0 と Windows 8.0 なので、1.1 にする積極的な理由もないかもしれません。
  • 外部プロセス、標準入出力、ファイル入出力などが必要な場合、netstandard1.3 が必要になるでしょう。ただし、.NET 4.5 系はサポートできません。
    • netstandard1.4 は楕円曲線暗号が追加されています。
  • リフレクションを多用する既存ライブラリを .NET Standard 対応にする場合、netdstandard1.5 にすると、多くの API を使用できます。ただし、netstandard1.1 向けであっても、同等の機能は存在しているので、互換レイヤーなどを実装してしまうのも手です。
  • .NET Core でだけ動けばいいのであれば、ケチケチせずに netstandard1.6 にしましょう。Xamarin も大丈夫です。

迷ったなら、netstandard1.3 にしておけばとりあえず問題ないと思います。

なお、netstandard2.0netdstandard1.4 をサポートするプラットフォーム(.NET 4.6.1、UWP、Xamarin、.NET Core)で使用可能になる見込みです。.NET Standard 2.0 が出た暁には、.NET 4.6.0 や Windows Phone 8、Windows 8.x アプリをサポートするのでない限り、netstandard2.0 にしてもいいでしょう(そうすると、netstandard1.5netdstandard1.6 とは何だったのか、という話になりますね……)。

まとめ

  • .NET Standard には 3 つの側面があります。仕様としての .NET Standard、TPM としての .NET Standard、そしてパッケージとしての .NET Standard です。
    • 仕様としての .NET Standard は、CLI の実装系が持つ べき API のセットを定義します。
    • TPM としての .NET Standard は、その NuGet パッケージがどのプラットフォームをサポートできるのかを定義します(PCL の後継)
    • NuGet パッケージとしての .NET Standard は、仕様としての .NET Standard の実装です。
      • 実体としては、.NET Core 用の実装または既存のプラットフォーム用のファサードアセンブリとなっている様々なパッケージ(System.Runtime など)を参照するメタパッケージです。
      • .NET Standard 2.0 では、netstandard.dll というファサードアセンブリになる予定です。
        • それにより、既存の .NET Framework 向けライブラリと、最近の .NET Standard 向けライブラリの両方を、.NET Standard で動作するアプリケーションで使用できるようになるはずです。
  • アプリケーション開発者として知っておくべきこと
    • .NET 4 以降、Xamarin、.NET Core、UWP や Windows Phone アプリケーションは、それぞれのプラットフォーム向けのライブラリに加え、アプリケーション プラットフォームがサポートするバージョンの .NET Standard 用にビルドされたライブラリを使用できます(もちろん対応する PCL も)。
    • .NET Standard 2.0 では、既存の .NET Framework 向けの NuGet パッケージ(つまり、.NET Standard 向けとしてビルドされていないパッケージ)も、.NET Standard 2.0 をサポートするパッケージであるかのように使うことができます。
      • たとえば、ASP.NET Core から、(.NET Core 向けの実装のない)Azure の PaaS の SDK なんかを参照できます。
    • .NET Standard 2.0 リリース後、多くのパッケージは .NET Standard 2.0 対応となることが予想されます。.NET 4.6.1(以降)への移行を計画しておくとよいでしょう。
  • ライブラリ開発者として知っておくべきこと
    • これから開発するのであれば、netstandard1.x 向けのものを作るべきです。
      • このとき、x はビルドできる最小のバージョンにすべきです。
    • 既に .NET 4.5 以降で動作するライブラリを持っているけれども、netstandard1.x に対応するのに躊躇している場合、.NET Standard 2.0 を待つのも手です。
      • おそらく、そのライブラリは netstandard2.0 向けのパッケージと同じように使えるはずです(もちろん、OS やランタイム依存の処理がある場合を除く)
    • Unity はあきらめましょう。ただし、希望はあります。

気付けばかなりの長文となっていますが、現時点での内容を整理すると以上になります。
それでは、happy hacking。

2016年10月4日火曜日

マルチプラットフォーム対応のNuGetパッケージの作り方

まず、2016/10/4 現在、NuGet Docs サイトはリニューアルされ、かなり見やすくなってますので、ぜひそちらも参照ください。
昔のサイトもそれほど読みにくくはありませんでしたが、色々と情報が増えてどこを見ればいいのかわからない感じだったのも事実です。なので、個人的にはかなり良くなったと思います。 全文検索もできますし。
たとえば、docs.nuget.org のトップページにある「Guides」には目的別のガイドラインがありますし、クイックスタート的な記事もあります。このあたりを見れば結構何とかなるはずですし、リファレンスもメニューからたどることができます。
さて、その公式ドキュメントを見ればマルチプラットフォーム対応のやり方もわかると思います。色々書いてありますが(<file src> とか初めて知った)、ようは以下のようにすれば OK です。
  • .nupkg ファイル生成のソースとなるディレクトリツリー内の lib の下に、ターゲットプラットフォームを表す名前(TPM:Target Platform Moniker)のディレクトリを切り、そこに .dll と、IntelliSense 用の XML ドキュメントコメントファイルを入れます(XML 入れなくてもかまいません)
  • 依存先のパッケージがある場合、.nuspec/package/dependencies 要素の下に、TPM ごとに <group targetFramework="{TPM}"> 要素を対象の TPM ごとに記述します。この子要素として、依存先のパッケージを <dependency id="{パッケージの名前}" version="{バージョン}" /> といった具合に書いていきます。
  • .NET Standard 用の TPM を含む場合、サポートしていない古いバージョンの NuGet でよくわからないエラーが出ることがないように、/package/metadata 要素に minClientVersion="2.12" と記述します(これ、docs.nuget.org に書いてませんね……)
参考までに、MsgPack for CLI の .nuspec ファイルはこちら
ちょっと文字ばかりでわかりづらいでしょうか。実際に展開した .nupkgtree /F した結果はこんな感じです。
C:.
│  MsgPack.Cli.nuspec
│  [Content_Types].xml
│
├─lib
│  ├─MonoAndroid10
│  │      MsgPack.dll
│  │      MsgPack.xml
│  │
│  ├─net35-client
│  │      MsgPack.dll
│  │      MsgPack.XML
│  │
│  ├─net45
│  │      MsgPack.dll
│  │      MsgPack.XML
│  │
│  ├─net46
│  │      MsgPack.dll
│  │      MsgPack.XML
│  │
│  ├─sl5
│  │      MsgPack.dll
│  │      MsgPack.XML
│  │
│  ├─windowsphone8
│  │      MsgPack.dll
│  │      MsgPack.XML
│  │
│  └─Xamarin.iOS10
│          MsgPack.dll
│          MsgPack.XML
│
├─package
│  └─services
│      └─metadata
│          └─core-properties
│                  d502c190230a45328393d9c274cf792e.psmdcp
│
└─_rels
        .rels
ターゲットモニカについては、公式ドキュメント を参照してください。
Xamarin についてはちょっとわかりづらいですが、上記の例の記述で動くはずです。なお、monotouch が旧形式の Xamarin iOS、Xamarin.iOS が Unified app 版になります(Xamarin のドキュメント)。なお、旧形式については、Xamarin iOS の 10.0 からサポートされていません
さて、実際に作る際には、以下のようにするといいでしょう。
  • 実際に対応している OSS パッケージのディレクトリ構造や .nuspec ファイルを参考にする。私は JSON.NET や CoreFX のパッケージを参考にしました。
  • ローカルのディレクトリに配置して、動作を確認する。なお、v3 の場合、配置先のディレクトリを nuget init しておき、nuget add でパッケージを追加する必要があります。また、前に試した時、ローカルディレクトリは Windows でしかうまく動作しませんでしたが、最近は変わったかもしれません。
それでは、happy hacking!

.NET Fringe Japan 2016でしゃべりました

少し間が空いてしまいましたが、先週末、.NET Fringe Japanというイベントで(珍しく)しゃべってきました。当日のスライドはこちら

内容としては、まずは準備運動よろしく F# の話から始まり、C# の言語機能への提案方法まさかの .NET じゃない話Xamarin ソースの見方の Deep DiveOSS 開発のためになる話 と続いていき、日が沈むとともに IL を追加する方法の話 に行ったときにはどうなるかと思いましたが、最後は地に足の着いた deep dive でうまく終わりました。いや、松井さん最高です。正直あまり運営のお手伝いはできなかったのですが、色々な人の助けもあり、成功に終わったのかなと思います。いやー、みなさんコンテンツもしゃべりも上手で、そちらの方でも勉強になりました。

セッションスケジュール的には、ちょっと詰め込みすぎでしたかね。ただ、初回ということで、こんなマニアックな会で本当に人が集まるのか、という懸念もあり、1 トラックでまずはやってみようという話になったのでした。雨で、かつ色々と楽しそうな裏番組があった中で 100 人近い来場者があったので、次回は 2 トラックくらいにできるのかもしれません。

さて、私も好き勝手しゃべったわけですが、荒井さんのセッションの質問とか、懇親会での話とかを考えると、そもそもマルチプラットフォーム対応の NuGet パッケージの作り方を普通に説明すればよかったのでは、と気づいたので、一筆書こうと思います。そんなの日本語で話しても需要がないだろうと思っていたのですが、あそこはそういうことをする人たちの集まりなのでした :)

あと、あのメンツはどう見ても亜流とかいう生易しいものじゃなくて過激派グループだと思います

2016年6月24日金曜日

DispatchProxyのPRを送ってみた

前回の続きです。

というわけで、.NET Core の、System.Reflection.DispatchProxy が返すオブジェクトからなぜかプロパティとイベントが取れない問題があって、さすがにこれはどうかなと思ったので、PRを送ってみたので、その顛末でも書きます。ほとんどポエムです。

問題の解説

そもそも、

IFoo foo = DispatchProxy.Create<IFoo, SomeProxy>();
foo.Bar = "ABC";

みたいなコードがコンパイルされ、動作するのに、

foo.GetType().GetRuntimeProperty("Bar");

nullを返すのはなぜでしょうか?
それは、fooオブジェクトの実態である動的に生成された型が、プロパティ(やイベント)のアクセッサーメソッドのみを実装してプロパティやイベントを宣言していないからです。
前回の記事をよく見ると、

動的に生成したクラスに、インターフェイスが宣言しているすべてのメソッドを宣言します。

と書いてありますね。 そう、DispatchProxy.Create<T, TProxy>()は動的に生成した型にアクセッサーメソッドを実装するだけで、それらが属するプロパティやイベントを型で宣言させないのです(もう少し内部的な話をすると、動的に生成されたプロキシ型のメタデータテーブルにプロパティとイベントのエントリを書き出さないということです)。
しかもなんと、インターフェイスを実装した型では、そのインターフェイスのプロパティやイベントのアクセッサーメソッドさえ宣言されていれば、プロパティやイベントは宣言しなくても動作するのです(これが動作するのが正しいかどうかという話はありそうですが)。
C# が出力するのはアクセッサーメソッド呼び出しのILですからちゃんとコンパイルでき、かつ動作するのですが、プロパティやイベントが宣言されていないので、リフレクションでプロパティやイベントそのもののメタデータは取れないというわけです。

ポエム

これだとちょっと困るので、DispatchProxyGenerator の中で、プロキシ型にインターフェイスのプロパティとイベントを宣言させるようにしたPRを送ったよという話です。
ちなみに、diffを見ながらじゃないとついていくのがつらいと思います。

第0の関門:どう実装するか

TypeBuilder.DefineProperty()DefineEvent()ですね。あと、アクセッサーメソッドをPropertyBuilderEventBuilderに設定する必要があります。
なぜかこの辺のAPIは頭に入っているので、実装はあっさり終わりました。

第1関門:設計意図

意気揚々と直しましたが、そういえば、そもそもこれって意図的にプロパティやイベントを実装していないのかもしれません。
なので、とりあえずissueをあげて様子を見ました。
きっとRTM前で忙しいでしょうし、ということで、10日くらい待ちました。
で、音沙汰もないうちにリリース1週間前になり、よく見ると依存先のバージョンがrc3からrc4になってるし、これはもう1.1向けの開発モードになってそうだなということで、「何か問題あるかな? なさそうなら実装持ってるからPRできるよ」って聞いてみたところ、「急いで入れる必要ないよね? 実際に直し始めたら色々聞きたくなると思うけど、他にやることあるからちょっと待ってー」って言われて、「ていうか直したんだったらもうPR投げていいよー」と言われたので、PRすることにしました。

第2の関門:ビルドと単体テスト

PRを出すには、当然単体テストを実行しなければなりません(追加のテストは既に書いたものとします)。
ところが、corefxのプロジェクトは少々特殊なproject.jsonになっているので、素直にビルドできません。
corefxのドキュメントを読めばいいのですが、1.0 RC2 時点で、Windows環境でビルドするには以下のようにします。Visual Studio(ライセンス的に問題がない限り、無料のCommunity Editionでも大丈夫のはずです)が必要です。

  1. Visual Studio 2013の MSBuild へのパスが通っているコマンドプロンプトを開きます(「開発者コマンドプロンプト」とかそういうやつです。ちなみに、私はVS 2015用でやりましたが、問題はありませんでした)。
  2. corefxのルートにある、init-tools.cmdを実行します。
  3. 修正したコードのテストプロジェクトのディレクトリに移動し、msbuild /t:BuildAndTestを実行します。

ちゃんとドキュメントを読んでいればなんてことない話でした。

あと、実は初めてのPRだったのでちょっと戸惑ったり、CLAへの署名とかもありましたが、特に躓きはありませんでした。

第3の関門:レビュー

主にvarの使い方でダメ出しをくらいました。「型が明確な場合を除きvarを使わない」とありますが、これは「コンストラクター呼び出しの結果を割り当てる場合を除き」くらいのニュアンスだったようです。
他には、

  • 変数の宣言位置(実はリファクタリングしたときの修正漏れ)
  • ifの本体の改行位置(普段は中括弧必須派なので、うっかり)

などのポカミスが多かったです。正直手間を取らせて申し訳ない。
そして、次の関門。

第4の関門:MethodInfo.Equalsの罠

MethodInfo.Equalsは.NET Core だと参照比較として実装されているから、MethodInfoDictionaryのキーにしちゃダメよー」というありがたい突っ込みをいただきました。
(.NET メタプログラミング界隈の人たちが青ざめる姿が見えた気がしました)
MetadataToken比較するようなEqualityComparer作ればいいと思うYo」とのアドバイスをもらったので、それはそもそも.NET Coreに入っているべきではと思いつつ、それを英語で記述するよりは C# でコードを書く方が早いので書きました。確かに、メタデータテーブルのインデックスであるMetadataTokenを比較するのは確実で、かつ高速な手段ですしね。

第5の関門:netstandard1.3

はい。MemberInfo.MetadataTokenはnetstandard1.5のAPIなのです(.NET Framework側には昔からありますが)。System.Reflection.DispatchProxyは1.3用のライブラリなので、MetadataTokenは使えません。
なので、愚直に名前とパラメーターの型を比較する実装にしました。

第6の関門:ジェネリクス

意気揚々とプッシュしたEqualityComparer<MethodInfo>実装について、「この比較だとジェネリック型引数見てないからダメじゃね?」という真っ当な指摘を受けました。その通りですね。
ついでに「ECMAがどうかわからないけど、静的メソッドかインスタンスメソッドかも比較しないとまずいんじゃないかなー」と言われたので、ECMA-335を見てみました。
そのものずばりのところはないのですが、「I.8.6.1.6 Signature Matching」を見る限り、

  • 静的メソッドかインスタンスメソッドは比較すべき
  • 戻り値の型も比較すべき
  • 呼び出し規約(CallingConvention)も比較すべき

と判断し、これの真偽(実はいらないんじゃないか)を確かめるよりこの通り実装した方が早いので、実装しました(DispatchProxy.Create()をループの中で呼び出して遅いとかいう人はいないでしょうし、そもそも動的コード生成やJITコンパイルに比べたら大したことないでしょうし)。

第7の関門:raise

ここで、「そういえば、イベントのaddメソッドとremoveメソッドは割り当ててるけど、raiseメソッドも割り当てないとダメじゃないかな」という発言が出ました。こいつ、気付きやがった……。同時に「じゃあotherはどうする?」って聞き返そうかと思いましたが、.NET Coreにotherメソッドを割り当てるためのAPIないし、0x20歳を過ぎた大人なので藪蛇になることは言わないことにしました。

とはいえ、C#コンパイラにraiseメソッドを出力させる方法はありません。つまり、テストコードで動的型生成をしないと行けないということです。それは正直ちょっとやりすぎかなーと思った(この後保守するのが面倒になるんじゃないかなと思った)ので、「ほんとにやる?」って返信して、寝ました。もう丑三つ時回ってましたし。

翌日、仕事から帰ってきたところ、ノーレスだったので、四の五の言わずにやれや、ということだと判断し、あきらめて実装しました。実装はECMA-335を見ながらやったのですが、raiseメソッドのシグネチャはvoid raise_xxx(Event e)でなければならないとか書いてありつつ、Eventが何なのかは一切説明がありませんでした。ただ、普通に考えればイベントハンドラーに渡すデータでよかろうということで、適当にEventArgsを渡すようなメソッドを生成させました(これを書いていて思ったのですが、イベントの型は任意のデリゲートになり得るで、EventArgsではないような気はしますね。じゃあ何なのかというと謎ですが、テストでコード生成例外は起きてないし、所詮テストコードの動作の話なので良しとしましょう)。

あと、このためにテストプロジェクトからSystem.Reflection.Emitパッケージへの参照を増やす必要がありました。

第8の関門:dotnet-bot

10日間も間を開けたのは失敗でした。そう、1.1開発モードにシフトしているので、依存先パッケージのバージョンがガンガンアップデートされていきます(いつの間にかrc4betaになってました)。
そう、raise_メソッドのテストのためにテストプロジェクトのproject.jsonをいじっているので、botによって依存先パッケージのバージョンが書き換わると、修正がコンフリクトするのです。具体的には、変更をプッシュして「コンフリクトがないからマージできるよ」ってGitHubに言われても、数時間のうちにコンフリクト状態になってしまう状態でした。
ところが、レビューしてくれた人たち以外は忙しいのか何なのか、LGTMが増えず、マージされません。
コンフリクトのまま放置していもレビューしてくれなさそうなので、仕事から帰ったらマージして再プッシュとかしてみたものの、毎日再プッシュされてもレビューする側は嫌だと思うので、「毎日project.jsonマージしなおして上げなおしたらうざいと思うんで、レビューできる状態になったら教えて。そのときまとめて再プッシュするから」と言ったら、「いや、もう何も言わないってことはいいってことでしょ」と言われ、マージされたわけです。

結論

  • corefxの「varは控えめ」は本当に控えめ。
  • さすがにレビューはしっかりやってる
  • project.jsonいじると頻繁にマージコンフリクトするから気を付けよう

感想としては結構楽しかったです(レビューコメントの英語も勉強になりましたし)。

余談

レビューしてくれた人、日本人っぽい名前だったのですが、日本時間の23:00(シアトルは7:00)台にレスくれるので、早起きなのか、日本にいる人が夜中に対応してくれてたのかがよくわからず。
いずれにせよ、深夜早朝に丁寧な対応ありがとうございました。

DispatchProxy

.NET Core には、System.Reflection.DispatchProxy という型が追加されています。
こいつが何かというと、インターフェイスベースの AOP を実現するプロキシを生成するための仕組みです(Java の Proxy に近いといえばわかる人もいるでしょうか)。
DispatchProxy を使用して特定のインターフェイスのプロキシを作成すると、返されたオブジェクトに対するメソッド呼び出しに対する割り込みがかけられるようになります。

この説明でピンと来る人はいないでしょうから、もう少し丁寧に説明していきます。

使い方

まず、割り込み処理を実行するプロキシクラスを作ります。これは、System.Reflection.DispatchProxy 抽象クラスを継承したクラスです。
基底型である DispatchProxy クラスには、以下のような抽象メソッドが定義されています。

protected abstract object Invoke(MethodInfo targetMethod, object[] args);

どう見ても、メソッド呼び出しに割り込んで、処理を実装しろと言っていますね。この中で、

  • 割り込み処理を行う
  • 本来のディスパッチ先のメソッドを呼び出す
  • メソッド呼び出しの戻り値を返す(targetMethod の戻り値型が void なら null で OK)

などをすればOKです。
後は、やりたいことに応じて、このプロキシにプロパティやメソッドを生やしてください。
ただし、このプロキシ型はpublicでなければならず、さらにpublicなデフォルトコンストラクターが必要です(後述しますが、つらい)。
そして、DispatchProxy.Create<T, TProxy>() 静的メソッドで、プロキシ型のインスタンスを作成します。このとき、任意のインターフェイス型と、先ほど作成したプロキシ型を指定します。

IMyModel obj = DispatchProxy.Create<IMyModel, MyAopProxy>();

この戻り値のobjのメンバーを呼び出すと、MyAopProxyInvoke(MethodInfo,object[])が呼び出されます。やった。

さっそく例を見てみましょう。
昔から、AOPと言えばトランザクション管理とログ出力と相場が決まっています。
たとえば、IMyModelというインターフェイスと、実装であるMyModelがあり、呼び出しのトレースを出力する TracingAopProxy を作るとしましょう。
まず、プロキシクラスを以下のように記述します。追加のプロパティはAPからは呼んでほしくないので、internalにしてます。

public sealed class TracingAopProxy : DispatchProxy
{
    // トレース出力先
    private TraceSource _trace;
    // 実際の処理を行うオブジェクト。
    private object _model;
    // インターフェイスメソッドと
    private Dictionary<MethodInfo, MethodInfo> _dispatchTable;

    public TracingAopProxy() { }

    // コンストラクターが引数を宣言できないので、初期化メソッドを用意。
    internal void Initialize(Type interfaceType, object model, string sourceName)
    {
        _model = model;
        _trace = new TraceSource(sourceName);
        _dispatchTable = new Dictionary<MethodInfo, MethodInfo>(new MethodInfoEqualityComparer());
        foreach (var method in interfaceType.GetRuntimeMethods())
        {
            // .NET Core には GetInterfaceMap() が実装されていないので、頑張って比較。
            // 厳密にやるなら、ReturnType と CallingConvention も。
            // インターフェイスの明示的な実装とかあるので、public メソッドかどうかは問わない。
            var target = model.GetType().GetRuntimeMethods().Single( m =>
                             m.Name == method.Name
                             && m.GetGenericArguments().SequenceEqual(method.GetGenericArguments())
                             && m.GetParameters().Select(p => p.ParameterType).SequenceEqual(method.GetParameters().Select(p => p.ParameterType))
                         );
            _dispatchTable.Add(method, target);
        }
    }

    protected override object Invoke(MethodInfo targetMethod, object[] args)
    {
        _trace.TraceEvent(TraceEventType.Verbose, "Enter: {0}", targetMethod);
        try
        {
            var result = _dispatchTable[targetMethod].Invoke(_model, args);
            _trace.TraceEvent(TraceEventType.Verbose, "Success: {0}", targetMethod);
            return result;
        }
        catch(TargetInvocationException ex)
        {
            _trace.TraceEvent(TraceEventType.Error, "Error: {0}", ex.InnerException);
            throw;
        }
    }

    // .NET Core では MethodInfo.Equals が参照比較で、うまく比較できないことがあるので必要
    private class MethodInfoEqualityComparer : EqualityComparer<MethodInfo>
    {
         public MethodInfoEqualityComparer() { }

         public override bool Equals(MethodInfo left, MethodInfo right)
         {
              return left?.MetadataToken == right?.MetadataToken;
         }

         public override int GetHashCode(MethodInfo obj)
         {
              return (obj?.MetadataToken.GetHashCode()).GetValueOrDefault();
         }
    }
}

で、以下のようなラッパーメソッドを作ってあげればOKです。

public static T WithTrace<T, TImpl>(TImpl model)
    where TImpl : T
{
    var proxy = DispatchProxy.Create<T, TracingProxy>();
    ((TracingProxy)(object)proxy).Initialize(typeof(T), model, "the.source");
    return proxy;
}

ここでのポイントは、DispatchProxy.Create<T, TProxy>() の戻り値の型は T 型ですが、同時に TProxy の派生クラスでもあるということです。
そのため、TProxy 型にキャストすることで、追加の初期化処理を呼び出すことができます(上記の例では、C# コンパイラーをごまかすために、いったんobjectにキャストしています。理由は本筋ではないので割愛します)。

内部動作の説明

DispatchProxy.Create<T, TProxy>() は、ざっくりいうと以下のような処理をやってくれます(他にも細かいことをいろいろやっていますので、興味のある方はソースを見るといいでしょう)。
1. TProxy クラスを継承したプロキシクラスを動的に生成します。
2. 動的に生成したクラスに、指定したインターフェイス(T型)を実装させます。
3. 動的に生成したクラスに、インターフェイスが宣言しているすべてのメソッドを宣言します。
4. 現在のメソッド情報をMethodInfoとして取得するILを出力します。
5. 実引数を格納するobject[]をインスタンス化するILを出力します。
6. 実引数をobject[]につめるILを出力します。
7. Invoke(MethodInfo, object[])を呼び出すILを出力します。
8. メソッドが戻り値を持つ場合、Invoke(MethodInfo, object[])の戻り値をキャストして戻します。

注意点

  • プロキシ型はpublicである必要があります。ライブラリやフレームワークを作るお仕事の人は「まじかよ……」と思ったかと思いますが、そう思った方は我慢せずにIssueを投げてみるといいと思います(自分は、後述するように他にもっと気になったことがあったので投げてないです)
  • 巷のよくある AOP の仕組みと同様に、インスタンスメソッドだけに割り込めます。
  • プロキシ型のInvoke(MethodInfo, object[])の実装によりますが、上記の例のように素直に実装してしまうと、呼び出し先で発生した例外がTargetInvocationExceptionになったりして透過的な割り込みではなくなります。気を付けましょう。式木か何かでMethodInfo.Invokeせずに呼び出すとか。
  • DispatchProxy.Create() で返されたオブジェクトに対してリフレクションを実行した場合、なぜかインターフェイスが実装しているはずのプロパティとイベントの情報が取れません。
    たとえば、
public interface IFoo
{
    string Bar { get; set; }
}

というインターフェイスに対して、

IFoo foo = DispatchProxy.Create<IFoo, TracingAopProxy());

とすると、

foo.Bar = "A";

というコードは(もちろん)コンパイルするし動作するにもかかわらず、

foo.GetType().GetRuntimeProperty("Bar")

nullを返します。なので、このオブジェクトをリフレクションベースのツールやライブラリに渡すと、うまく動作しないかもしれません。
対処方は今のところありません(次回に続く)

2013年12月19日木曜日

.NET の動的コード生成技術の紹介

この記事は C# Adventcalendar 2013 の記事です。この記事では、ちょっとだけ濃い目に、MsgPack for CLI というシリアライザライブラリで使っている、動的コード生成技術について簡単に解説します。この記事が動的コード生成を組み入れるときの助けになればいいな、と思います。

昨日の @rabitarochan さんの記事は CodeDOM と MEF を使用した、文字通り動的にコードを生成する話でしたが、今日は、もうちょっとライブラリの話にします。といっても、それほど深い話ではありません。

動的コード生成とは

「動的コード生成」と言う用語は、あまりちゃんとした用語ではないと思うので、この記事のために定義しておきます。

ここでは、「プログラムの挙動を実行時に変更するために、実行時にプログラムを生成し、その結果を実行すること」、とします(後々の分類のために、こういう定義にします)。一見すると、なんだか色々できそうですが、具体的に何ができるか正直想像しづらいかと思います。

どんな時に使うのか

基本的に、動的コード生成しないとできないことってあまりないです。リフレクションとか使っておけば大体できると思います(foddy みたいなメソッド呼び出し割り込み(いわゆる AOP)機構を実装したいならともかく)。

では、何故動的コード生成を使うかというと、主な理由はパフォーマンスです(あとは TargetInvocationException が憎くて仕方がないときとか)。リフレクションは遅いです。いや、もちろん I/O なんかよりはずっと速いんですが、少なくとも普通の仮想メソッド呼び出しやインターフェイスメソッド呼び出しに比べて遅いです。なので、何回も実行されるコードの場合、動的コード生成をやる価値があります。何回も呼び出されたときに、積み重なったパフォーマンスの改善が効いてくるからです。そうでない場合、そもそも動的コード生成自体がそこそこ重いとか、正直書くのがしんどいとかあるので、動的コード生成なんか使っちゃダメです。

たとえば?

身近な所では、以下のようなところで使われています。いずれも、リフレクションなどでは十分な速度が得られない場合に使用されています(と思います)。

  • Regex に RegexOptions.Compiled を渡した場合。内部的に動的コード生成されます。
  • P/Invoke の IL スタブ。これも、マネージドとアンマネージドの世界の間の相互変換(マーシャリングとか)を実行時に動的に生成しているはずです。
  • XmlSerializer。(昔は CodeDOM の代表格でしたが、最近は IL ベースになったようですね)

コード生成ライブラリについて

さて、FCL(だか BCL だか)には、動的コード生成のライブラリがいくつかあります(Cecil 等のライブラリについては、話が大きくなるので触れません)。今さら感もありますし、MSDN 読めばわかることですが、まぁゆるふわということで。

  • AssemblyBuilder:伝統的な動的コード生成 API で、CTS のデータ構造(アセンブリとか型とか)と、その実装である IL をごりごり書くタイプです。ステートや依存先オブジェクト用のバッキングストア(つまりはフィールド)が必要な場合に有用な選択肢です。また、生成した Assembly はディスクに書き出すことができます(書き込み先のディレクトリは AssemblyBuilder をインスタンス化するときに指定し、ファイル名は保存時に指定するという謎設計なので注意です)
  • DynamicMethod:.NET 2.0 から追加された API で、型やアセンブリを作らずに直接 IL を書き出すことができます。LGC(Lightweight Code Generation)とか言ったりしますが、開発者的にはあまりライトじゃないです。ExpressionTree ができたので、はっきり言っていらないと思います。Windows Phone 7 系で動的コード生成をする場合の唯一の選択肢です。
  • ExpressionTree:.NET 3.5 から追加され、4.0 で強化された API です。基本的には式ベースの、関数型スタイルのコード生成をしますが、4.0 でブロックや goto が実装され、かなり強力になりました。任意の MethodBuilder にコンパイル後の IL を出力できたりもします。ただし、フィールドにステートや依存先を持たせることはできません。
  • CodeDOM:古き良きコード生成技術です。これは他の技術と異なり、ソースコードを生成します。式ツリーが式ベースなのに対し、こいつは文ベースです。DOM オブジェクトからコンパイルしてアセンブリとしてロードしたりもできますが、実装としては一時ファイルにコードを吐いてコンパイラを実行しているので重いです。SSD に換装したところで、Windows のプロセス起動の遅さがネックになる感じです。あと、foreach や using、三項演算子はもちろん、単項演算子がサポートされてなくてなけます。後、空の文や式の指定方法が仕様として曖昧だったりします。あと、Windows XP 日本語版という残念な OS を使っていると、CodeDOM の内部で使っている csc の起動時に、Console IME がデッドロックしたりするので要注意です(もう直ったかもしれないけど)。

ポータビリティについて

最近は .NET 以外にも、Windows Phone とか、Silverlight とか、Windows Runtime とか、Unity とか Xamarin とかあります。なので、そういった各種 CLI(Common Language Infrastructure)実装系の間でのポータビリティも気になるところです。ポータビリティと言って思い浮かぶのは Portable Class Library、略して PCL です。PCL はプラットフォームの差異を吸収してくれるデファクトの機能です(デファクトであるということは、Mono でサポートされるようになったりと、エコシステムが出来上がるので楽なわけです)。ですが、動的コード生成は PCL にありません。そもそも、PCL はプラットフォーム間で共通の機能を提供するわけなのですが、以下の表を見るとわかるように、そもそもどのプラットフォームでも使える動的コード生成ライブラリがありません。

API.NET 3.5.NET 4.5.1Silverlight 5Windows Phone 7.1Windows Phone 8WinRT
AssemblyBuilder××××
DynamicMethod×××
ExpressionTree(※1)△(※2)××
CodeDOM××××

※この表に Unity と Xamarin を入れたかったのですが、まだ検証できてません。

※1 ExpressionTree の内容を IL にダンプするには、AssemblyBuilder がサポートされていなければなりません。

※2 BlockExpression や GotoExpression がないので、他の方法に比べるとかなり苦労するはずです。

うーむ。CLR 2 系がなくなれば ExpressionTree が PCL に入るかもしれませんね。フィールド使えませんが。

一応、上記の表を簡単にまとめると、以下のようになります。

  • AssemblyBuilder.Save や CodeDOM、LambdaExpression.CompileToMethod など、生成結果を保存する機能は、デスクトップ CLR にしかありません。
  • 新しいプラットフォームであれば、ExpressionTree が使えます。BlockExpression などを使えば(IL よりも変数のスコープの癖が大きい気がしますが)ほとんどの処理は書けるはずです。
    • .NET 3.5 ではちょっと心元ありませんが、AssemblyBuilder が使えるので頑張れるはずです。
    • Windows Phone7 の場合は、DynamicMethod 一択です。

余談:ステップ実行のサポートについて

動的に生成されたコードをデバッグしたい、ということはよくあります。そして、AssemblyBuilder や ExpressionTree にはデバッグシンボルを生成するための API があります。ありますが、実際にデバッガーをアタッチして動的コード生成の場合、そもそも対応させるソースコードをどうやって作って吐き出すのか(難しくはないけど面倒くさい)という問題があります。なので、この記事ではここについてはもう触れません。ステップ実行をサポートしたいのであれば、CodeDOM を使って吐き出すのがいいでしょう。DebuggerNonUserCode 属性を付けておくと、Visual Studioのデバッガオプションで「マイコードのみ」を有効にしているかどうかで、ステップ実行するかどうかが切り替えられていいかもしれません。

実装事例について

さて、あなたが何の因果かポータブルな動的コード生成が必要になったとしましょう。パフォーマンスを売りにしているライブラリをうっかり移植しようと思うとか、AOP フレームワークを実装する仕事が来たとか、ちょっとしたユーティリティでどうしても TargetInvocationException をスローしたくないとか、いろいろな偶然が重なることもないとは言えません。もっと可能性の高いこととして、突然 github でプルリクエストを送りたくかもしれません。人間万事塞翁が馬です。そのときに困らないように、どのように動的コード生成をポータブルな感じにしたのか、実例を紹介しましょう。

ここでは、MessagePack for CLI というシリアライザライブラリの事例を紹介します。このライブラリは、.NET 系(Silverlight や Mono)で、MessagePack というバイナリ形式へのシリアル化ができるようにするライブラリです(ちなみに、CLI は Command Line Interface ではなく、Common Language Infrastructure です)。パフォーマンスを確保しつつ(MessagePack は実装系のパフォーマンスを売りにしているので)、気軽に使えるようにするために(あらかじめコードを作っておくのはちょっと敷居が高いです)、基本的には実行時にコード生成を行います(余談ですが、ビルドシステムを作り込んでいるので事前コード生成の方が良いという意見もあったので、0.5 では CodeDOM もいれてます)。ちなみに、ちょっとでも遅くなると、ネットですぐにベンチマークがさらされるので油断なりません。

さて、ライブラリの紹介はこれくらいにして、事例としては、どのように動的コード生成を使いつつ複数のプラットフォームをサポートするのかと、単体テストをどのように行っているのかを紹介しましょう。

補足:シリアライザがやることについて

と、その前に、簡単にライブラリの内部動作に触れておきましょう。MessagePack は伝統的に(?)オブジェクトグラフをサポートせず、循環参照のないツリー構造のみをサポートします(他の言語のバインディングで循環参照がサポートされているものはないはずです。そして、相互運用の必要がないなら、高機能な BinaryFormatter なり NetDataContractSerializer を使えばよいので、MessagePack を使う理由がありませんね)。なので、おおざっぱに言うとシリアル化は以下のようなシンプルな処理になります。

  1. 対象のオブジェクトのフィールドやプロパティを列挙します。
  2. そのフィールドやプロパティの値が null でもプリミティブ(整数、実数、文字列)でもなければ、再帰的に展開します。
  3. プリミティブ型を MessagePack の仕様に従ってエンコードします。

ある程度慣れた人であれば、上記の処理はリフレクションを使用して実装可能なことが分かるでしょう。そして、エンコード処理はそれほど重くないので、処理時間のほとんどはリフレクションによるメンバーの再帰的な分解になります。MessagePack for CLI では、これを高速化するために動的コード生成を行います(ちなみに、逆シリアル化も似たようなものですが、ストリームのパース処理と検証が入るため、リフレクション以外の部分のパフォーマンスも重要になります。どちらにせよ、複雑なのでここでは触れません)。

複数のプラットフォームのサポート

さて、MessagePack for CLI では、デスクトップ以外にも、Silverlight、Windows Phone(0.4 で凍結)、WinRT(WinRT コンポーネントではなく、CoreCLR 用のライブラリとして実装)などをサポートしています。また、そのため、単一のコード生成技術ではなく、プラットフォーム毎に対応した動的コード生成ライブラリを使用しています。

動的コード生成ライブラリによるコード生成と、シリアライザの機能の実装を分離するため、0.5 から抽象構造(AbstractSerializers 名前空間)を実装しています。この抽象クラスの実装が、コード要素を表す抽象クラスの派生型を返して、コードを組み立てていきます。まぁカッコつけて言うと Strategy とか AbatractFactory とかそういうものです(Visitor にしなかったのは、単に面倒だったからです)。シリアライザを実装するうえで必要なプログラム構造はある程度固定されているので、あまり汎用性や粒度のきれいさを考えずに、実装のしやすさで作ってます。具体的には、このあたりが抽象構造で、ここここに実装がありますので、興味のある方はご覧ください。

さて、構造を抽象化したところまではいいのですが、ビルドを上手く工夫しないと、そもそもビルドできないコードになってしまいます。 MessagePack for CLI では、ファイル内で切り替えが必要な部分、例えばコード生成実装クラスのインスタンス化処理で、コンパイラプリプロセッサディレクティブ(#if)を使用してます。

さらに、全部のファイルに #if 書くのはさすがにかったるいので、ターゲットプラットフォームごとにプロジェクトを分け、さらに名前空間ごと除外できるようにしています。名前空間と使用している動的コード生成技術に対応を持たせているので、名前空間(を射影したディレクトリ)ごと除外しています(興味のある方は sln ファイルを開いてみてください)。プロジェクト間の同期には色々ツールもあるのですが、そもそもソリューションを分けていたりもするのと(たとえば CLR 2 用の単体テストと CLR4 系の単体テストを混在させると、Visual Studio の単体テストエンジンがプロセス内 SxS してくれないので、それでロードの失敗とか基本的なバグを見過ごすとか起きがちなので)、ファイルごとにこれは同期しない、これは同期する、など細かく制御したかったので、カスタムのちょっとしたツールを使ってやってます。

単体テスト

動的コード生成のテストですが、パブリックなコンパイラを作っているわけではないので、取りうる入力値をゆるっと同値分割して、それらをテストするコードを書いて、期待通り動作するか見ています(同値分割をサボるために、T4 に型を食わせて、力押しでテストコードを量産したりしてます)。ようは、コード生成そのものを網羅的にテストするのではなく、出来上がった結果が正しく動作するかどうかをテストしています。

なお、各コード生成技術は、プラットフォームに合わせてビルドされますが、デスクトップ CLR ですべてのコード生成技術を実行し、MsgPack for CLI 自身のバグを検出できるようにしています。ちなみに、IL 系だと、一応アセンブリをダンプして PEVerify もかけます。偶然間違った IL が動いてしまったという事態を避けたいので。

あとは、デバッグ用のコードが仕込まれていて、どのライブラリを通っても、最終的な結果を DLL またはソースコードとしてダンプできるようにしています(AssemblyBuilder.Save に、LambdaExpression.CompileToMethod を組み合わせたりしてます)。それを ILDasm やら ILSpy やら PEVerify やらに通してデバッグします。(余談ですが、CodeDOM バインディング実装したので、ここはだいぶ楽になりました)

まとめ

とりとめのないゆるふわ記事ですが、いちおう以下のようにポイントをまとめておきます。

  • 動的コード生成は、実行時にコードを生成して、動的なコード(いわゆる Interpreter 的な処理)を高速化する技術である。
  • ポータブルな動的コード生成ライブラリはない。
  • テストは、まずは出来上がった結果のコードが正しく動くのかをテストするとよい。
  • デバッグでは、生成したコードを検査できるようにするとよい。

免責事項として、MessagePack for CLI 0.5 ブランチは今も変更中のため、後からこの記事を見た人がいたら、リンク切れになっていたりするかもしれません。そのときは、お手数ですが、いったんローカルに clone するなどして、2013/12/19 時点のブランチまで git 系のツールで巻き戻していただければと思います。

明日は @terry_u16 さんです。