in precompiled asp.net

问题:

I'm deploying a precompiled and all-page-merged website using Web Deployment Projects on Visual Studio 2008. Note that all assemblies and projects have been compiled in Release mode.

All my pages are pre-compiled in release mode. So they wont be recompiled, they'll just be loaded by runtime. In that case when the page compilation is not required, Setting <compilation debug="true"> in system.web will make any difference ?

回答1:

Check out the excellent links below:

• ASP.NET Memory: If your application is in production… then why is debug=true
• Don’t run production ASP.NET Applications with debug=”true” enabled

Basically:

• Your code will run slower because of the overhead of debugging support.
• Scripts and images are not cached on the client side because you don't want things to be cached in development if you're constantly making changes and debugging.
• Requests are not timed out. Again when you're debugging your code, you don't want to get a request timeout.

None of the above is desirable. You will find more disadvantages in the above links.

回答2:

According to the documentation:

Specifies whether to compile debug binaries rather than retail binaries

However, having just quickly reflected through System.Web, I can see the debug flag is used (directly or indirectly) by the following:

• Runtime compilation (ASPX/ASCX/MASTER)
• Code generation of the browser capabilities files
• HttpDebugHandler, which is used during a debugging session

As a result, if your site is precompiled you will not receive a performance hit. However, as the HttpApplication will respond to the DEBUG http verb, you open yourself up to security problems.

In short, set debug=false, even if your site is precompiled.

Edit: debug=true will result in a performance (see Mehmet Aras's answer) hit for caching and no execution timeout, but it will not reduce execution speed for compiled pages.

回答3:

From the blog post ASP.Net – Never again fear publishing your website with debug=true:

• The compilation of ASP.NET pages takes longer (as batch compilation is turned off)
• Code typically executes slower
• Memory footprint is increased
• Scripts and images downloaded from the WebResources.axd handler are not cached
• Requests do not time out (this is bad, as in a production environment we dont want requests to be stuck indefinitely)

The article goes on to recommend setting the production server machine.config to ensure retail deployment mode is forced which essentially means debug is always false.