とある.NETやさんのつぶやき

例外発生時に、スタックトレースに行番号が書かれていると、ソースコード中のどの箇所でエラーが発生したのかを迅速に把握でき、プログラムの改修をピンポイントで行えるようになります。
スタックトレースに行番号が表示されない場合は、次の原因が考えられます。

■拡張子pdbファイルがない
実行環境に、pdbファイルを配置し忘れたなどの理由が考えられます。
pdbファイルを実行環境に配置すれば、行番号が表示されるはずです。

■pdbファイルの対応付けが誤っている
pdbファイルはあるが、異なるビルドタイミングで生成した拡張子dllやexeのファイルと併存していることが考えられます。例えば、dllファイルは更新したが、pdbファイルを更新せず古いままだった、などが考えられます。
同じビルドタイミングで生成されたdllファイルとpdbファイルを、実行環境に配置すれば、行番号が表示されるはずです。

■VisualStudioの設定
VisualStudioでのビルドの設定により、pdbファイルが生成されない設定になっていることが考えられます。
VisualStudioのプロジェクトのプロパティを開き、
設定項目：ビルド＞詳細設定(D)＞デバッグ情報
設定値：fullまたはpdb-only
と設定すれば、pdbファイルが生成されるようになります。

本番稼働環境にはpdbファイルを置くな、という意見も多くあります。
ただ、本番環境で万が一不具合が発生した時に、的確に最速でバグを回収して本番環境を再更新が必要とされる要件がある場合には、pdbファイルを置いておくのも一考に値します。

ASP.NETで、下記のエラーメッセージが出たときの対処法です。

パーサー エラー
説明: この要求の処理に必要なリソースの解析中にエラーが発生しました。以下の解析エラーの詳細を確認し、ソース ファイルに変更を加えてください。
パーサー エラー メッセージ: 型 'Global' を読み込めませんでした。
ソース ファイル: /global.asax 行: 1

調べたところ、エラーの原因は、binフォルダにDLLファイルを配置していないことによるものでした。

例えばVisualStudioでソリューションのクリーンをした直後に物理ファイルを配置してしまった場合や、binフォルダを丸ごと更新し忘れた場合などが、原因として考えられるでしょう。

VisualStudio2015には、データベース比較ツールが付属しています。
このツールを使うと、2つのデータベースの定義を比較して、テーブル定義・列定義が一致しているかどうかを調べることができます。

先日、SQLServer2016のデータベースに対して比較をしようとした時、エラーが出て比較をすることができませんでした。
調べたところ、VisualStudio2015のUpdate3をインストールすれば、SQLServer2016にも対応できるようです。

VisualStudio2015 Update3をインストールしてみると、見事SQLServer2016のデータベースも比較することができるようになりました。

IISでは、Webサイトに対する設定をGUIで行うことができます。
しかし煩雑な処理をミスなく確実に行うためには、GUIで手を動かして操作するよりも、バッチコマンドを使うほうが効率的です。

それをするためのPowerShellのコマンドを調べていましたが、結局見つからなくて、コマンドプロンプトで実行する方法を採用することにしました。

appcmdというコマンドを使うと、実現できます。
このコマンドは、IISサーバー上のウェブサイトや仮想ディレクトリを指定して、様々な設定を変更することができます。

例えば、IISのリダイレクト機能を使って、ウェブサイトのメンテナンス中に「メンテナンス中です」といったHTMLファイルにリダイレクトするのは、次のようなコマンドを使います。

%windir%\system32\inetsrv\appcmd set config "Default Web Site/VirtualDir1" /section:httpRedirect /enabled:true /destination:http://localhost/maintenance.htm /exactDestination:true

・ウェブサイト名は「Default Web Site」とします
・このDefault Web Site直下の、ディレクトリVirtualDir1内の任意のファイルにアクセスされた場合に、別URLにリダイレクトします
・リダイレクト先URLは http://localhost/maintenance.htm と設定しています

.NETで開発したWindowsサービスを、簡単に動作確認、デバッグするためのツール「topshelf」がとても便利です。
詳しいことは「topshelf」で検索すれば、いろいろ出てきます。

.NET4.5で登場した、HttpClientクラスはとても便利です。
以前はWebClientやHttpResponse/HttpRequestクラスなどを使っていましたが、それよりも格段に使い勝手がよくなっています。

ただ注意点もあります。HttpClientクラスでは非同期によるダウンロードメソッドが用意されていますが、場合によってはスレッドデッドロックが発生し、結果が返らない状態が永遠に続く、という現象に陥ることがあります。
さらに、タイムアウトを設定しても、非同期呼び出しだとタイムアウト機能が無効化されるのです。
そのため、ダウンロードメソッド呼び出し後に、結果が返ってこない、反応がない、固まった、という現象に見舞われることもあります。

私もその現象が発生しましたが、ConfigureAwaitメソッドを呼び出して解決することができました。
詳しくは、下記のサイトをご覧ください。

HttpClientクラスの利用サンプルはこちら（タイムアウト設定可能）
http://www.atmarkit.co.jp/ait/articles/1501/06/news086.html


ConfigureAwait(false)の記述で回避できるという情報
http://www.slideshare.net/neuecc/httpclient

※「スレッド デッドロック ConfigureAwait」で検索すれば、いろいろな情報が得られます。

アプリ内で発生した例外を一括して処理する仕組みが.NETにはあります。
詳しくは後述のURLを見ていただくとして。

AppDomainクラスに、FirstChanceExceptionイベントというエラー処理用のイベントがあることを、恥ずかしながら最近知りました。
.NET4.0から登場したそうです。

このイベントでは、catchできなかった例外だけでなく、そもそもcatchされる直前の時点で呼び出されるイベントです。
あらゆる例外を真っ先に検知できる仕組みと言えます。

例外処理の幅が広がる一方、FirstChanceException内で例外が発生すると無限ループに陥るなど、使いどころ・使い方にちょっと工夫が必要になるようですね。

【例外をまとめてトラップするには？】
http://www.atmarkit.co.jp/ait/articles/1512/16/news026.html

IIS Expressで、他のマシンからもアクセスできるよう、リモートアクセスの設定をしたい場合についてです。
デフォルトでは他のマシンからのリモートアクセスは許可されていませんが、IISExpressの設定ファイルを書き換えることで、実現できます。

■手順１：applicationhost.configを探す
applicationhost.configは、IIS Expressの設定ファイルの一つであり、これを書き換えます。
このファイルは、次の場所にあります。

Visual Studio 2013以前：
c:\ユーザー\(ユーザー名)\ドキュメント\IISExpress\config

Visual Studio 2015以降：
ソリューションフォルダ内の.vsという名前のフォルダ
※隠しフォルダの設定になっています。


■手順２：設定ファイルの書き換え、その他作業
これ以降の詳しい手順は、下記サイトを参照してください。詳しく説明されています。
http://www.ipentec.com/document/document.aspx?page=windows-iis-express-accept-outer-host-access
http://architect-wat.hatenablog.jp/entry/20130513/1368425906
http://nakaji.hatenablog.com/entry/2014/09/19/022536


■手順３：上記手順でうまくいかない場合
この手順により、localhostのドメインでアクセスができなくなる場合もあります。その場合は、localhostのURLにも、ACLの設定を追加します。

netsh http add urlacl url=http://localhost:[ポート番号]/ user=everyone