Why use SharePoint Custom Timer Jobs?

Question

Am I wrong to think that Scheduled Windows Tasks running for example a console app can achieve everything that a SharePoint custom timer job can?

This has been my experience so far.

However, a C# Console app running as scheduled task is :

A. Easier to code - no learning curve required for a C# developer

B. Easier to deploy and redeploy, this really speeds up development if you're doing a lot of testing and incrementally updating your job. With a console app you could copy it to a network share, with a SharePoint custom timer job you need to RDC into the server, and it is about 5 steps you need to redeploy. You might say you can use powershell, yes you can but with the console app it is just pure convenience.

C. All the SharePoint purists out there thinking in the SharePoint box want everything housed under one roof - this isn't a good enough reason to add so much complexity to the job development and deployment process.

So what are the good reasons to use SharePoint custom timer jobs over Windows Scheduled tasks?

Answer 1

I think one of the biggest advantages is the granulair deployment methods that you can use.

• You can deploy in one package a whole application
• you can determine on what kind of servers timerjobs can run
• you can administer and schedule those timerjobs via the central admin/powershell
• you can make use of the sharepoint logging methods (diagnostic logging)
• sharepoint timer jobs can get backed up!

it lets you manage stuff in one place. Agreed, it costs some extra development time, but in the end of the ride, it pays off.

Check the blogpost of the genious wictor wilen for more information on different kind of timerjobs!: http://www.wictorwilen.se/Post/Timer-job-changes-and-additions-in-SharePoint-2010.aspx

Answer 2

Bas nailed it, but basically, if your farm is any more complex than a single server (which it should be unless it's a development environment), then custom timer jobs are far easier to maintain across your farm.

Also, if a server drops off the network, it will be synchronised and everything will come back online and up to date when it rejoins. You cannot guarantee this with scheduled tasks.

Timerjobs also have context of web or service application - console applications have no context and has to be explicitly defined - limiting extensibility of them.

Console applications have their uses, I use them a lot for one-off automated tasks that I need to do over thousands of site collections and tens of thousands of sites - this could be done in PowerShell also but I'm more fluent in C#. But for regular, recurring tasks, a timer job is the way to go.