そして1年後、Windows 8 Metro用のJavaScriptアプリケーションに再び取り組んでいます。C＃マネージコードからEvernote APIへのアクセスを提供する必要があります。 繰り返しになりますが、今回はMetroアプリケーション用の.NET .NET APIとのThriftの非互換性が発生します。 本日、この問題を解決する方法をご紹介します。
コンパイルエラーを修正するために、私たちはVisual StudioでEvernote APIおよびThriftシェルクラス用のMetroクラスライブラリを作成することから始めました。 まず、コンパイル中にSILVERLIGHTが検出された場合、コードは非同期ネットワークモデルを使用しました。 Metroの場合、NETFX_COREを追加しました。
Metroアプリケーション用の.NET APIのI / Oクラスでは、Close（）メソッドが定義されていないことが判明しました。 Microsoft は 、この場合の対処方法を詳細に説明しました。
マイクロソフトは、2段階のネットワーク操作（Begin *およびEnd *）を新しいReadAsyncと待機演算子に置き換えることも推奨しましたが、古いモデルはまだ機能しているようであるため、まだ何も複雑化または変更しないことにしました。
APIへの要求を生成するとき、すべてのEvernoteクライアントは指定されたUser-AgentでHTTPヘッダーを送信します-これにより、サーバーログで要求を行うアプリケーションを簡単に識別できます。 Silverlight用User-Agentのインストールに使用したHttpWebRequest.UserAgentプロパティは、Metroアプリケーション用の.NET APIから削除されました。 新しいHttpClient APIを使用すると、特定のUser-Agentをインストールできますが、HttpClientを使用するには、応答を待つために新しいモデルに切り替える必要があり、前述のように、このような重要な変更に対応できません。 現時点では、User-Agentをそのままにして、誰がAPIにリクエストを送信するかを決定する能力を失いました。 期待モデルは将来使用される可能性が高いという事実により、おそらくそれをサポートするネットワークインタラクションの3番目のモデルを開発し、ユーザーエージェントサポートを返します。
これら3つの変更のおかげで、クラスライブラリをコンパイルすることができました。 ただし、クラスライブラリは、マネージ言語で開発されたMetroアプリケーションでのみ使用できます。 APIはJavaScriptアプリケーションで使用されます。つまり、ライブラリをWinMDファイルにパックする必要があります。 ただし、プロジェクトのコード生成形式をクラスライブラリからWinMDに切り替えてみてください。WinMDファイルにはいくつかの重大な制限があります。
さいわい、WinMDファイルの制限は、使用されるコードでそれらが表すインターフェイスにのみ適用されます。 アプリケーションで完全なクライアントAPIを使用しようとする代わりに、ラッパーを追加しました-WinMDとしてコンパイルし、APIを使用して個々の操作のロジックをサポートし、アプリケーションにシンプルなAPIを提供するプロジェクト。
アプリケーションのラッパーライブラリのモデルを使用して、Evernote APIで完全に機能する機能するMetroアプリケーションを（既存のコードに最小限の変更を加えて）受け取りました。 ユーザーがWindows 8とMetroを採用していることを喜ばしく思います。将来、「メトロアプリケーション」が広く普及し、この用語が通常の用語「アプリケーション」に置き換えられることを願っています。
変更されたSDKと試用版アプリケーションを使用した Visual Studio 11のソリューションは、GitHubで入手できます 。 それを試して、あなたが何を手に入れたか教えてください。