+2  A: 

I think I'd probably use a single service which can be easily configured to run the various tasks (so that if you want to separate them later, you can do so).

Scheduling specific applications is okay and certainly a simpler way of working, but this feels more like a service to me. Of course, if you separate out the "doing stuff" logic from the "invocation" side of things, you can easily switch from one to the other.

The efficiency side of things is unlikely to change much by this decision. Do you have good grounds to be worried about the overall efficiency at the moment? Have you profiled your applications to work out where any bottlenecks are? I'd say they're unlikely to be in the scheduling side of things.

Jon Skeet
I agree my initial idea was to create a Service. However, as I don't really have any experience creating services I thought (for quickness) I would create a solution that would be easy enough to get up and running. I think my main concern is the PDF Creation. Task 2 monitors a folder that can contains emails which trigger a report to be generated. This taks roughly 5-10 seconds to process, my concern is when the mailbox begins to get bigger, with more and more report emails coming in it could start to slow down and even start to miss it's 5 minute deadline.
James
@James: Well want do you want it to do if it *does* take longer than 5 minutes? At the moment presumably another task will start processing the same folder, which sounds like a bad idea. You could use a computer-wide Mutex to avoid this - it's basically an easy way to see of another process is already running. The idea of prototyping using a scheduled console app and then migrating it to a service later is a fine one IMO.
Jon Skeet
Yeah what would happen at the moment is the Tasks will just start again which starts to cause an issue as if a PDF report is generating, the email is still sitting in the inbox (as it hasn't yet been moved) so it will pick up the same email and start processing it again. I suppose to avoid this I could move it to a temporary folder. However, I would prefer if the application was able to determine whether to trigger the task or not. I will have a look into the Mutex stuff thanks.
James
+1  A: 

A service sounds like the right way to approach this.

Long running subtasks such as PDF generation are well suited to perform using the asynchronous programming method, i.e. using worker threads that call back to the parent thread upon completion. This way the monitor tasks can run independently of the action tasks.

d91-jal
Thanks, I was 99% sure it was the correct way, just really needed some clarification incase there was a better way.
James

related questions