ASP.NET Webアプリケーションの.dllファイルをWebサイトの/ bin /ディレクトリにアップロードすると、リリースビルドを再コンパイルするのではなく、デバッグバージョンを使用する上で不利な点があります。ASP.NET WebサイトDLL：デバッグバージョンとリリースバージョン
たとえば、Webサイトでローカルで作業している間は、ビルド構成は[デバッグ]に設定されています。状況が良くなると、私は先に進んでウェブサイト/ webappの最新の.dllをアップロードします。代わりにその時点でビルド構成をリリースしてコンパイルし、そのバージョンの.dllをサーバーにアップロードする必要がありますか？
私はこの質問が重複しないことを望んでいます。私は、件名に似たような言葉で他の多くの質問を読んだが、私の質問に直接関係するものは見つけられなかった。
おかげで、それの多くは、個々のニーズが何であるかに依存し
デバッグアセンブリを使用して実行すると、パフォーマンスが向上しますが、メモリを増やすことはできますが、それほど大したものではありません。実際にリリースされているリリースビルドのみを展開するべきです。野生で予期せぬ動作が予想される場合は、デバッグアセンブリの使用を検討します。そのため、未処理の例外からより有用な情報が得られます。実際のパフォーマンス "gotcha"はあなたのweb.configにdebug="true"を持っています。
アダム。一般的に、パフォーマンス上の理由から、デバッグビルドを本番環境に移行するのは嫌です。発行されたデバッグコードは、明らかに最適化されておらず、コードの実行を遅くする可能性のあるデバッグシンボルを含んでいます。
一方、私は、コードが例外をスローするときに行番号などを見やすくするために、デバッグビルドをプロダクションに置くという方針をとっていました。私はこのポジションに同意すると言っているわけではありませんが、私は人々がそれをやっているのを見ました。
Scott Hanselmanは、両方の世界のベストを得るために、DebugとReleaseのハイブリッドバージョンを実行するのに良い投稿を持っていますhere。
リリースビルドとデバッグビルドのパフォーマンスに大きな違いがあるアプリケーションはほとんどありません。中小規模のアプリケーションを実行していて、キャッチしていないバグがあると思われる場合は、デバッグビルドを使用してください。
Jinx :-)後で同じ考えを投稿しました。 –
Webサイトの量が少ない場合、デバッグアセンブリのパフォーマンス上のペナルティは、測定可能な方法で決して見られません。ボリュームが高い場合は、代わりにロギング/インスツルメンテーションコードの他の手段を調べてください。
大量のWebサイトでは、大量のストレスと負荷テストを実行して、アプリケーションを実際に運用する前に中断しないようにする必要があります。私はデバッグアセンブリでそのテストの最初のパスを実行します（おそらくあなたが物を壊してしまうので、どこを見ても分かりやすくなります）。次に、リリースアセンブリと同じ方法で動作することを確認するためにリリースアセンブリを繰り返します。
これは、Webアプリケーションプロジェクト（[ファイル]> [新規プロジェクト]で作成）か、Webサイト（[ファイル]> [新規Webサイト]で作成）かを明記してください。 –