Visual Studio for Web であってはならない1つの事

かなり長い間 Visual C++ を使い、C# 1.0 が出るや飛びついて、今は身も心も .net の奴隷と化している pon ですこんばんは。

.net ではコンソールも Windows.Forms も、ASP.net も p/invoke も、それ以外も色々と手を出しているのですが、個人的に一番距離が遠いのは ASP.net です。

ASP はそもそも分からず、ASP.net で WebPages がわずかに分かるかな？ 程度だったのですが、MVC と Razor が使いやすそうだったので軸足を移してきました。 それまでは perl か PHP に postgreSQL でサーバを立てる事しかできなかったのです。

ASP.net でお世話になっていたのが Visual Web Dev 2008 Express と SQL Server 2008 Express でした。 特に目立つサイトを作ったわけでは無いのですが、あー ASP.net は便利だなぁ。 的な。 そして 2010 が出た時も、少し様子見をしたもののあっさり飛びついてしまい、あれは動くけどこれは動かないと泣きながらソリューションやアクセス権とバトルしたものでした。

それに比べると、Visual Studio 2012 Express for Web などのセットアップや移行の簡単さ。(実は RC1 の時に一回インストールして環境がバッティングし、涙目でロールバックしたのですがさておき) 以前のソリューションはあっさりとビルドされて動いたんですね。 あーこれは本当に便利だなぁ。 ありがたいなぁ。 じゃぁお世話になった 2010 Express とはおさらばしよう。

↓

(T T

ソリューションは問題なくビルドでき、Web アプリケーションもスタートされ、リクエストは来ているのですが、URL ルーティングが始まる前に、ビューエンジンの検索が始まる前に、しかしアプリケーションドメインに処理が移った後に例外を出してしまいます。 もちろんアプリケーションはあらゆる例外やそれ以外の障害に対応するよう記述してありますが、アプリケーションコアの下で発生した例外の一部はトラップできずにサーバをクラッシュさせてしまいます。

何か悪い事をしたかな…？

思い当たる事が多すぎて気が遠くなりかけましたが、まずは状況の検証です。

とりあえず突然クラッシュするので、原因が全く分からないというのはマズいですね。 仕方ないので .net のシンボルを全部ロードしてスタックを見てみます。 ぐわ… 全部ロードするとさすがに重い…。

アプリケーションは確かにスタートしており、リクエストに対してレスポンスしようとはしているらしいのですが、何かのインスタンスを作成するためアセンブリをロードしようとして失敗しているらしいのです。 なぜか逆アセンブルを出さないと例外発生をトラップできずに難儀しました。

トラップしてしまえばこちらの物。 内容は…？

{“ファイルまたはアセンブリ ‘System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’、またはその依存関係の 1 つが読み込めませんでした。指定されたファイルが見つかりません。”:”System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″}

System.Web.Providers？ なんですかそれは。 そんなアセンブリってありましたっけ？

プロバイダって事は、ユーザーとかロール、セッションを管理するアレですよね？ 昨日まで普通に動いてましたが…？

とりあえず bing で検索すると、http://nuget.org/packages/System.Web.Providers が引っ掛かりました。

えーと、要するに… 昨日まで動いていたアセンブリパッケージを間違って削除した？

だから再インストールしろと？

…

ええええー？！ そんな、GAC から勝手にアセンブリを消したりしませんよ。

…

嘘です。 してました。Visual Web Dev 2010 Express の残骸が残っていたのをアンインストールしました。 でも、アンインストールプロセスで勝手に NuGet パッケージをアンインストールするかな普通。 → するらしいです。

＼(^o^)／

ですから、IDE を使っている場合、ツール(T) → ライブラリ パッケージ マネージャー(M) → パッケージ マネージャ コンソール(O) を選択して、NuGet パッケージと対話するためのコンソールを開きます。

PM>

とプロンプトが出るので、素直に

Install-Package System.Web.Providers

と打ち込んで Enter を押します。

「依存関係の解決を試みています。」 とか、オイそれ勝手にやってくれるの！？ みたいなのが数行流れ、「正常に追加されました。」 と表示されるはずなので、それでビルドすれば大概はするっと動作するはずです。

もししなかったら、web.config の中で使われている各プロバイダの type 文字列が

type="System.Web.Providers.*Provider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

となっているかを確認し、connectionStringName が configuration\connectionStrings\add+name のいずれかに一致している事を確認してください。 もしかするとさっきのパッケージマネージャーが勝手に web.config をいじって、余計な接続文字列を追加しているかもしれません。

この辺がクリアされれば、めでたくサイトは元通り動き始めるでしょう。