3

コード全体に多数の .NET アサーションがありますが、失敗することはありません。何らかの理由でアサーションが失敗した場合、ユーザーのデータを破損するよりも、プロセスを終了してクラッシュ ダンプを生成します。

未処理の例外が発生したときにメモリ ダンプを作成するようにすべてのアーキテクチャを設定したので、リリース ビルドでアサーションをそのように動作させたいと考えています。これをきちんと行う方法はありますか?それとも、すべてのAssert呼び出しを、アサートしてからスローする他の関数に置き換えるだけでよいのでしょうか?

4

2 に答える 2

4

1 つのオプションは、Debug.Assert の代わりに Trace.Assert を使用することです。

MSDN ページの備考セクションから:

リリース ビルドでアサーションを行う場合は、Trace.Assert メソッドを使用します。Debug.Assert メソッドは、デバッグ ビルドでのみ機能します。

編集:コメントへの応答:

が存在する理由は、本番ビルドTrace.Assertと同じ機能を提供するためです。Debug.AssertDebug.Assert でクラッシュ ダンプに使用するものと同じインフラストラクチャを使用できるはずですが、Debug ではなく Trace を参照する必要があります。MSDN の記事Assertions in Managed Codeから:

たとえば、TraceListener.Fail メソッドをオーバーライドして、[Assertion Failed] ダイアログ ボックスを表示する代わりに、イベント ログに書き込むことができます。

あなたの場合、おそらくあなたと同じTraceListenerものを再利用することができます（おそらく-あなたがそう言わない限りわかりません）クラッシュダンプを生成するために今日使用しています。唯一の違いは、それをDebug.ListenersではなくTrace.Listenersに追加することです。

于 2012-10-01T23:18:17.537 に答える
3

私の意見では、3 つの選択肢があります。

  • リリース ビルドではなく、デバッグ ビルドをクライアントにデプロイします。正確なスタック トレースを取得する場合は、これも優れたオプションです。これがデバッグビルドの目的です。

  • 別のオプションはCode Contractsです。これは、契約が満たされない場合、デフォルトで RaiseContractFailedEvent をスローします。

  • すぐに使用できる Assert 関数の代わりに、Guard ユーティリティを使用します。

于 2012-10-01T23:24:08.580 に答える