例外がスローされるという話を備忘録として書いておきます。スローされ、以下のエラーメッセージが出るそうです。メッセージの長さが制限を超えています。超えるというのはレアなのか、日本語のエラーメッセージでググっても参考になる記事はヒットしませんでした。他の記事がヒットします。設定することだそうです。プロパティを使って応答ヘッダのサイズの許容最大値を設定できるそうです。起こっていた問題に対応できないことを指摘されて追加したのかもしれませんね。アプリの構成ファイルの保存場所はどこかという話を書きます。別に生成され、別の場所に保存されます。いう名前のファイルが作られます。この他に構成ファイルが作られるケースがあります。ウィンドウのサイズです。ユーザーがウィンドウのサイズを変更してアプリを閉じると変更後の値を保存して、次にアプリを立ち上げたときは保存した値でウィンドウのサイズを設定するようにコーディングしています。値が保存されているはずです。個々のユーザーに適用する個別構成によって格納場所が違うそうです。すべてのユーザーに適用するグローバル構成」に該当するようです。いう名前で保存されています。場所を表示し、その内容をメモ帳で開いて表示したものです。値が反映されています。ちなみに、ファイルパスはプログラムで取得することができます。プロパティを使って取得します。オブジェクトを取得できます。[デバッグの開始(S)]でなら以下のような例外が捕捉されるが、[デバッグなしで開始(H)]では捕捉されないという話を書きます。「非同期処理でデバッグ時・ビルド実行時で処理結果が異なる?」というスレッドから来ています。拡張メソッドを使ってマルチスレッドで処理するケースを考えます。呼び出しを行っています。これが不正なクロススレッドコールになります。いうエラーメッセージを表示します。ところが[デバッグなしで開始(H)]で実行した場合は例外はスローされず、あたかもこのコードは正常終了したかのように見えます。集約的例外ハンドラで捕捉してアプリケーションを終了させるということもできません(そもそも例外がスローされないので)。いう訳で、特にマルチスレッドアプリを開発している場合は必ず[デバッグの開始(S)]で実行して動作確認をするようにした方がよさそうです。false)に設定すれば不正なクロススレッドコールで例外をスローさせることはできます。オーバーヘッドが増えてパフォーマンスに影響があるでしょうからリリース前には元に戻さなければならず、そんな面倒なことをするより[デバッグの開始(S)]で実行して確認するのが正解だと思います。blog2010年5月にこのブログを立ち上げました。関係のトピックス、ブログ2はそれ以外のトピックスに分けました。