[Xamarin] 何もしてないのに Visual Studio で「値を Null にすることはできません」というエラーが表示される

いつの時点で出るようになったのかわかりませんが、最近 Visual Studio に「値を Null にすることはできません。パラメーター名:project」というエラーが常に表示されるようになってしまいました。

英語だと “Value cannot be null. Paramater name: project” という表記みたいです。
検索してみるとありました。
Visual Studio reporting errors (Value cannot be null) since last set of Xamarin updates applied

1. 以下の 2つのファイルを削除する。
   ”C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Xamarin\Xamarin\3.11.446.0\Xamarin.TestCloud.Integration.pkgdef”
   ”C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Xamarin\Xamarin\3.11.446.0\Xamarin.TestCloud.Integration.dll”
2. 管理者でコマンドプロンプトを起動して以下のコマンドを実行する。
   

   C:\> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /setup /nosetupvstemplates

なお、2のコマンドは、コマンド自体はすぐ終了しますし画面にも何も表示されませんが、見えないところで devenv.exe が動いています（タスクマネージャーで Visual Studio のプロセスを探せばわかります）。私の環境だと 1分くらいはかかるようでした。

これで「値を Null にすることはできません」エラーが表示されることは無くなりました。

[VS] Google Crash Handler が動いていると Visual Studio の XAML UI デザイナーがハングする？

2月後半くらいからこの現象が出るようになって困ってました。

1. Windows 8 上の Visual Studio 2012 を起動。（私が使ってるのは Ultimate。他のエディションは不明）
2. 「ファイル」－「新規作成」－「プロジェクト」 で Visual C# の 「Windows ストア」 で 「新しいアプリケーション (XAML)」 を作成。
3. プロジェクトができたらソリューションエクスプローラーで MainPage.xaxml をダブルクリックして XAML UI デザイナーを開く。
4. XAML UI デザイナーのどこかをクリック。

これで、Visual Studio がハングしてどうしようもなくなります。
私の環境では 100% こうなります。
同じような環境が 2つ（デスクトップ PC とノート PC）がありますがどちらも 100% 発生します。
上記では例として新規作成のプロジェクトにしましたが、既存のプロジェクトを開いて XAML UI デザイナーをクリックしても同様です。
何かに時間がかかっているだけかと思い 10分以上放置してみたこともありますが何ともなりませんでした。
ちなみに、WPF のデザイナーでは問題はでません。問題が出るのは Windows ストアーのデザイナーだけのようです。

この状態になったら以下の方法で部分的に復旧させることができます。

• タスクマネージャーを開き 「Microsoft Visual Studio XAML UI Designer (32 ビット)」 という名前のプロセスを終了させる。

どうやら XAML UI デザイナーは別プロセスになっているようで、こうすると Visual Studio が操作できるようになります。
ただし、XAML UI デザイナーは死んだ状態なので下図のようになりデザイナーは使えません。

デザイナーは使えませんが、XAML を手書きはできますし、XAML UI デザイナー以外の部分は問題ないのでとりあえずこれで使ってました。（最近は XAML UI デザイナーが必要なことはあまりやってなかったのでこれで何とかなってた）

けど、これはさすがに不便なので解決策を探ることに、、、
まず手始めに何かのプロセスが影響を与えていないことを確認するためにタスクマネージャーで殺せるプロセスはみんな殺す。。。あれ？動くようになったぞ？
いきなりビンゴ。あとはどのプロセスが原因になっているのかを特定するため地道に試していくと、、、

• タスクマネージャーで 「Google Crash Handler (32 ビット)」 という名前のプロセスを終了させれば Visual Studio 2012 の XAML UI デザイナーがハングしなくなる。

でした。

Google Crash Handler が何なのかはわかりません。（まぁ、名前的にクラッシュを検出してレポートするためのものなんでしょうが。そんなものが Visual Studio をハングさせてしまうというのも皮肉な話）
また、何を入れると入るのかもわかりません。Google 日本語入力（Google IME）、Chrome、Google Toolbar あたりだとは思いますが。
ちなみに、GoogleCrashHandler.exe は バージョン 1.3.21.135 で、タイムスタンプ 2013/02/06 08:21 でした。

と、冷静にまとめましたが、原因が特定できたときには思わずガッツポーズしちゃいましたよ（笑）

[VS2012] async/await のパフォーマンスの注意点

前の記事 で紹介した 「What’s New for Parallelism in Visual Studio 2012 RC」 の補足記事が来てました。

「Performance consideration for Async/Await and MarshalByRefObject」
これ、個人的にはものすごく重要なことのような気ガス

前の記事にあった StreamReader.ReadLineAsync メソッドが 3倍速くなったとかはどういうことなのか？
詳しくは上の記事を読んでもらった方がいいと思いますが、ざっくりと説明します。
上記の記事からコードの重要な部分をコピペします。

class MyObj 
{ 
    const int ITERS = 100000000; 
    private int m_data; 

    public async Task Foo1() 
    { 
        for (int i = 0; i < ITERS; i++) m_data++; 
    } 

    public async Task Foo2() 
    { 
        int localData = m_data; 
        for (int i = 0; i < ITERS; i++) localData++; 
        m_data = localData; 
    } 
}

この Foo1 メソッドと Foo2 メソッドの実行速度を調べると Foo1 の方が 3倍くらい遅いそうです。
なぜか？
async なメソッドはコンパイラによって中身がゴニョゴニョされて await が使用できるようなコードに変換されます。（メソッドの中身が IAsyncStateMachine を継承した別クラスに切りだされて、await ごとに状態遷移するようなステートマシンなコードになる） コード上では単なるフィールドへのアクセス（m_data へのアクセス）に見えますが、コンパイル結果は単なるアクセスじゃなくなっているわけです。そのため、その分遅くなってしまうということだそうです。

さらに

class MyObj

を

class MyObj : MarshalByRefObject

とすると差が大きくなります。
実に Foo1 は Foo2 の 72倍くらい遅くなってしまいます。Foo2 の方は MarshalByRefObject であっても無くてもほとんど速度は変わりません。
これは、どうやら以下の理由だそうです。
MarshalByRefObject を継承したクラスはリモートアクセスが可能になります。リモートアクセスする場合はプロキシーが生成され引数などがマーシャリングされて渡されるわけですが、これはかなり重い処理です。なので無駄にプロキシー経由にならないようになっています。プロキシーが必要かどうかは 「別 AppDomain かどうか」 で判断します。しかし、この判断自体もオーバーヘッドになってしまいます。なので、JIT は自分自身（すなわち “this”）にアクセスする場合は絶対に同じ AppDomain だとしてチェックを省略し、普通にローカルなフィールドにアクセスするのと同じ速度になるようにしています。
ところが、async なメソッドになると上に書いたようにメソッドの中身が別クラスに切り出されるため m_data へのアクセスは this へのアクセスではなくなります。そのため m_data にアクセスするたびに 「同じ AppDomain かどうかのチェック」 をしなくちゃいけなくなります。これがオーバーヘッドになって 72倍という速度差になります。（ちなみに、もし別 AppDomain になって、プロキシー経由のアクセスになると数百倍くらいの速度差にはなるんじゃないかと思います。COM のころはそんな感じでした）
ちなみに、Stream や TextReader、TextWriter といったクラスは MarshalByRefObject から派生しています。

これはプロパティにするとちょっとましになるそうです。

private int Data { get { return m_data; } set { m_data = value; } } 

public async Task Foo3() 
{ 
    for (int i = 0; i < ITERS; i++) Data++; 
}

意味的には Foo1 とまったく同じですが、JIT が最適化するヒントになって Foo3 は Foo2 に比べて 10倍くらい遅い（Foo1 に比べて6倍ちょっと速い）となるそうです。

まぁ、こうしても遅くなるのは確かなので結局のところ 「async なメソッドでは極力フィールドやプロパティにアクセスせず、可能な限りローカル変数アクセスになるようにする」 ということになりそうです。
別の意味でもなるべくローカル変数になるようにした方が安全です。
async なメソッドで await を使うと非同期で動くようになるわけですからそこからフィールドやプロパティにアクセスするときは排他を考えてやらなくちゃいけません。async/await を使うとあまりにお手軽に非同期できちゃうので忘れがちになってしまいますが、非同期で動いている以上、外部のリソースにアクセスする場合は常に 「別の非同期メソッドとの読み書きがバッティングして内容が破壊されるようなことは無いか」 を考えてやらなくちゃいけません。ローカル変数は外部ではありませんので、そういったややこしいことを考える必要が無くなります。（注意: 別のクラスのインスタンスをローカル変数に持っていて、そのインスタンスが別の非同期メソッドからアクセスされるような場合は当然ちゃんと考えてやらなくちゃいけません。ローカル変数ならなんでも大丈夫ってわけじゃありませんのでご注意を）

[VS2012] Visual Studio 2012 RC での変更点

「What’s New for Parallelism in Visual Studio 2012 RC」 より。
Visual Studio 2012 RC での変更点がまとめられてました。

コンパイル時に async なメソッドには AsyncStateMachineAttribute がつけられるようになったそうです。コード解析するツールとかで async なメソッドであったことがわかるようにってことらしいです。

async/await キーワードに関しては（中身が）いろいろ変わった模様。
いろいろ改良されて、async/await 時に消費されるメモリも、オーバーヘッドもかなり減ったとのこと。
また、ベースクラスライブラリ（BCL）の Async なメソッド自体も改良されているそうです。たとえば、StreamReader.ReadLineAsync メソッドは 300% くらい速くなってるとか。他にも BufferedStream 類もいろいろ改良したとか、AsStream や AsStreamForRead なんかは BufferedStream を使うようにしたとか、非同期関連はコンパイラ・ライブラリ通していろいろと改良されているようです。

ASP.NET も Beta まではイベントハンドラに async 付けるとバギーだった（代わりに RegisterAsyncTask を使う）のが、どうやら async 付けても大丈夫になった模様。
他にも HttpRequest、HttpResponse でキャンセル可能になったとかいくつかの改良がされているようです。

Dataflow （System.Threading.Tasks.Dataflow）がなくなっちゃいました。
どうやら、Beta まではフル .NET Framework のパッケージに入ってたけどメトロスタイルには無いとかそういう状況だったけど、デスクトップとメトロスタイルの両方で使えるように .NET Framework からは分離して NuGet で提供するようにしたってことみたいです。
詳細は 「MEF and TPL Dataflow NuGet Packages for .NET Framework 4.5 RC [Nick]」 にあります。
System.Threading.Tasks.Dataflow.dll は無くなって Microsoft.Tpl.Dataflow として NuGet にある。これはデスクトップ、サーバー、メトロスタイルのすべてをサポートする。なお、まだ Prerelease なので “Include Prerelease” にしておかないと一覧で出てこない模様。
あと、MEF も Beta のころはメトロスタイルでは .NET Framework 版 MEF のサブセットが使えるという感じだったが、これからは MEF for Metrostyle という新しいパッケージとして NuGet で取得できるようになってるそうです。

[VS11] Visual Studio 11 のラインナップ

「A look ahead at the Visual Studio 11 product lineup and platform support」 より。
Visual Studio 11 の製品構成が発表されてました。

まず、Visual Studio 11 っていうのはあくまでコードネームで正式名ではないってことだったと思いますが、名称については特に何も書かれてないですね。VS11 が正式名になるんだろうか？

で、ラインナップですが、 http://www.microsoft.com/visualstudio/11/en-us/products ここに書かれてるようになるってことみたいです。上記の記事にある “Visual Studio product website” のリンクから行くと日本語のページにいきますが、英語の方のページを見てみると微妙に違います。ラインナップが書かれていますし、日本語のページの方はすべて “Visual Studio 11 Beta” と表記されていますが、英語の方は（タイトルロゴ以外は） “Beta” の文字が無くなっています。ただ、リンク先は Beta のままだったりするのでちょっとアレですが。

有償版の方は VS2010 と似たようなラインナップみたいですが、無償の Express は大きく変わるみたいですね。
C#、Visual Basic といった言語別の Express は無くなり、Express for Windows 8、Express for Web になるようです。for Windows 8 では C#、Visual Basic、C++、JavaScript が使えるようです。ここで言う “for Windows 8” がメトロスタイルアプリのことだけを言ってるのか、メトロスタイルでは無い .NET Framework アプリの開発もできるのかはよくわかりません。（自分は Express を入れてないからわからないんですが、確か VS11 Express for Windows 8 Beta ではメトロスタイルのみって話だったと思うんですが）
あと、記事には 「Blend、プロファイラー、ユニットテストなどといったメトロスタイルアプリの開発に最適なツールも提供される」 ともあります。Express にもこういった機能が入るってことでしょうか？Blend も Express に付いてるってこと？

で、最新のプラットフォーム向けの特別なツール無しの言語別の Express が使いたい場合は、今後も VS2010 Express は引き続き提供されるので、そっちをダウンロードして使ってくれということだそうです。
これは VS11 Express にはメトロスタイル用の for Windows 8 と Web 用の for Web しか無いからそれ以外の普通の .NET Framework 4、4.5 の開発とかネイティブ C++ の開発とかは VS2010 Express を使えってこと？せめて VS11 for .NET Framework 4.5 は欲しかったような（for Windows 8 に .NET Framework 4.5 も含まれるんならいいんですが）

あと、Windows Phone ですが、これは次の Windows Phone がリリースされる時に Visual Studio Express for Windows Phone がリリースされる予定だそうです。ということは Windows Phone 8 のときってことなんでしょうね。（それにしてもそろそろ Windows Phone 8 アプリが Silverlight for Windows Phone 7.1 の発展系になるのか、WinRT の Windows Phone になるのか、それ以外になるのか、といったくらいのところは教えて欲しいなぁ）
同じように Azure も次の Azure アップデートのときに Azure tools が提供されるようです。
それまでの間は VS2010 を使っていてくれとのこと。

そういや、Silverlight のことについてはまったく触れられてませんね。やっぱり、Silverlight Toolkit for VS11 が提供されることは無いのかなぁ。ちょっとさびしい。

VS11 は .NET Framework 4 と 4.5 をサポートするようです。4.5 は Vista 以降のみサポートなので XP、Windows Server 2003 をサポートするには 4 をターゲットにする必要があります。なお、4.5 の新機能の async/await は Async Targeting Pack for Visual Studio 11 を入れてやれば .NET Framework 4 でもサポートされるようになるそうです。これはうれしい。

C++ の方は XP、Windows Server 2003 をサポートするには VS2010 のコンパイラーとライブラリーを使用しろとあります。VS11 と VS2010 はサイドバイサイドで両方インストールできるので使い分け可能だそうです。ただ、VS2010 をサイドバイサイドでインストールすること無しに XP を直接ターゲットにできるようなオプションを評価中だそうです。

[VS11] Visual Studio 11 の Direct3D サポートすごいな

Somasegar’s Weblog 「Visual Studio 11 Platform Tooling Advances」 より

Visual Studio 11 の Direct3D 関連のサポートがすごいことになってるんですね。

■ The first area of improvement
HLSL （High-Level Shader Language。GPU に対する命令を記述するための C 言語風の言語） が VS で普通にサポートされるみたいです。
あまり詳しくないんですが、以前は DirectX SDK に付いてる外部の HLSL コンパイラ（fxc.exe）を呼び出してコンパイルしてたと思いますが、これは XNA GameStudio でも今だに変わってなかったのかな？それがきちんと VS に統合されるという感じでしょうか。
また、エディターもちゃんと色付けやインデントなど C# や VB と同じようにサポートされるようです。（当然インテリセンスもできるんでしょうね）

シェーダーではいろんなことができますが、ピクセルシェーダーでは
    「マテリアル表面のテクスチャ A」 と 「陰影のテクスチャ B」 を合成する
みたいなことをやったりします。
これをビジュアルに編集するノードエディターが搭載されるようです。編集中もリアルタイムに結果が表示されるとか、”Time” ノードでアニメーションも定義できるとか、なにこれ、すげぇ！
もちろん、ビジュアルに編集した結果は HLSL がジェネレートされます。

■ The second area of improvement
.FBX や .DDS のビューワーも搭載されるようです。これで 3D モデルを VS11 内で確認できるとのこと。
（さすがに 3D モデルの作成機能は無いよとのこと）

■ The third area of improvement
DirectX のフレームをキャプチャしたり、GPU パイプラインの内容を参照したり、ピクセルの描画イベントを参照したりといった GPU のデバッグ機能が搭載されるそうです。（このあたりは （これまた詳しくありませんが） DirectX SDK や XNA GameStudio にはあった機能かもしれませんが）

--

今まで DirectX 関連は DirectX SDK や XNA GameStudio にまかせっきりだったものが、Visual Studio 本体に機能追加されつつ統合されるという感じでしょうか？
Windows Phone はもともと XNA をサポートしてますし、Silverlight も 5 で XNA サポートと、本体と分離して考えるほうが無理が出てきたってことかもしれませんね。