How to tel if IDE debugger is atatched.

[colin]

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 =^.^=

 

[Peter Duniho]

[...]
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?

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?

Pete

 

[Jon Skeet [C# MVP]]

[...]
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.

 

[colin]

[...]
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

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 =^.^=

 

[Peter Duniho]

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,
Pete

 

[Peter Duniho]

[...]

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).

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.

Pete

 

[Pedro Luna Montalvo]

Check the property: System.Diagnostics.Debugger.IsAttached.

Pedro Luna,
Gye, Ecu

 

[colin]

[...]

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.

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

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 =^.^=