Is there any relation between compilation debug="true" and in publish mode "release"

Question

Do I need to set the debug='false'

<compilation debug="false" targetFramework="4.0" /> 

Even if Publish my code in Release Mode.

Edit 1

As mentioned in the MSDN Compilation Overview It is done in two Phase

1. In first phase it compile the code into one or more assemblies
2. In second pahse translates MSIL into CPU-specific instructions for the processor on the computer running the application

Does publish code means the phase 1 part and
<compilation .... means the phase 2.

Answer 1

I don't fully understand your question. If you ask about that you manually need to set the debug='false' then the answer will depend on fact if there are files with config transformation in the project. Current Visual Studio standard web project template includes two files with config transformation: Web.Debug.config and Web.Release.config. These files contain config transformation to be applied during publishing your code. This is example of the default Web.Release.config file:

<?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> 

So, if you have Web.Release.config transformation file with the content similar to above and you use publish abilities of the Visual Studio (or according msbuild targets) then debug='true' attribute will be removed when you publish your project in release mode.

There are a lot of benefits to remove debug='true' from web config. This settings have effect not only to compiled dlls, but it affects what version of MS Ajax scripts will be loaded (if you use ASP.NET web forms and Script Manager control). Debug version of the MS Ajax library has a lot of checks (argument validation and etc) which are removed from release version of scripts. That's why debug version works slowly.

Answer 2

Yes, you need to use debug="false".

ASP .Net parses the .aspx or the views and creates some dll's which are different than the one you're compiling with Visual Studio. This setting is for these dll's.

ASP.NET Compilation Overview http://msdn.microsoft.com/en-us/library/ms178466(v=vs.100).aspx

Answer 3

For the debug=true vs debug=false discussion, there are many benefits in a production system to turning debugging off when publishing to production. The other answers and comments go more into detail on that (one big advantage that I've noticed in MVC4 apps is that JS and CSS bundles are minified when debug is off).

For the question about is publishing in Release mode sufficient, please read below:

If you are using the out-of-the-box transformation files that come with a new ASP.NET project, then no, you do not need to manually set it. However, if you don't have transformation files or you're not using them, then when releasing to production, you should change that setting.

Basically, when you publish an ASP.NET web site, what it'll do is build the application, apply the appropriate web.config transformation (based on the configuration selected in the "Settings" portion when using the "Publish Web" feature - which I'm assuming is where you're selecting the "Release" mode), and then publish the code out to the specified location.

Usually, to get you started with transformations, when you create an ASP.NET application in Visual Studio, you will be given two transformations for your web.config: web.Debug.config and web.Release.config (you can see them by clicking the expand symbol next to your web.config file).

If you don't have any transformations, you can create them by right clicking on the web.config file and selecting "Add Transform Config" and transformation files will be created for your various build configurations that you have in your solution.

As Maxim Kornilov mentioned in his reply, the out of the box web.Release.config contains this important transformation line: <compilation xdt:Transform="RemoveAttributes(debug)" />, which tells the application to remove the debug attribute from the <compilation tag, which will make the application publish with debugging turned off.

Note: if you don't see that RemoveAttributes(debug) in the config transformation that you're selecting when publishing, then the code might publish in debug mode.

If you really want to be sure of how the transformation is working, view the contents of the web.config after a publish, and you'll see the output of the transformation

Additionally, there is a tool at http://webconfigtransformationtester.apphb.com/ that will let you test how a web.config transformation will affect your web.config file.

Lastly, I'm a big fan of using a build-server and builds to publish my code when it's ready to go live (less folks need direct access to the server that way), so web.config transformation help me out quite a bit, from allowing me to change connection strings based on the environment that I'm deploying to, as well as to manage warning messages, etc. for the different environments (e.g., warning: test system, don't enter real data). By using transformations, the main collection of settings can stay in the web.config file (along with local dev settings, since hitting F5 usually doesn't apply a transformation, unless you have it publish locally to test), and each environment has its own config transformation that lives in source control, and with the same branch, code can be easily deployed to multiple environments without needing to change any code.

Answer 4

Theory

This article from 2006 lists the effects of debug="true":

1. ASP.NET requests will not timeout: for obvious debugging purposes
2. Batch compilation is turned off: pages and controls are compiled into separate assemblies
3. Code optimization: JIT compiler generates more efficient code

Number 3. is basically the same as what Release mode compilation does.

Code references

To give it some more investigation, I unleashed Re# on System.Web.Configuration.CompilationSection.Debug in one of my Web projects on Framework 4.0. Usage found were:

1. System.Web.Configuration.BrowserCapabilitiesCodeGenerator.GenerateAssembly
2. System.Web.Configuration.CompilationSection.GetCompilerInfoFromExtension
3. System.Web.Configuration.CompilationSection.GetCompilerInfoFromLanguage
4. System.Web.Compilation.CompilationUtil.GetRecompilationHash
5. System.Web.HttpRuntime.InitDebuggingSupport
6. System.Web.Compilation.CompilationUtil.IsDebuggingEnabled

These all seem to relate to the 3 points mentioned above.

Runtime effects

Note that the debug flag affects

1. on-the-fly compilation
2. precompilation (by wdproj)
3. and MSDeploy

While the net effect is mostly the same, changing the flag has no optimization effect on any code that is not compiled on the fly (like with wdproj precompilation).

Bundles

In addition, there's at least 1 other use of the debug flag: with resource bundles. Bundled JS and CSS will be outputted unaltered when the debug flag in the app/web config is on.