I have developed a number of SharePoint Timer Jobs and they are always a bit more painful to debug and test than other areas of SharePoint.

I was wondering what tools/techniques other people use to do their debugging and testing of SharePoint Timer Jobs?

4 Answers 4


My biggest issue with testing timer jobs was getting the job to start so that I could debug it. It seems like I when I reset the timer service whenever I deployed new code and when the service restarted, even though I had my job to run every minute, sometimes it would take up to an hour for it to "catch up" and get around to running my timer job.

I think the best way is to make your timer job business logic code seperate from spjobdefinition and build unit tests for it. That way you do most of your testing using unit tests and when you are happy that it is working correctly, build the spjobdefinition that just calls your business logic code. That way you have less testing in which you have to depend on the timer service.


You can use


to attach a debugger (Visual Studio) instead of attaching the timer job in VS.

Also i tend to use DebugView alot to just write out asserts or messages like


Another tip for testing is to encapsulate the logic in its own class. Then you can test (and unit test) the code first in for example a console application. Then you wont have to wait for timer job to execute etc.

hth Anders Rask

Helpful references Creating, Deploying and Debugging Custom Timer Jobs

  • wow 3 replies just in the time it took me to write my answer :-D Jan 12, 2010 at 13:14
  • Thanks nice tips there too.. Debug View has saved me on a number of occasions.
    – Anonymous
    Jan 12, 2010 at 17:14

A couple of small things you have probably already considered.

Stop and restart the Timer service as part of the pre-build event to release any of your solution's GAC dlls.

Rather than attaching to the process using the debugger I prefer to use System.Diagnostics.Debugger.Break();

For other SharePoint related guidelines, check out our free SharePoint Development Guidelines.

  • Nice that sounds like a great way once you have got to the point of being able to deploy it properly. Thanks
    – Anonymous
    Jan 12, 2010 at 17:14

As both Anders and Steve have pointed out, write the main processing of your timer job in a separate Class Library. For debugging "wrap" a Console App around it, and when you're happy wrap it in a timer job. If at a later point you want to debug, you use your Console App again - F5 and there you go.

On a related note, check out SharePoint Layered Architecture App here on SharePointOverflow.com


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.