System.Diagnostics.Debugger.Break
(1)
Visual Studio
(1)
Debugger.Break
(1)
Thread.Sleep
(1)
Debugger
(1)
Thread
(1)
TlyJust
(1)
Breakpoints
(1)

Supporting two executables in a solution-2

Asked By Morris
09-Feb-10 07:35 AM
Hi all,
Two days ago,  In 2/6/10 I started here a thread named "Supporting two
executables in a solution".
I did add the second executable but its breakpoints are dissabled immediatly
after startup(its not the startup project).
Is it possible to enable them and how?
Regards
Morris

tlyJust what would be the purpose in that?

Joe Cool replied to Morris
09-Feb-10 08:54 AM
tly

Just what would be the purpose in that? If it is not the startup
project, just what point would there be to have breakpoints in it?

Hi Morris!

Konrad Neitzel replied to Morris
09-Feb-10 09:06 AM
Hi Morris!

I think the main problem is, that the debugger is attached to your first
process already and when you start another process, the debugger will
not be attached to it.

I think it is possible to attach to the process through another
debugger. Simply add a loop for some time directly at the start so you
have time to connect to the process after it was started.

At least I see no other possibility at the moment.

With kind regards,

Konrad

Thanks Mr.

Morris replied to Konrad Neitzel
09-Feb-10 01:21 PM
Thanks Mr. Konrad,
I beleive you offerd an acceptable resolution to the problem but I am afraid
I do not know how to implement your idea. I run the solution under VS 2008
debugger. What excatly should I do?
Regards
Morris
Morris wrote:If you want to debug a second process, you need a second instance
Peter Duniho replied to Morris
09-Feb-10 01:28 PM
If you want to debug a second process, you need a second instance of the
debugger.

Konrad suggets inserting a delay, to provide enough time to manually
start the second instance of Visual Studio.  However, a) he suggests a
loop, which in fact one would normally just call Thread.Sleep() passing
an appropriate amount of time (30000 milliseconds, for example), and b)
IMHO if one is going to modify the code being debugged (and in this
situation, that is may well be necessary, depending on exactly how the
second process runs and where your breakpoints are), you should probably
instead just use the System.Diagnostics.Debugger.Break() method, which
is basically a hard-coded break-point.

Using Debugger.Break(), when the second process hits that hard-coded
breakpoint, the OS should display a "just-in-time debugging" dialog,
asking if you want to debug the process.  And of course, at that point
you would answer "yes".  :)

Pete
Hi Peter!
Konrad Neitzel replied to Peter Duniho
09-Feb-10 02:21 PM
Hi Peter!


That is a very nice idea that I did not know so far. Will give that a try
next time instead of using the delay. Maybe it will work with services, too.

(And yes, a simple sleep could be ok with a normal console application. We
used it in a service start only and multiple smaller sleeps in a loop are
better in case the service is stopped after a start which is handled inside
the loop, too)

Thanks for this information.

Konrad
Post Question To EggHeadCafe