http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Markus, The tasks sits in another assembly, this is just a quick way to list & execute them. Why configure the execution times using attributes? Because it is the simplest thing I could think about, and I know in advance what the times will be. If I will need the flexibility of an external way to specify that, I will add that. http://ayende.com/2775/scheduled-tasks-in-monorail-the-quick-dirty-solution#comment3http://ayende.com/2775/scheduled-tasks-in-monorail-the-quick-dirty-solution#comment3Fri, 21 Sep 2007 18:51:16 GMTNice way for testing but... I have always written a service for running scheduled tasks instead using a web application. The tasks themselves should be in an independent assembly and can be therefore accessed both interactively by web apps and testing projects as well as by the scheduler. Another question that I have is why you configure the application within the code using tags. I have made the experience that this leads to unneccessary compile cycles exactly when you don't need them (non-communicated changes in production environment, oh how I like them...). -Markus http://ayende.com/2775/scheduled-tasks-in-monorail-the-quick-dirty-solution#comment2http://ayende.com/2775/scheduled-tasks-in-monorail-the-quick-dirty-solution#comment2Fri, 21 Sep 2007 18:07:32 GMTI love this. I think that the level of benefit that this provides makes it elegant by default. Surely implementing a pattern like this, that makes development so much easier/faster/simpler, qualifies as a "good practice"? Your own satisfaction has to be the main benchmark. What I am trying to say is that if I wrote that code I wouldn't be too worried about people thinking it wasn't best practice :) http://ayende.com/2775/scheduled-tasks-in-monorail-the-quick-dirty-solution#comment1http://ayende.com/2775/scheduled-tasks-in-monorail-the-quick-dirty-solution#comment1Thu, 20 Sep 2007 23:37:59 GMT