Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers 4

up vote 5 down vote accepted

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.

share|improve this answer
    
Thanks some great tips in there.. –  Anonymous Jan 12 '10 at 17:13
add comment

You can use

System.Diagnostics.Debugger.Launch();

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

System.Diagnostics.WriteLine("sometext","MYCATEGORY");

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

share|improve this answer
    
wow 3 replies just in the time it took me to write my answer :-D –  Anders Rask Jan 12 '10 at 13:14
    
Thanks nice tips there too.. Debug View has saved me on a number of occasions. –  Anonymous Jan 12 '10 at 17:14
add comment

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.

share|improve this answer
    
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 '10 at 17:14
add comment

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

share|improve this answer
    
Thanks for the link and console app idea.. –  Anonymous Jan 12 '10 at 17:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.