| Groups | Blog | Home |
c# : How to tel if IDE debugger is atatched.
[quoted text, click to view] wrote: > [...] > How can you tell if the debugger is atatched when you run it from the > visual C# express ? The debugger is always attached when you run it from the IDE. Could you explain what you're trying to do more clearly? Is there something about the Debugger.IsAttached property that doesn't fulfill the need? [quoted text, click to view] > im thinking of dumping everything when the debuger is atatched and doing > a > compare when it isnt or visa versa... Why not just dump all the data you want to compare all the time (in a special debugging build, of course). Then run once with the debugger, save the data, run again without the debugger, save the data, then compare the two collections of saved data. Why is knowing whether the debugger is attached or not important?
On Fri, 04 Jan 2008 12:47:14 -0800, Jon Skeet [C# MVP] <skeet@pobox.com>
[quoted text, click to view] wrote: >> The debugger is always attached when you run it from the IDE. > > No, that's not true. If you use Ctrl+F5 instead of F5 (Start without > Debugging instead of Start Debugging), the program runs without the > debugger being attached. You can't break into it, stop it or anything > like that - it's a completely separate process. Ah. Duh. Completely forgot about that (never use it myself :) ). Thanks,
On Fri, 04 Jan 2008 13:27:17 -0800, colin <colin.rowe1@ntworld.NOSPAM.com>
[quoted text, click to view] wrote: > [...] >> Why is knowing whether the debugger is attached or not important? > > to at least save it in different files for a start, > then hopefully compare it in the program, > so I can see where its not doing exactly the same thing ... I would personally not worry about checking for the debugger being attached, and just save the files twice, renaming the first one before I run the program again to generate the second one. Since the code is diagnostic-only, why complicate things by introducing a new dependency? Of course, it would be important to write the data out as text. But if you do that, it should be very easy to do a direct comparison (I'd probably use Windiff, which comes with Visual Studio, as it will detect and display all of the differences for you in an easy-to-use UI). [quoted text, click to view] > can I re atatch the debugger ? You should be able to attach to the process from within VS, yes...and as far as I know, the Debugger.IsAttached property will update to reflect the current state. But you'll find out soon enough if that's not true, assuming you do go ahead and include debugger-attached-specific code. :)
Hi,
Im still trying to sort out whats cuasing the difference when the debugger is attatched... Ive finsihed re writting a lot of the code and although its a heck of a lot faster it still gives the same visual diferences, at least now it finishes a run in just second or two as oposed to nearly a minute. How can you tell if the debugger is atatched when you run it from the visual C# express ? ie either f5 or ctrl-f5, ive entered a command line parameter "debuger_atatched" but this is used both for f5 and ctrlf5 is used, the only way I can make it know the diference is to run it from outside the IDE with no parameters. Is there any other way ? im thinking of dumping everything when the debuger is atatched and doing a compare when it isnt or visa versa... thanks Colin =^.^=
[quoted text, click to view]
Peter Duniho <NpOeStPeAdM@nnowslpianmk.com> wrote: > > [...] > > How can you tell if the debugger is atatched when you run it from the > > visual C# express ? > > The debugger is always attached when you run it from the IDE. No, that's not true. If you use Ctrl+F5 instead of F5 (Start without Debugging instead of Start Debugging), the program runs without the debugger being attached. You can't break into it, stop it or anything like that - it's a completely separate process. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
Check the property: System.Diagnostics.Debugger.IsAttached.
Pedro Luna, Gye, Ecu "colin" <colin.rowe1@ntworld.NOSPAM.com> escribió en el mensaje de noticias:eEvfj.2391$a61.2230@newsfe3-win.ntli.net... [quoted text, click to view] > Hi,
> > Im still trying to sort out whats cuasing the difference when the debugger > is attatched... > > Ive finsihed re writting a lot of the code and although its a heck of a > lot faster it still gives the same visual diferences, > at least now it finishes a run in just second or two as oposed to nearly a > minute. > > How can you tell if the debugger is atatched when you run it from the > visual C# express ? > ie either f5 or ctrl-f5, ive entered a command line parameter > "debuger_atatched" but this > is used both for f5 and ctrlf5 is used, the only way I can make it know > the diference is to > run it from outside the IDE with no parameters. > > Is there any other way ? > > im thinking of dumping everything when the debuger is atatched and doing a > compare when it isnt > or visa versa... > > thanks > > Colin =^.^= >
[quoted text, click to view]
"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message news:op.t4e91mnp8jd0ej@petes-computer.local... > On Fri, 04 Jan 2008 11:18:34 -0800, colin <colin.rowe1@ntworld.NOSPAM.com> > wrote: > >> [...] >> How can you tell if the debugger is atatched when you run it from the >> visual C# express ? > > The debugger is always attached when you run it from the IDE. > > Could you explain what you're trying to do more clearly? Is there > something about the Debugger.IsAttached property that doesn't fulfill the > need? ah thats does it, duno why i didnt think to look for something like that :) [quoted text, click to view] > >> im thinking of dumping everything when the debuger is atatched and doing >> a >> compare when it isnt or visa versa... > > Why not just dump all the data you want to compare all the time (in a > special debugging build, of course). Then run once with the debugger, > save the data, run again without the debugger, save the data, then compare > the two collections of saved data. > > Why is knowing whether the debugger is attached or not important? to at least save it in different files for a start, then hopefully compare it in the program, so I can see where its not doing exactly the same thing ... can I re atatch the debugger ? Colin =^.^=
[quoted text, click to view]
"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message news:op.t4fc0kyj8jd0ej@petes-computer.local... > On Fri, 04 Jan 2008 13:27:17 -0800, colin <colin.rowe1@ntworld.NOSPAM.com> > wrote: > >> [...] >>> Why is knowing whether the debugger is attached or not important? >> >> to at least save it in different files for a start, >> then hopefully compare it in the program, >> so I can see where its not doing exactly the same thing ... > > I would personally not worry about checking for the debugger being > attached, and just save the files twice, renaming the first one before I > run the program again to generate the second one. Since the code is > diagnostic-only, why complicate things by introducing a new dependency? I didnt think of that but having the name indicate wether its attached is reassuring. [quoted text, click to view] > Of course, it would be important to write the data out as text. But if > you do that, it should be very easy to do a direct comparison (I'd > probably use Windiff, which comes with Visual Studio, as it will detect > and display all of the differences for you in an easy-to-use UI). I added more and more data to the dump, only finding a few diferences in floats of +/- 1 to 3 in the last of 7 digits, but then noticed Xna.Framework.Ray.IntersectPlane was returning null in one but not the other, wich affected wether it thought surfaces were hidden or not wich explains the visual differences. it does a ray trace from a point wich is intended to be inside the model to the point of interest then checks that ray against every surface to determine if its behind that surface or not. there didnt seem to be a pattern so I dumped every call to it. so I now have 2 x 45mb of data to compare, Windiff has been churning cpu time for the last 1/2 hour trying to expand the comparisons lol... although the windiff I have came with Visual studio v6 I also have WinMerge but that spends ages at 100% cpu too [quoted text, click to view] >> can I re atatch the debugger ? > > You should be able to attach to the process from within VS, yes...and as > far as I know, the Debugger.IsAttached property will update to reflect the > current state. > > But you'll find out soon enough if that's not true, assuming you do go > ahead and include debugger-attached-specific code. :) bah i have the express version seems its not available ... no wonder I cldnt find it. Colin =^.^=
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |