Those are all non-points Michel.
Services are just EXEs just like scheduled tasks and Scheduled tasks can in fact run in the same execution context as services (when you configure a task you specify account and launch options just like a service).
If a service crashes it doesn't auto-restart any more than a scheduled startup task. Crash and you're hosed. In the end both service and scheduled task target are EXEs with a front end interface that launches them. The EXE is the key, the rest is just a launcher.
The only difference is perceived: Server admins tend to be more familiar with Service installation and automation as opposed to scheduled tasks. You can start and stop serviecs through the service interface, although you can do the same with an EXE that has a proper interface to do the same.
OTOH, it's easy enough to create services in .NET that it's not a big deal. Unfortunately Microsoft (as usual) didn't provide all the tools to build solid services (namely the service control interface to manage registration/uninstallation/start/stop etc.). There are libs out there that help with that.
+++ Rick ---
>>I would look at "launcher" technology. I think there are examples in Downloads here.
>
>Thanks
>
>>I don't like the idea of a Windows Service relying on the availability of an executable on a network share.
>
>Why?
>
>>What do you perceive as the advantages of a service over the scheduled tasks you have working now?
>
>First of all, an entry in Scheduled Tasks is usually about a task which has to be executed at a certain time, interval and so on. Our tasks have to be executed on a permanent basis. So, just to go in there and configure everything needed to achieve that is always over complicated. While I can do this remotely from my framework, there are a lot of changes from Windows 7 now and this complicates things. Then, from the SC command, I create an entry in the Services with one line of command to have a Windows Service to be registered. This is much easier.
>
>Secondly, the new environment forbids the login so we need to have something more easier to negotiate with and a service looks what we just need.
>
>In that new environment, I have several layers of security that I need to bypass. With a service, this will not be a complicated as the other way.
