By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,453 Members | 932 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,453 IT Pros & Developers. It's quick & easy.

RQOTD -- random question of the day

P: n/a
How is compiling code in debug different from compiling in release?

:\\derian
Nov 20 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Cor
Hi Derian,
One of the most importants, you don't have to remember to put it back before
you start debugging.
Cor
How is compiling code in debug different from compiling in release?

Nov 20 '05 #2

P: n/a
holy cow!!! i was just asking myself that this weekend! i was going to run a
performance test to see if both exe's ran the same or if the debug version
was slower (more implied event delegates and hooks possibly setup to
communicate w/ an ide or trace util?).

i don't know...very good question!

steve
":\\derian" <de****@someplace.com> wrote in message
news:OT**************@TK2MSFTNGP11.phx.gbl...
| How is compiling code in debug different from compiling in release?
|
| :\\derian
|
|
Nov 20 '05 #3

P: n/a
Main thing is the creation of the (.pdb) file.

The (.pdb) file IS created during a debugging compilation, which stores info
about each CALL statement in the compiled file. This is what gives you the
info when an unhandled exception occurs, and also holds variables to be
displayed in the Watch windows in the IDE while in Break Mode.

Release compilation does not include this (.pdb) file, thus cannot be
debugged.....

":\\derian" <de****@someplace.com> wrote in message
news:OT**************@TK2MSFTNGP11.phx.gbl...
How is compiling code in debug different from compiling in release?

:\\derian

Nov 20 '05 #4

P: n/a
* "Cor" <no*@non.com> scripsit:
One of the most importants, you don't have to remember to put it back before
you start debugging.
How is compiling code in debug different from compiling in release?


And very important too: Don't distribute the Debug version.

;-)

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #5

P: n/a
Hi Derian,

One difference is that the Debug version contains more - guess what -
debugging information. ;-)

I don't actually know exactly what that info is, but part of it is the
line number in the source files of the current statement. This can be
determined from the stack trace.

Here are a couple of stack routines which might be interesting. The first
one shows the name of itself and the method that called it. The second show
the line number from which it was called. [This is untested as it doesn't work
in v2002 which is what I'm using]

Regards,
Fergus

<code>
Public Function MeAndMyCaller As String
Dim CurrentStack As New System.Diagnostics.StackTrace
Dim Myself As String = CurrentStack.GetFrame(0).GetMethod.Name _
& " " &CurrentStack.GetFrame(0).GetFileLineNumber
Dim MyCaller As String = CurrentStack.GetFrame(1).GetMethod.Name _
& " " &CurrentStack.GetFrame(1).GetFileLineNumber
Return "In " & Myself & vbCrLf & "Called by " & MyCaller
End Function

Public Function MyLineNumber As String
Dim CurrentStack As New System.Diagnostics.StackTrace
Dim MyCaller As String = CurrentStack.GetFrame(1).GetMethod.Name
Return CurrentStack.GetFrame(1).GetFileLineNumber.ToStrin g
End Function

Sub SomethingOrOther
Dim S As String = vbCrLf & MeAndMyCaller
S &= vbCrLf & vbCrLf & MyLineNumber
MsgBox (S)
End Sub
</code>
Nov 20 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.