Also you would have likely to disable compiler optimization to be able to do
so (so that it can still properly map executable statements to the original
source code line)...
So unless you really need this very frequently it's likely better to add
some instrumentation code when needed to break down the code path in
"segements" so that you can know in whihc area the problem lies when needed.
This is what I finally done instead of spending time to find out how to use
PDBs with my release builds...
"Patrice" <http://www.chez.com/scribe/a écrit dans le message de news:
%2***************@TK2MSFTNGP05.phx.gbl...
My understanding is that the difference is based on the build mode (debug
vs release). I gave this a try when I saw that PDB generation was actually
not coupled with debug builds (it likely just stores wih offset correspond
to which source file line) but for now it seems to make no difference...
For now I jsut keep track of the current location in a variable that is
dumped when it errors in the rare cases where having directly the location
would help...
Let us know.
Patrice
"Wayne Sepega" <Me******@community.nospama écrit dans le message de
news: e5**************@TK2MSFTNGP02.phx.gbl...
>We are currently having an issue with one of our web applications. Some
users receive an exception when using the app, but the method that has
the error in the stack trace has a few places that could cause the error.
So my question is, what are the CONS to deploying the PDB's that are
built with the application if you build in release mode?
Security? performance? anything else?
Thanks
Wayne
