Azure などに発行するときに正常に動作する Web 構成変換をセットアップしました。しかし、ローカルで実行しているときに web.config 変換が実際に適用されない場合、リリースとデバッグのどちらをローカルで選択しても意味がないように思われます。
「実行」をクリックしたときにこれらの変換を適用する方法はありますか? そうでない場合、そのドロップダウンを使用する意味は何ですか? 私は修辞的に尋ねるのではなく、本当に興味があります。
Azure などに発行するときに正常に動作する Web 構成変換をセットアップしました。しかし、ローカルで実行しているときに web.config 変換が実際に適用されない場合、リリースとデバッグのどちらをローカルで選択しても意味がないように思われます。
「実行」をクリックしたときにこれらの変換を適用する方法はありますか? そうでない場合、そのドロップダウンを使用する意味は何ですか? 私は修辞的に尋ねるのではなく、本当に興味があります。
web.config 変換の考え方は、環境間で変更されるいくつかの設定があるということです。たとえば、ローカル開発接続文字列があり、ローカルで実行/デバッグするときは常にそれを使用します。ただし、本番サーバーに公開する場合は、本番 DB を使用する必要があります。ビルド時のデバッグ構成とリリース構成では、プロジェクトのビルド方法(最も一般的には、デバッグ シンボルの生成方法またはコンパイラの最適化の有効化) の一部の設定が変更されるだけですが、web.config 変換では、デプロイされる内容が変更されます ( web.config)。
F5 で web.config 変換をローカルに適用したい場合は、それを可能にする拡張機能があります。 スロー チーターもその 1 つです。ただし、多くの場合、ローカルで実行するときは常に web.config がほぼ一定のままであるため、これはおそらく必要ありません。
ほとんどすべての IDE にはリリース モードとデバッグ モードがあります。デバッグ モードでは、コードはデバッグ フラグを使用してコンパイルされ、最適化はあまり行われません。つまり、ビルドされたプログラムとソース コードの間の関係が保持されます。このようにして、コードを実行できます。デバッガーを使用すると、アプリケーションの実行フローを追跡および制御できるツールです。たとえば、コード内のある状況で変数に格納された値などです。これにより、アプリケーションに発生する可能性のあるセマンティックな問題が明らかになります、つまり、コードが実際に期待どおりに動作していない場合 (ほとんどの人は、どこでも少なくとも 1 回は print ステートメントを使用してこれを行います)。
リリース モードは、デバッグ/プロファイリング フラグを使用せずに、アプリケーションの最適化されたバージョンを生成することを目的としています。
これは Web アプリケーションのデバッグ モードとは何の関係もないことに注意してください。実行時エラーが発生したときに自動化されたビューを設定して、より多くの情報を表示します。それは、その下で実行されている実際のプログラムの最適化またはデバッグと関係があるだけです。したがって、デバッグ モードまたはリリース モードを設定しても、Web アプリケーションがトレースバックを表示するかどうかは変わらないかもしれませんが、サーバーでローカルに実行されているアプリケーションのパフォーマンスは確実に変わります。
よろしく。