先日買った Windows 10 Pro 64-bit のノート PC に旧マシンから開発環境を移していますが、Visual Studio で開発中の Web アプリを Edge で開けないという問題に遭遇しました。一応解決したので、自分が行った解決方法を備忘録として書いておきます。

Windows 10 には Microsoft Edge という新しいブラウザが標準として搭載されています。

その Edge を使うと、Visual Studio から開発中の Web アプリを開けないだけでなく、Edge を単独で立ち上げてアドレスバーにローカル IIS で動くように設定した Web アプリの URL を入力しても表示されません。

ググって調べてみると、Edge はセキュリティが厳しくなって、ローカルホスト（ホスト名に関係なく IP アドレス 127.0.0.1 がアクセス先のホスト）へのアクセスが制限されているそうです。

解決策として、Edge のアドレスバーに about:flags と入力して表示される「開発者向け設定」で［ローカルホスト ループバックを許可する］にチェックを入れて Edge を再起動するという記事がいくつか見つかりました。

で、早速自分もやってみました・・・が、ダメでした。（涙）　依然として Edge はローカルホストにはアクセスできません。当然 Visual Studio からローカルホストの Web アプリを開くこともできません。

さらにググって調べてみると、コントロールパネルから開く「インターネットオプション」で、ローカルイントラネットゾーンに含めるサイトの定義を変更するという記事を見つけました。

具体的には上の画像のように、［セキュリティ］タブ ⇒［ローカルイントラネット］⇒［サイト(S)］で表示される「ローカルイントラネット」ダイアログで［ほかのゾーンに指定されてないローカル (イントラネット) のサイトをすべて含める(Z)］のチェックを外します。

結果、Visual Studio 2010 / 2015 ともローカルホストの Web アプリを Edge で開くことができるようになりました。もちろん Edge を単独で立ち上げてアドレスバーにローカルホストの URL を入力しても表示できます。

上の画像は、Visual Studio 2015 のテンプレートを使って自動生成させたインターネット用 Web サイトアプリケーションです。

ローカル IIS 上でホスト名 websiteproject.com で動くように設定し、hosts ファイルでそのホスト名の IP アドレスを 127.0.0.1 に設定し、Visual Studio 2015 でサイトを開いて実行させています。

（ググって調べた記事の中に CheckNetIsolation.exe コマンドを使って設定するというものがいくつかありました。Edge のアドレスバーに about:flags として設定できなかった古いバージョンではそれを使っていたようです。なお、CheckNetIsolation.exe コマンドが「インターネットオプション」の変更まで行ってくれるかどうかは分かりません）

SQL Server Management Studio（以下、SSMS と書きます） を使ってデータの編集ができますが、その際に楽観的同時実行制御がかかっているようです。（SQL Server 2008 Express SP4 で試しました）

上の画像が SSMS を使ってのデータの編集中に楽観的同時実行制御に引っかかって警告のダイアログが表示されたところです。

上の例は、EmployeeID = 1 の LastName を編集して他の行に移動した際、編集されたデータを使ってデータベースの更新（UPDATE クエリの発行）をトライしたが、SSMS にデータを表示してから UPDATE クエリが発行されるまでの間に他のユーザーがデータを変更していたという状況です。

SSMS での編集に楽観的同時実行制御がかかるって知ってました？　実は自分は知らなかったです。後勝ちルールになると思ってました。（汗）

このデータを更新するアプリと SSMS を一緒に動かしていたら上の画像のダイアログが出てきたので、楽観的同時実行制御がかかっていることを初めて知ったという次第です。

新発見ということでブログに書いておくことにしました。知らなかったのは自分だけかもしれませんが。（笑）

先日買った Windows 10 Pro 64-bit のノート PC に旧マシンから開発環境を移しています。

WCF サービスをホストしている ASP.NET Web Forms アプリをソリューションごとコピーして .aspx ページは問題なく動くようになったのですが、何故か WCF サービスだけが動きません。（汗）

ブラウザから .svc ファイルを要求すると HTTP 404.17 エラーとなります。エラーメッセージは「要求されたコンテンツはスクリプトであり、静的ファイル ハンドラーで処理されない可能性があります。」でした。

IIS のハンドラマッピングをみると .svc 用のハンドラは 3 つ存在していたのですが、何故静的ファイルハンドラーにマップされたのでしょう？

3 時間ぐらいハマってしまったのですが、ググって調べて stackoverflow の記事 What causes WCF Error 404.17 to be shown? にたどり着きました。

その記事の質問欄に "I then finally fixed it by enabling "HTTP Activation" (as suggested here)" とあります。その here のリンク先が HTTP Error 404.17 - Not Found で、その記事の回答にある画像すなわち ASP.NET 4.5 の WCF サービスの HTTP アクティブ化が正解のようです。

自分の Windows 10 Pro で該当するのは、以下の画像の「Windows の機能の有効化または無効化」で [.NET Framemwork 4.6 Advanced Services] => [WCF サービス] => [HTTP アクティブ化] のようですので、それにチェックを入れて有効化してみました。

結果、ブラウザから .svc ファイルを要求すると応答が返ってくるようになり、アプリから WCF サービスのメソッドを呼んだ場合も正常に応答が返ってくるようになりました。やはりこれが正解だったようです。

IIS のハンドラマッピングをみると HTTP アクティブ化前には 3 つしかなかった .svc 用のハンドラが、以下の画像のように 6 つに増えています。

HTTP アクティブ化の前/後でどう変わったのかはっきりしませんが、3 つ増えたのは間違いなくて、たぶん 4.0 用が追加されたのだと思います。

また、上に紹介した stackoverflow の記事に、

"The Http Activation Module (System.ServiceModel.Activation.HttpModule) is registered in the machine.config file. .NET 2.0 and .NET 4.0 have separate machine.configs. The Http Activation feature also exists for both .NET versions separately."

・・・と書いてありましたが、HTTP アクティブ化によって、ハンドラの追加だけではなく、.NET 4 用の Http Activation Module の有効化も行われたのかもしれません。

（ググってヒットした記事の中には ServiceModel 登録ツールを使って解決したという話もありました。HTTP アクティブ化もこのツールを使っているのかもしれません。ただし、確認はできていません。ご参考まで）