Skip navigation.

Beware Of Deploying Debug Code In Production

Comment permalink 1 SomeNewKid |
Excellent article! Thanks for investigating the issue, and writing about it.
Comment permalink 2 Sam Amer |
Very informative stuff. Great work. Where on earth do you get these kinds of details that are really useful. Thanks for sharing.
Comment permalink 3 Milan Negovan |
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. :)
Comment permalink 4 Watcher |
Excellent article! Your site is one of the best out there. Keep up the good work. :)
Comment permalink 5 Amit |
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!
Comment permalink 6 Milan Negovan |
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.
Comment permalink 7 Robert Merriott |
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.
Comment permalink 8 Milan Negovan |
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.
Comment permalink 9 Netski |
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.
Comment permalink 10 Ben Henderson |
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.
Comment permalink 11 Milan Negovan |
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."
Comment permalink 12 nitin chittal |
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()
Comment permalink 13 Milan Negovan |
Wow, that's an interesting error message. I can't think of a reason why the debug tag would affect your data access logic...
Comment permalink 14 Manoj Kholia |
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
Comment permalink 15 nitin chittal |
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
Comment permalink 16 Lars Kjeldsen |
Excellent article!

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

Thanks
Comment permalink 17 Milan Negovan |
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).
Comment permalink 18 charlie arehart |
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.
Comment permalink 19 Patrick Tangelder |
Excellent article!

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

Thanks
Comment permalink 20 Phani |
Well analyzed and beautifully written.
Comment permalink 21 Balasaheb |
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
Comment permalink 22 Milan Negovan |
I think MSDN itself is a good enough resource to learn about the rest of the tags.
Comment permalink 23 Prashant |
Awesome article, thanks a lot for sharing the information.
Comment permalink 24 Rutger van Hagen |
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
Comment permalink 25 Rens |
Excellent article and well presented....one I was searching for a long time..
Comment permalink 26 Garth Hinman |
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.
Comment permalink 27 Milan Negovan |
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. ;)
Comment permalink 28 Tony |
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?
Comment permalink 29 Dave |
Great article! I'm off to change my Debug attribute straight away :-)
Comment permalink 30 Ritesh Uniyal |
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
Comment permalink 31 Jyotin |
Exellent Article.... :o)
Short and to the point...
Comment permalink 32 Angel |
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????
Comment permalink 33 Nawaz Ali |
Thank you for a great post and thanks for sharing it, i have learnt alot. Great post.
Comment permalink 34 KBN Sarma |
Excellent. This is the problem I am facing now.
Comment permalink 35 yashpal sharma |
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 :)
Comment permalink 36 Rukhsar Ahmad |
Thanks for this goodarticle.
Comment permalink 37 Priya |
Excellent Article, Thanks
Comment permalink 38 luciano |
Excellent Article, Thanks

Submit your comment

Please enter only text since all HTML tags except hyperlinks will be stripped. Hyperlinks will become live links. Any comments with flaming or offensive language will be deleted. Be courteous to other posters. Thank you.

Your name (required):
Your email (optional):
Your site's URL (optional):
Enter this number
Type in the number above:
Comment (required):