serviço do windows vs tarefa agendada

Quais são os contras e vantagens dos serviços do Windows versus as tarefas agendadas para executar um programa repetidamente (por exemplo, a cada dois minutos)?

Atualizar:

Quase quatro anos depois da minha resposta original e esta resposta está muito desatualizada. Desde que o TopShelf surgiu, o desenvolvimento do Windows Services ficou fácil. Agora você só precisa descobrir como apoiar o failover …

Resposta Original:

Eu realmente não sou fã do Windows Scheduler. A senha do usuário deve ser fornecida como @moodforall , acima, o que é divertido quando alguém altera a senha desse usuário.

O outro grande incômodo com o Windows Scheduler é que ele é executado de forma interativa e não como um processo em segundo plano. Quando 15 janelas do MS-DOS aparecerem a cada 20 minutos durante uma session RDP, você irá chutar a si mesmo que não as instalou como Serviços do Windows.

Seja qual você escolher, eu certamente recomendo que você separe seu código de processamento em um componente diferente do aplicativo do console ou do Windows Service. Em seguida, você tem a opção de chamar o processo de trabalho de um aplicativo de console e conectá-lo ao Agendador do Windows ou usar um Serviço do Windows.

Você verá que agendar um serviço do Windows não é divertido. Um cenário bastante comum é que você tem um longo processo em execução que deseja executar periodicamente. Mas, se você estiver processando uma fila, não será necessário duas instâncias do mesmo trabalhador processando a mesma fila. Então, você precisa gerenciar o timer, para ter certeza de que o seu processo de longa duração tenha funcionado por mais tempo do que o intervalo do timer atribuído, ele não inicia novamente até que o processo existente seja concluído.

Depois de ter escrito tudo isso, você pensa, por que eu não usei apenas Thread.Sleep? Isso permite que eu deixe o thread atual continuar em execução até que tenha terminado e, em seguida, o intervalo de pausa entra em ação, a thread entra em suspensão e inicia novamente após o tempo necessário. Arrumado!

Então você lê todos os conselhos na internet com muitos especialistas dizendo como é uma prática ruim de programação:

http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx

Então você vai coçar a cabeça e pensar para si mesmo, WTF, Desfazer checkouts pendentes -> Sim, tenho certeza -> Desfazer todo o trabalho de hoje ….. droga, droga, droga ….

No entanto, eu gosto desse padrão, mesmo que todo mundo ache que é uma porcaria:

Método OnStart para a abordagem single-thread.

protected override void OnStart (string args) { // Create worker thread; this will invoke the WorkerFunction // when we start it. // Since we use a separate worker thread, the main service // thread will return quickly, telling Windows that service has started ThreadStart st = new ThreadStart(WorkerFunction); workerThread = new Thread(st); // set flag to indicate worker thread is active serviceStarted = true; // start the thread workerThread.Start(); } 

O código instancia um segmento separado e anexa nossa function de trabalho a ele. Em seguida, ele inicia o thread e permite que o evento OnStart seja concluído, para que o Windows não pense que o serviço está interrompido.

Método de trabalho para a abordagem de encadeamento único.

 ///  /// This function will do all the work /// Once it is done with its tasks, it will be suspended for some time; /// it will continue to repeat this until the service is stopped ///  private void WorkerFunction() { // start an endless loop; loop will abort only when "serviceStarted" // flag = false while (serviceStarted) { // do something // exception handling omitted here for simplicity EventLog.WriteEntry("Service working", System.Diagnostics.EventLogEntryType.Information); // yield if (serviceStarted) { Thread.Sleep(new TimeSpan(0, interval, 0)); } } // time to end the thread Thread.CurrentThread.Abort(); } 

Método OnStop para a abordagem single-thread.

 protected override void OnStop() { // flag to tell the worker process to stop serviceStarted = false; // give it a little time to finish any pending work workerThread.Join(new TimeSpan(0,2,0)); } 

Fonte: http://tutorials.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1%3a_Use_a_Separate_Thread (Dead Link)

Eu tenho executado muitos serviços do Windows como este há anos e funciona para mim. Eu ainda não vi um padrão recomendado que as pessoas concordem. Apenas faça o que funciona para você.

Alguma desinformação aqui. O Windows Scheduler é perfeitamente capaz de executar tarefas em segundo plano, sem janelas aparecendo e sem necessidade de senha. Execute-o sob a conta NT AUTHORITY \ SYSTEM. Use este interruptor schtasks:

/ ru SYSTEM

Mas, sim, para acessar resources de rede, a prática recomendada é uma conta de serviço com uma política de senha separada que não expira.

EDITAR

Dependendo do seu SO e dos requisitos da tarefa em si, você poderá usar contas menos privilegiadas do que o Localsystem com a opção /ru .

Do bom manual ,

 /RU username A value that specifies the user context under which the task runs. For the system account, valid values are "", "NT AUTHORITY\SYSTEM", or "SYSTEM". For Task Scheduler 2.0 tasks, "NT AUTHORITY\LOCALSERVICE", and "NT AUTHORITY\NETWORKSERVICE" are also valid values. 

O Agendador de Tarefas 2.0 está disponível no Vista e no Server 2008.

No XP e Server 2003, o system é a única opção.

Qual é a sobrecarga de iniciar e sair do aplicativo? Cada dois minutos é bastante frequente. Um serviço provavelmente permitiria que o sistema fosse executado com mais facilidade do que executar seu aplicativo com tanta frequência.

Ambas as soluções podem executar o programa quando o usuário não está logado, então não há diferença. Escrever um serviço é um pouco mais complicado do que um aplicativo de desktop comum – você pode precisar de um cliente GUI separado que se comunique com o aplicativo de serviço via TCP / IP, pipes nomeados, etc.

Do ponto de vista de um usuário, eu me pergunto qual é mais fácil de controlar. Os serviços e as tarefas agendadas estão praticamente fora do alcance da maioria dos usuários não técnicos, ou seja, nem sequer percebem que existem e podem ser configurados / parados / reprogramados e assim por diante.

No desenvolvimento .NET, eu normalmente começo desenvolvendo um aplicativo de console, que executará toda a saída de log para a janela do console. No entanto, isso é apenas um aplicativo de console quando ele é executado com o comando argument /console . Quando é executado sem esse parâmetro, ele atua como um Serviço do Windows, que continuará sendo executado no meu próprio cronômetro programado personalizado.

Os Serviços do Windows, na minha opinião, são normalmente usados ​​para gerenciar outros aplicativos, em vez de ser um aplicativo de longa execução. OU .. eles são aplicativos pesados ​​de execução contínua, como SQL Server, BizTalk, Conexões RPC, IIS (embora o IIS tecnicamente ofereça o trabalho para outros processos).

Pessoalmente, sou a favor de tarefas agendadas no Windows Services para tarefas e aplicativos de manutenção repetitivos, como cópia / synchronization de arquivos, envio em massa de emails, exclusão ou arquivamento de arquivos, correção de dados (quando outras soluções alternativas não estão disponíveis).

Para um projeto, estive envolvido no desenvolvimento de 8 ou 9 Serviços do Windows, mas eles ficam na memory, ociosos, comendo 20 MB ou mais de memory por instância. As tarefas agendadas farão seus negócios e liberarão a memory imediatamente.

A palavra ‘serv’ice compartilha algo em comum com’ serv’er. Espera-se que esteja sempre em execução e ‘serv’e. Uma tarefa é uma tarefa.

Encenação. Se eu sou outro sistema operacional, aplicativo ou dispositivo e eu chamo um serviço, espero que esteja em execução e espero uma resposta. Se eu (os, app, dev) precisar executar uma tarefa isolada, então executarei uma tarefa, mas se eu quiser me comunicar, possivelmente uma comunicação bidirecional, quero um serviço. Isso tem a ver com a maneira mais eficaz de comunicar duas coisas, ou uma única coisa que queira executar uma única tarefa.

Depois, há o aspecto do agendamento. Se você quiser que algo seja executado em um horário específico, agende. Se você não sabe quando vai precisar, ou precisa “on the fly”, serviço.

Minha resposta é mais filosófica por natureza, porque é muito semelhante a como os humanos interagem e trabalham com o outro. Quanto mais entendermos a arte da comunicação e as “entidades” entenderem o seu papel, mais fácil se torna essa decisão.

Toda a filosofia à parte, quando você está “rapidamente prototipando”, como meu departamento de TI geralmente faz, você faz o que for preciso para fazer face às despesas. Uma vez que a prototipagem e a prova de conceito estão fora do caminho, geralmente no planejamento e descoberta iniciais, você precisa decidir o que é mais confiável para a sustentabilidade a longo prazo.

OK, então, em conclusão, é altamente dependente de muitos fatores, mas esperamos que isso forneça insight ao invés de confusão.

  1. É mais fácil configurar e bloquear os serviços do Windows com as permissions corretas.
  2. Os serviços são mais “visíveis”, o que significa que todos (isto é: técnicos) sabem onde procurar.

Um serviço do Windows não precisa ter ninguém conectado, e o Windows possui resources para parar, iniciar e registrar os resultados do serviço.

Uma tarefa agendada não requer que você aprenda como escrever um serviço do Windows.

Por que não fornecer os dois?

No passado eu coloquei os bits ‘core’ em uma biblioteca e fiz uma binding para Whatever.GoGoGo () tanto em um serviço quanto em um aplicativo de console.

Com algo que você está triggersndo a cada dois minutos, as probabilidades são decentes, não está fazendo muito (por exemplo, apenas uma function de tipo “ping”). Os wrappers não devem conter muito mais do que uma única chamada de método e algum registro.

Esta é uma pergunta antiga, mas gostaria de compartilhar o que enfrentei.

Recentemente, recebi um requerimento para capturar a captura de canvas de um radar (de um site de Meteorologia) e salvá-lo no servidor a cada 10 minutos.

Isso exigiu que eu usasse o WebBrowser. Eu costumo fazer serviços do Windows, então eu decidi fazer este serviço também, mas iria continuar falhando. Isso é o que eu vi no caminho do módulo Fawler do Visualizador de events : C: \ Windows \ system32 \ MSHTML.dll

Como a tarefa era urgente e eu tinha muito menos tempo para pesquisar e experimentar, decidi usar um simples aplicativo de console e acioná-lo como uma tarefa e executá-lo sem problemas.

Eu realmente gostei do artigo de Jon Galloway recomendado em resposta aceita por Mark Ransom.

Recentemente, as senhas nos servidores foram alteradas sem me reconhecer e todos os serviços falharam na execução, pois não puderam fazer logon. Então, ppl afirmando no artigo comenta que isso é um problema. Eu acho que os serviços do Windows podem enfrentar o mesmo problema (Pls. Me corrija se eu estiver errado, eu sou jus um novato)

Além disso, a coisa mencionada, se estiver usando janelas de agendador de tarefas pop-up ou a janela do console aparece. Eu nunca enfrentei isso. Pode aparecer, mas é pelo menos muito instantâneo.

Os serviços do Windows querem mais paciência até que seja feito. Tem um pouco de debugging e instalação. É sem rosto. Se você precisar de uma tarefa que deve ser feita a cada segundo, minuto ou hora, escolha o serviço do Windows.

Tarefa agendada é rapidamente desenvolvida e tem um rosto. Se você precisar de uma tarefa diária ou semanal, poderá usar a tarefa agendada.

    Intereting Posts