making debug=true in web.config slows the application

[Luis Esteban Valencia]

Hi,

I want in debug mode debug=true. In release (production), no reason debug to
be true but the questions are:
1. Does it slow the application (holding debug=true)
2. If yes, how can I solve the problem so that in debug mode debug=true and
in realse debug=true. To hold 2 separate files - seems not so good idea


Additional question: is there any correlation between debug in web.config
file and Project settings?
thanks

 

[Curt_C [MVP]]

dude.... with the sheer amount you've posted lately have you thought you may
want to get a book or try google?
Now I dont think anyone here has issues with helping out, it's why we come
here, but it almost seems like either you aren't trying at all or you just
want someone else to do your work for you....

Just my $.02 worth, not meant to offend, just offering constructive advise.

 

[Curt_C [MVP]]

use two different web.config files, one with production settings, one with
development settings, dont release this with your apps unless you have to
make a change.

It's what most people I know do, or they adjust their web.config prior to
release, then reset it in dev.

 

[Luis Esteban Valencia]

thanks! but My Issues sometimes are difficult and I cant find them on
google! or maybe I dont know to search.

 

[Karl Seguin]

Luis,
I have to agree with Curt. I've skipped over one of your questions earlier
simply because you've asked so much. I'm not sure that you realize this but
most of the people who answer questions on here do so voluntarily. I
don't mind helping out, but most of the stuff you ask could easily be
encouvered via google or from a book...that's fine once, but frankly, why
don't you just ask us to write your application for you?

Karl

 

[Scott Allen]

A query like the following should get you in the right direction, no?

http://www.google.com/search?hl=en&lr=&c2coff=1&q=asp.net+debug+release+settings+site:microsoft.com

 

[MWells]

Luis, I'm not aware of a way to automate configuration differences in
Web.config across DEV / TEST / PROD. In our environment we manage this as
follows;

+ All web projects have a /deploy/test and /deploy/prod subdirectory,
containing any files that supercede the DEV versions. Web.config is the
most common entry here, but on occasion certain XML files, etc may change
during deployment.
+ We maintain the DEV, TEST, and PROD versions of these files separately.
DEV files being in the normal location within the source. All files are
managed in source control.
+ At deployment, we run a custom tool that deploys the files from (e.g.)
DEV to TEST, and then overlays the files from the /deploy/test directory.
This ensures that anything different between DEV and TEST, or between TEST
and PROD, can be handled automatically at deployment.

If you cannot find a better option, you might consider going this route.
There are other advantages to the custom-deployment-tool approach as well,
like being able to send email notifications to the TEST team, logging
deployment events in a database, updating change histories from source
control, avoiding the copy of undesired files (*.cs, *.scc, etc) and
directories (/deploy/*, /debug/*, etc), temporarily displaying a "The site
is being updated" message, and so on.