I have no idea why did you decide that the code before "
if(#DEBUG)
" can be considered equivalent to the code after. If you tried to run it interactively, your debugger would really stop if you set a breakpoint after "
else
", but it you run it as a service controller, you would not get there, by the following reason: you would have to start the service first and then use Visual Studio's "
Debug / Attach to
Process". You cannot do it before you have the process to debug running, but by the time you do it, the process will most likely pass fist two lines and enter your infinite wait state. The debugger will be attached, but the process will remain in the wait state. It makes no sense at all.
Basically, you have two ways for debugging: by attaching the debugger to a process or interactively. To attach a debugger, you can wait for just enough time in the thread you want to debug, not infinitely, and then, when the process is started, set a breakpoint after the sleep call. This is pretty boring, but sometimes it will help you.
You can also debug most of the problems on the process started interactively. For that purpose, you can use the fact that you can program slightly different behavior depending on how your process is started. I would not touch
if (DEBUG)
. Instead, you can use identical process code, not depending on any precompiler settings. To tell interactive mode from the service, you can use the static variable
System.Environment.UserInteractive
. I developed a whole technique based on this flag; it allowed me to debug 99% of problems interactively,
the way you asked about in your question. Of course,
no thread sleep should be used.
For further ideas, please see my past answer:
Configure Windows Service with UI[
^].
—SA