Click here to Skip to main content
15,889,116 members
Please Sign up or sign in to vote.
1.00/5 (3 votes)
See more:
i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.i deleted my question.
Posted
Updated 13-Oct-15 3:51am
v3

You're most of the way there, you just need to cheat a little.

Keeping scope in mind, you have a couple of options on how to appraoch this. Because I use test fixtures, I usually use a parallel execution process so that I'm not calling OnStart from my debug function. In your case, it would look like this:

C#
public void test()
{
   System.Diagnostics.EventLog.WriteEntry("ActiveDirectoryService","Active Directory Service Started");

   TrialChecker trial = new TrialChecker();
           
   if (!trial.TrialCheck()) 
   {
      Manager.Intialize(args, typeof(ADService));
   }
   
   while(true){} // Keep going until debug process is stopped.
}


Also, take the Thread.Sleep out of your Main().
 
Share this answer
 
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
 
Share this answer
 
v3

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900