It depends on your architecture how easily you can debug the code running a Windows Service. Most propably you use a layered architecture which allows you to directly call the code doing the critical work. E.g. by a Winforms test application or via a administrative page in your web application.
But what if you have to find out what is going wrong in the service infrastructure itself? I usually install the service on my local machine directly from my <Service>\bin\Debug folder. Of course you will always have to make sure the service is stopped if you want to rebuild.
When running the service you can attach to the process and hopefully are fast enough to step in at the critical part of your code. Otherwise you can use the Debugger.Launch() method. I would suggest to put this call into the OnStart() of the service or into your Start() block :
When the framework executes the Debugger.Launch() method and prompts you to select the debugger, select the VS instance that shows the service code and continue to run the service under the control of the debugger.
Be careful that the debugger dialog does not show up in a released version. To avoid this you can check with #if DEBUG or use command arguments which you provide in the service properties:
Alternatively implement a while-loop which waits for the debugger to be attached. You can find a code snippet here.
No comments:
Post a Comment