Excellent article! Thanks for investigating the issue, and writing about it.

Very informative stuff. Great work. Where on earth do you get these kinds of details that are really useful. Thanks for sharing.

Well, I gather as much information as I can and dig as deep as I can. I don't really have any fancy titles of MCP, MCSD, MVP, "insider", etc (neighter am I going after them). Well, I guess my only title is CTO, but that's it. :)

Excellent article! Your site is one of the best out there. Keep up the good work. :)

Interesting article. As I understand it, the gist of the article is the line :"If certain pages change a lot, move them out to a separate folder if possible to spare the rest of the code from constant recompilations!". The thing I'm not able to understand is, on the production server, the pages are not going to be changed once they're put there. So that means they're not going to be recompiled constantly. When a release is done, the recompilation will be a one-time thing and once the dlls are there they stay there. Have I got this right? Thanks for sharing!

Well, sometimes you have to update a web site with minor changes. A page here and there. There's no need to redeploy everything-everything. Or maybe some pages are "assembled" by server-side code. If it's done aggressively I can imagine there will be quite a bit of recompilation going on.

Good article. However, I have one main question.
Is this also true for projects compiled in VS.Net or only pages within inline code? I have always assumed that this setting was ignored in projects compiled in VS.Net.

Robert, this is about any change to an aspx page, i.e. a change to the markup, not code-behind.

VS.NET doesn't bother with the debug setting from web.config. Once you build your project in VS.NET and deploy it, compiled code-behind DLLs don't get recompiled no matter what.

Useful information, presented in a very confusing format. You're on to something here, but the way it is written does not do it justice at all. At some points it even seems like you contradict yourself.

Milan,

Thanks for taking the time to put this information together. A couple of observations:

1. Under the heading [debug="false"], the first sentence says:

“When the debug attribute is set to TRUE ASP.NET conducts a batch compilation, i.e. all files in the current folder are compiled into one DLL.”

It sounds like you're describing behavior when debug is set to FALSE. Did you make a typo or have I missed something?

2. You conclude:

“If certain pages change a lot, move them out to a separate folder if possible to spare the rest of the code from constant recompilations!”

You explained that when an ASPX file is modified, a new assembly containing ONE class that represents the modified ASPX file, is created. Given this fact, why do you assert that rest of the code in the folder while be recompiled?

Again, I really enjoyed the material. Not many people are talking about this topic.

Ben, great catch! Thank you. It is supposed to say that when debug="false" batch compilation happens.

To answer your second question let me quote the "Coding Strategies With The Microsoft ASP.NET Team" book:

"The batch compilation has directory granularity, so pages that are updated can cause an assembly to be invalidated and cause additional compilations. But once an assembly is loaded, it can't be unloaded until the application is unloaded. Instead, new assemblies are created for the updated content. Plan accordingly on sites with a high rate of churn. Pages that are updated frequently should be separated from relatively stable pages so that the number of recompilations is limited."

the article is excellent and well presented. i actually serached for the article and read it becuase i had deployed a web application with the debug flag as 'true' and i felt the site is a bit lethargic. by chance i discovered this tag and changed it... i am not sure about the performance after the change... but a part of the website, which deals with several xml creations/upadations on submit bombed. the message that the sql database returned is reporduced below. after i changed it back, it worked fine. am still trying to find out whether it was related to the debug tag. has anybody encountered such an issue.

the error msg:

2004-09-01 10:52:06,843 [3112] ERROR ErrorLogger [] -
-------------------------------------
NAVManager : Void UpdateStatus(Int64, Int64, Int64, System.String)
Exception: System.InvalidOperationException
Message: This SqlTransaction has completed; it is no longer usable.
Source: System.Data
at System.Data.SqlClient.SqlTransaction.Rollback()
2004-09-01 10:52:06,843 [3112] ERROR ErrorLogger [] - at System.Data.SqlClient.SqlTransaction.Rollback()
Exception: System.InvalidOperationException
Message: This SqlTransaction has completed; it is no longer usable.
Source: System.Data
at System.Data.SqlClient.SqlTransaction.Rollback()

Wow, that's an interesting error message. I can't think of a reason why the debug tag would affect your data access logic...

I have found this problem .. and here debug = true, will change it to False and get back to u if realy works fine...

This SqlTransaction has completed; it is no longer usable.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidOperationException: This SqlTransaction has completed; it is no longer usable.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[InvalidOperationException: This SqlTransaction has completed; it is no longer usable.]
System.Data.SqlClient.SqlTransaction.Rollback() +115
QTicket.TicketQueue.btnAssign_Click(Object sender, EventArgs e)
System.Web.UI.WebControls.Button.OnClick(EventArgs e) +108
System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler. RaisePostBackEvent(String eventArgument) +57
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33
System.Web.UI.Page.ProcessRequestMain() +1292

hi manoj,
any luck on this one... got a bit side tracked on another project... i have still kept the debug tag = true.
rgds,
nitin

Excellent article!

Can anyone explain to me how the Debug setting in Web.config differs from the Debug/Release dropdown in VS.NET?

Thanks

It's pretty confusing that there's a Release/Debug mode in VS.NET and a debug option in web.config.

The one in VS.NET controls what kind of DLLs are compiled. Debug ones cotain symbol information in pdb files. These DLLs are much slower, although their benefit is that symbol information allows to build a meaningful trace stack when an exception is thrown.

Once DLLs are compiled and deployed, the debug option in web.config determines how they are handled (whether batch compilation happens and so forth).

Here's some info that may be valuable to some of your readers (and you may want to add to your list of how to manually stop the web app if desired).

You can manually stop the web app by calling the UnloadAppDomain method of the System.Web.HttpRuntime class. No argument required. Just call it and the app is unloaded. As with your other approaches, the next request will start up the app domain.

Excellent article!

Indeed the ASPX pages will be compiled, regardless the build is made with Debug or Release option in VS.Net.

Thanks

Well analyzed and beautifully written.

I like this document on web.config's < compilation >tag.
But I need more information on web.config.
I want to know more about web.config
Please guide me on remaining tag

I think MSDN itself is a good enough resource to learn about the rest of the tags.

Awesome article, thanks a lot for sharing the information.

Very good article. BUT I've got a problem around this subject. When i set my asp.net webservice to DEBUG=FALSE a method in my webservice hangs ather a minute. This webservice is proccessing a lot of data. With DEBUG=TRUE everything is going fine. Someone got an idea?? Thanx!

Rutger van Hagen

Excellent article and well presented....one I was searching for a long time..

Does anybody know where to find the whitepaper, "Deployment Issues for .NET Applications", to read more about NGEN and JIT compilation as mentioned at the end of the article. Google, mdsn and msdn archive serches produce no results.

This is strange. I looked at the whitepaper with the exact same title at the Patterns and Practices, but its content is different. I guess they edited it heavily since then.

I do happen to have an older copy which you are welcome to download. The mentioned Chapter 4 is there. ;)

Well, let me first say that its an excellent article. What I could conclude from the article is that really, the debug attrubute will only matter if any files are changed after deployment. If none of that file are changed after depolyment, setting this attribute to true or false shouldnt really matter.Please correct me if I am wrong.

Also when they say that setting this attribute to false will improve performance, are the factors that you described in the article the only ones affecting performance, or there any others?

Great article! I'm off to change my Debug attribute straight away :-)

This is an excellent article with excellent presentation. It is upto the point and very clearly explains each and every thing that is being shown

Exellent Article.... :o)
Short and to the point...

V useful article. Here's a weird behaviour that I'm hoping someone will have an opinion on. On our system some directories of aspx pages can compile to show text updates no problem BUT some directories can't and we continue to see old versions. Eventually the application restarts and all the updates show and directories that didn't work before do update again. At some point the server decides it can't update different directories whilst going on updating others.

What is most likely to be going on in this case? You can always add new pages to even a directory that won't compile and it will compile the new pages. It feels like .NET does compile the page but it's still linking to the old DLL so the changes aren't showing... But only in some random directories! Does this make any sense to anyone????

Thank you for a great post and thanks for sharing it, i have learnt alot. Great post.

Excellent. This is the problem I am facing now.

Hi Milan,
Such a great article i was looking for it from long time becoze there is not so many post those tell us about the hiden things as u told in article but u have written a excellent article.
thank you :)

Thanks for this goodarticle.

Excellent Article, Thanks

Excellent Article, Thanks