Respostas:
Atualizar:
Quase quatro anos depois da minha resposta original e esta resposta está muito desatualizada. Desde que TopShelf surgiu, o desenvolvimento de Serviços do Windows ficou fácil. Agora você só precisa descobrir como oferecer suporte ao failover ...
Resposta Original:
Eu realmente não sou um fã do Windows Scheduler. A senha do usuário deve ser fornecida conforme @moodforall indica acima, o que é divertido quando alguém altera a senha desse usuário.
O outro grande aborrecimento 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 sessão RDP, você se surpreenderá por não as ter instalado como serviços do Windows.
O que quer que você escolha, certamente recomendo que você separe seu código de processamento em um componente diferente do aplicativo de console ou do serviço do Windows. Então você tem a escolha de chamar o processo de trabalho de um aplicativo de console e conectá-lo ao Windows Scheduler ou usar um serviço do Windows.
Você descobrirá que agendar um serviço do Windows não é divertido. Um cenário bastante comum é que você tem um processo de longa execução que deseja executar periodicamente. Mas, se estiver processando uma fila, você realmente não quer duas instâncias do mesmo trabalhador processando a mesma fila. Portanto, você precisa gerenciar o cronômetro, para ter certeza de que se o seu processo de longa execução foi executado por mais tempo do que o intervalo do cronômetro designado, ele não será iniciado novamente até que o processo existente seja concluído.
Depois de escrever tudo isso, você pensa, por que não usei apenas Thread.Sleep? Isso me permite deixar o encadeamento atual continuar em execução até terminar e, em seguida, o intervalo de pausa é ativado, o encadeamento adormece e recomeça após o tempo exigido. Arrumado!
Em seguida, você lê todos os conselhos na internet com muitos especialistas dizendo como é uma prática de programação realmente ruim:
Então, você coçará a cabeça e pensará consigo mesmo, WTF, Desfazer check-outs pendentes -> Sim, tenho certeza -> Desfazer todo o trabalho de hoje ... droga, droga, droga ...
No entanto, eu gosto desse padrão, mesmo que todo mundo pense que é uma porcaria:
Método OnStart para a abordagem de thread único.
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 thread separado e anexa nossa função 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 foi interrompido.
Método de trabalho para a abordagem de thread único.
/// <summary> /// 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 /// </summary> 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 de thread único.
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)
Há anos que executo muitos serviços do Windows como este e funciona para mim. Ainda não vi um padrão recomendado com o qual as pessoas concordem. Basta fazer o que funciona para você.
NT AUTHORITY\NetworkServiceé uma conta com privilégios limitados.
Alguma desinformação aqui. O Windows Scheduler é perfeitamente capaz de executar tarefas em segundo plano, sem janelas que aparecem e sem a necessidade de senha. Execute-o na conta NT AUTHORITY \ SYSTEM. Use esta opção de schtasks:
/ ru SISTEMA
Mas sim, para acessar recursos de rede, a prática recomendada é uma conta de serviço com uma política de senha que não expira separada.
EDITAR
Dependendo do seu sistema operacional e dos requisitos da tarefa em si, você pode usar contas menos privilegiadas do que o Localsystem com a /ruopção.
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 no Server 2003, systemé a única opção.
Local Service(aka NT AUTHORITY\LocalService) em vez de LocalSystem(aka .\LocalSystem). O primeiro tem direitos limitados, enquanto o último é um administrador
LocalServicee NetworkServiceestão disponíveis em schtasksv2 Vista em diante e deve ser preferido, sempre que possível. Na época, isso se referia ao schtasksno XP e no Server 2003, que aceita apenas o Systemcomo o parâmetro pelo manual da versão antiga technet.microsoft.com/en-us/library/bb490996.aspx
Qual é a sobrecarga de iniciar e encerrar o aplicativo? A cada dois minutos é quase sempre. Um serviço provavelmente deixaria o sistema funcionar de maneira mais suave 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 nenhuma diferença aí. Escrever um serviço envolve um pouco mais do que um aplicativo de desktop normal - 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. Ambos os serviços e tarefas agendadas estão praticamente fora do alcance da maioria dos usuários não técnicos, ou seja, eles nem perceberão que existem e podem ser configurados / interrompidos / reprogramados e assim por diante.
No desenvolvimento .NET, normalmente começo desenvolvendo um aplicativo de console, que executará todas as saídas de registro na janela do console. No entanto, este é apenas um aplicativo de console quando executado com o argumento de comando /console. Quando é executado sem esse parâmetro, ele atua como um serviço do Windows, que permanecerá em execução em meu próprio cronômetro programado codificado personalizado.
Os serviços do Windows, em minha opinião, são normalmente usados para gerenciar outros aplicativos, em vez de ser um aplicativo de longa duração. OU .. eles são aplicativos pesados em execução contínua, como SQL Server, BizTalk, RPC Connections, IIS (embora o IIS tecnicamente descarregue o trabalho para outros processos).
Pessoalmente, prefiro tarefas agendadas em vez de Windows Services para tarefas de manutenção repetitivas e aplicativos, como cópia / sincronização de arquivos, envio de e-mail em massa, exclusão ou arquivamento de arquivos, correção de dados (quando outras soluções alternativas não estão disponíveis).
Em um projeto, estive envolvido no desenvolvimento de 8 ou 9 Serviços do Windows, mas eles ficam na memória, ociosos, consumindo 20 MB ou mais de memória por instância. As tarefas programadas farão seus negócios e liberarão a memória 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 chamo um serviço, espero que ele esteja em execução e recebo uma resposta. Se eu (os, app, dev) precisar apenas executar uma tarefa isolada, irei executar uma tarefa, mas se espero me comunicar, possivelmente uma comunicação bidirecional, quero um serviço. Isso tem a ver com a maneira mais eficaz de duas coisas se comunicarem ou de uma única coisa que deseja executar uma única tarefa.
Depois, há o aspecto da programação. Se você quiser que algo seja executado em um horário específico, programe. Se você não sabe quando vai precisar, ou precisa "na hora", serviço.
Minha resposta é mais filosófica por natureza, porque isso é muito semelhante a como os humanos interagem e trabalham com os outros. Quanto mais entendemos a arte da comunicação e as "entidades" entendem seu papel, mais fácil se torna essa decisão.
Filosofia à parte, quando você está "prototipando rapidamente", como meu departamento de TI costuma fazer, você faz o que precisa para pagar as contas. Uma vez que o protótipo e a prova de conceito estão fora do caminho, geralmente no início do planejamento e descoberta, você tem que decidir o que é mais confiável para a sustentabilidade a longo prazo.
OK, em conclusão, é altamente dependente de vários fatores, mas espero que isso tenha fornecido uma visão em vez de confusão.
Um serviço do Windows não precisa ter ninguém conectado e o Windows tem recursos para interromper, iniciar e registrar os resultados do serviço.
Uma tarefa agendada não requer que você aprenda a escrever um serviço do Windows.
NT AUTHORITY\LocalService, ou NT AUTHORITY\NetworkService). Qualquer senha fornecida é ignorada porque as contas não têm senha.
Por que não fornecer os dois?
No passado, coloquei os bits 'principais' em uma biblioteca e encapsulei uma chamada para Whatever.GoGoGo () em um serviço e também em um aplicativo de console.
Com algo que você está disparando a cada dois minutos, as chances são decentes de que ele não está fazendo muito (por exemplo, apenas uma função do tipo "ping"). Os wrappers não devem conter muito mais do que uma única chamada de método e algum registro.
Esta é uma questão antiga, mas gostaria de compartilhar o que tenho enfrentado.
Recentemente, recebi a solicitação de capturar a imagem de um radar (de um site meteorológico) e salvá-la no servidor a cada 10 minutos.
Isso exigiu que eu usasse WebBrowser. Eu costumo fazer serviços do Windows, então decidi fazer esse serviço também, mas ele continuava travando. Isso é o que eu vi no caminho do módulo de falha do Visualizador de eventos : C: \ Windows \ system32 \ MSHTML.dll
Como a tarefa era urgente e eu tinha muito menos tempo para pesquisar e experimentar, decidi usar um aplicativo de console simples e o disparei como uma tarefa e ele foi executado sem problemas.
Gostei muito 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 ao executar, pois eles não puderam fazer logon. Assim, as pessoas afirmam nos comentários do artigo que isso é um problema. Acho que os serviços do Windows podem enfrentar o mesmo problema (por favor, corrija-me se eu estiver errado, sou apenas um novato)
Além disso, a coisa mencionada, se usando janelas pop-up do agendador de tarefas ou a janela do console aparece. Eu nunca enfrentei isso. Pode aparecer, mas é pelo menos muito instantâneo.
Geralmente, a mensagem central é e deve ser que o próprio código deve ser executável a partir de cada "gatilho / cliente". Portanto, não deve ser ciência do foguete mudar de uma abordagem para a outra.
No passado, usávamos mais ou menos sempre os Serviços do Windows, mas como também mais e mais clientes mudam para o Azure passo a passo e a troca de um aplicativo de console (implantado como uma tarefa agendada) para um WebJob no Azure é muito mais fácil do que um serviço do Windows, nos concentramos nas tarefas agendadas por enquanto. Se encontrarmos limitações, apenas aceleramos o projeto de serviço do Windows e chamamos a mesma lógica de lá (contanto que os clientes estejam trabalhando no OnPrem ..) :)
BR, y
Os serviços do Windows querem mais paciência até que isso seja feito. Tem um pouco difícil de depurar e instalar. Não tem rosto. Se você precisa de uma tarefa que deve ser realizada a cada segundo, minuto ou hora, deve escolher o serviço Windows.
A tarefa agendada é desenvolvida rapidamente e tem uma cara. Se precisar de uma tarefa diária ou semanal, você pode usar a Tarefa agendada.