Supporting two executables in a solution-2

[Morris]

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

 

[Joe Cool]

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

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?

 

[Konrad Neitzel]

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

 

[Morris]

Thanks Mr. Konrad,
I beleive you offerd an acceptable resolution to the problem but I'm afraid
I don't know how to implement your idea. I run the solution under VS 2008
debugger. What excatly should I do?
Regards
Morris

 

[Peter Duniho]

Thanks Mr. Konrad,
I beleive you offerd an acceptable resolution to the problem but I'm afraid
I don't know how to implement your idea. I run the solution under VS 2008
debugger. What excatly should I do?

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's 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

 

[Konrad Neitzel]

Hi Peter!

instead just use the System.Diagnostics.Debugger.Break() method, which is
basically a hard-coded break-point.

That is a very nice idea that I didn't 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