を設定する必要がありますかdebug='false'
<compilation debug="false" targetFramework="4.0" />
Release Modeでコードを公開しても。
MSDN Compilation Overview に記載されているように、2 つのフェーズで行われます。
コードを発行するとは、フェーズ 1 の部分を
<compilation ....意味し、フェーズ 2 を意味します。
私はあなたの質問を完全には理解していません。手動で debug='false' を設定する必要があることについて尋ねた場合、答えは、プロジェクトに構成変換を含むファイルがあるかどうかによって異なります。現在の Visual Studio 標準 Web プロジェクト テンプレートには、構成変換を含む 2 つのファイル (Web.Debug.config と Web.Release.config) が含まれています。これらのファイルには、コードの公開中に適用される構成変換が含まれています。これは、デフォルトの Web.Release.config ファイルの例です。
<?xml version="1.0"?>
<!-- For more information on using web.config transformation visit http://go.microsoft.com/fwlink/?LinkId=125889 -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<!--
In the example below, the "SetAttributes" transform will change the value of
"connectionString" to use "ReleaseSQLServer" only when the "Match" locator
finds an atrribute "name" that has a value of "MyDB".
<connectionStrings>
<add name="MyDB"
connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
-->
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
<!--
In the example below, the "Replace" transform will replace the entire
<customErrors> section of your web.config file.
Note that because there is only one customErrors section under the
<system.web> node, there is no need to use the "xdt:Locator" attribute.
<customErrors defaultRedirect="GenericError.htm"
mode="RemoteOnly" xdt:Transform="Replace">
<error statusCode="500" redirect="InternalError.htm"/>
</customErrors>
-->
</system.web>
</configuration>
したがって、上記のような内容の Web.Release.config 変換ファイルがあり、Visual Studio (または msbuild ターゲットに従って) の公開機能を使用する場合、リリースでプロジェクトを公開するときに debug='true' 属性が削除されます。モード。
Web 構成から debug='true' を削除すると、多くの利点があります。この設定は、コンパイルされた dll だけでなく、読み込まれる MS Ajax スクリプトのバージョンにも影響します (ASP.NET Web フォームと Script Manager コントロールを使用している場合)。MS Ajax ライブラリのデバッグ バージョンには、スクリプトのリリース バージョンから削除された多くのチェック (引数の検証など) があります。そのため、デバッグ バージョンの動作が遅くなります。
debug=true対の議論についてdebug=falseは、本番システムに公開するときにデバッグをオフにすることには、本番システムに多くの利点があります。他の回答とコメントはそれについて詳しく説明しています (MVC4 アプリで気づいた大きな利点の 1 つは、デバッグがオフのときに JS と CSS バンドルが縮小されることです)。
十分なモードで公開することに関する質問についてはRelease、以下をお読みください。
新しい ASP.NET プロジェクトに付属の標準の変換ファイルを使用している場合は、手動で設定する必要はありません。ただし、変換ファイルがない場合や使用していない場合は、運用環境にリリースするときにその設定を変更する必要があります。
基本的に、ASP.NET Web サイトを公開すると、アプリケーションがビルドされ、適切な web.config 変換が適用されます (「Web の公開」機能を使用するときに「設定」部分で選択された構成に基づいて -これは、「リリース」モードを選択している場所であると想定しています)、指定された場所にコードを公開します。
web.Debug.config通常、変換を開始するために、Visual Studio で ASP.NET アプリケーションを作成すると、web.config に対して次の 2 つの変換が提供されますweb.Release.config。ファイル）。
変換がない場合は、web.config ファイルを右クリックして [変換構成の追加] を選択することで作成できます。変換ファイルは、ソリューションにあるさまざまなビルド構成に対して作成されます。
マキシム・コルニロフが返信で述べたように、すぐに使用できる web.Release.config には、この重要な変換行が含まれています:タグから属性<compilation xdt:Transform="RemoveAttributes(debug)" />を削除するようにアプリケーションに指示します。これにより、アプリケーションはデバッグをオフにして公開されます。debug<compilation
注:RemoveAttributes(debug)発行時に選択している構成変換でそれが表示されない場合は、コードがデバッグ モードで発行されている可能性があります。
変換がどのように機能しているかを本当に確認したい場合は、公開後に web.config の内容を表示すると、変換の出力が表示されます。
さらに、http: //webconfigtransformationtester.apphb.com/ には、web.config 変換が web.config ファイルにどのように影響するかをテストできるツールがあります。
最後に、私は build-server と builds を使用してコードを公開する準備が整ったときにコードを公開するのが大好きなので (この方法でサーバーに直接アクセスする必要がある人は少なくなります)、web.config 変換はかなり役に立ちます。 、デプロイ先の環境に基づいて接続文字列を変更したり、さまざまな環境の警告メッセージなどを管理したりできます (例: 警告: テスト システム、実際のデータを入力しないでください)。変換を使用することで、設定の主要なコレクションを web.config ファイルに残すことができ (ローカルの開発設定と共に、F5 キーを押しても通常は変換が適用されないため、ローカルで公開してテストする必要はありません)、各環境にはソース管理に存在する独自の構成変換、および同じブランチで、
2006 年のこの記事には、次の効果が記載されていますdebug="true"。
番号 3. は、基本的にリリース モードのコンパイルと同じです。
さらに調査するために、System.Web.Configuration.CompilationSection.DebugFramework 4.0 の Web プロジェクトの 1 つで Re# を解き放ちました。見つかった使用法は次のとおりです。
これらはすべて、上記の 3 点に関連しているようです。
デバッグフラグが影響することに注意してください
最終的な効果はほとんど同じですが、フラグを変更しても、オンザフライでコンパイルされていないコードには最適化効果がありません(wdproj プリコンパイルなど)。
さらに、デバッグ フラグには他に少なくとも 1 つの用途があります:リソース バンドルを使用します。バンドルされている JS と CSS は、アプリ/Web 構成のデバッグ フラグがオンの場合、変更されずに出力されます。