Risposte:
Aggiornare:
Quasi quattro anni dopo la mia risposta originale e questa risposta è molto obsoleta. Da quando è arrivato TopShelf, lo sviluppo dei servizi Windows è diventato facile. Ora devi solo capire come supportare il failover ...
Risposta originale:
Non sono davvero un fan di Windows Scheduler. La password dell'utente deve essere fornita come indicato sopra @moodforall , il che è divertente quando qualcuno cambia la password di quell'utente.
L'altro grande fastidio con l'Utilità di pianificazione di Windows è che viene eseguito in modo interattivo e non come processo in background. Quando 15 finestre MS-DOS si aprono ogni 20 minuti durante una sessione RDP, ti prenderai a calci se non le hai installate come servizi Windows.
Qualunque cosa tu scelga, ti consiglio di separare il tuo codice di elaborazione in un componente diverso dall'app della console o dal servizio di Windows. Quindi hai la possibilità di chiamare il processo di lavoro da un'applicazione console e collegarlo all'Utilità di pianificazione di Windows o utilizzare un servizio di Windows.
Scoprirai che la pianificazione di un servizio Windows non è divertente. Uno scenario abbastanza comune è che si dispone di un processo a lunga esecuzione che si desidera eseguire periodicamente. Tuttavia, se stai elaborando una coda, non vuoi davvero che due istanze dello stesso worker elaborino la stessa coda. Quindi è necessario gestire il timer, per assicurarsi che se il processo a lunga esecuzione è stato eseguito più a lungo dell'intervallo del timer assegnato, non si riavvia fino al termine del processo esistente.
Dopo aver scritto tutto questo, pensi, perché non ho usato semplicemente Thread.Sleep? Ciò mi consente di lasciare che il thread corrente continui a funzionare fino al termine, quindi l'intervallo di pausa entra in azione, il thread va in sospensione e riprende dopo il tempo richiesto. ! Neat
Poi leggi tutti i consigli su Internet con molti esperti che ti dicono come è davvero una cattiva pratica di programmazione:
Quindi ti gratterai la testa e penserai a te stesso, WTF, Annulla pagamenti in sospeso -> Sì, sono sicuro -> Annulla tutto il lavoro di oggi ..... accidenti, accidenti, accidenti ...
Tuttavia, mi piace questo schema, anche se tutti pensano che sia una schifezza:
Metodo OnStart per l'approccio a thread singolo.
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(); }Il codice crea un'istanza di un thread separato e vi allega la nostra funzione di lavoro. Quindi avvia il thread e lascia completare l'evento OnStart, in modo che Windows non pensi che il servizio sia bloccato.
Metodo di lavoro per l'approccio a thread singolo.
/// <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(); }Metodo OnStop per l'approccio a thread singolo.
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)
Eseguo molti servizi Windows come questo da anni e funziona per me. Non ho ancora visto uno schema consigliato su cui le persone siano d'accordo. Fai solo ciò che funziona per te.
NT AUTHORITY\NetworkServiceè un account con privilegi limitati.
Qualche disinformazione qui. L'utilità di pianificazione di Windows è perfettamente in grado di eseguire attività in background senza che le finestre si aprano e senza che sia richiesta la password. Eseguilo con l'account NT AUTHORITY \ SYSTEM. Usa questo interruttore schtasks:
/ ru SYSTEM
Ma sì, per accedere alle risorse di rete, la best practice è un account di servizio con un criterio di password separato senza scadenza.
MODIFICARE
A seconda del sistema operativo e dei requisiti dell'attività stessa, potresti essere in grado di utilizzare account con meno privilegi di Localsystem con l' /ruopzione.
Dal bel manuale ,
/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.
Task Scheduler 2.0 è disponibile da Vista e Server 2008.
In XP e Server 2003, systemè l'unica opzione.
Local Service(aka NT AUTHORITY\LocalService) piuttosto che LocalSystem(aka .\LocalSystem). Il primo ha diritti limitati, mentre il secondo è amministratore
LocalServicee NetworkServicesono disponibili in schtasksv2 Vista in poi e dovrebbe essere preferito, ove possibile. Al momento, questo si riferiva a schtasksin XP e Server 2003 che accettano solo Systemcome parametro per la vecchia versione manuale technet.microsoft.com/en-us/library/bb490996.aspx
Qual è il sovraccarico di avvio e chiusura dell'app? Ogni due minuti è abbastanza spesso. Un servizio probabilmente consentirebbe al sistema di funzionare in modo più fluido rispetto all'esecuzione dell'applicazione così frequentemente.
Entrambe le soluzioni possono eseguire il programma quando l'utente non è connesso, quindi nessuna differenza. Scrivere un servizio è un po 'più complicato rispetto a una normale app desktop, tuttavia: potresti aver bisogno di un client GUI separato che comunicherà con l'app del servizio tramite TCP / IP, named pipe, ecc.
Dal punto di vista di un utente, mi chiedo quale sia più facile da controllare. Sia i servizi che le attività pianificate sono praticamente fuori dalla portata della maggior parte degli utenti non tecnici, ovvero non si rendono nemmeno conto della loro esistenza e possono essere configurati / interrotti / riprogrammati e così via.
Nello sviluppo .NET, normalmente inizio sviluppando un'applicazione console, che verrà eseguita registrando tutti gli output nella finestra della console. Tuttavia, questa è solo un'applicazione console quando viene eseguita con l'argomento comando /console. Quando viene eseguito senza questo parametro, funge da servizio Windows, che rimarrà in esecuzione sul mio timer programmato codificato personalizzato.
I servizi Windows, credo, vengono normalmente utilizzati per gestire altre applicazioni, piuttosto che essere un'applicazione a lunga esecuzione. OPPURE .. sono applicazioni pesanti in esecuzione continua come SQL Server, BizTalk, connessioni RPC, IIS (anche se IIS tecnicamente offload il lavoro su altri processi).
Personalmente, preferisco le attività pianificate rispetto a Windows Services per attività di manutenzione ripetitive e applicazioni come la copia / sincronizzazione di file, l'invio di e-mail di massa, l'eliminazione o l'archiviazione di file, la correzione dei dati (quando non sono disponibili altre soluzioni alternative).
Per un progetto sono stato coinvolto nello sviluppo di 8 o 9 servizi Windows, ma questi rimangono in memoria, inattivi, consumando 20 MB o più di memoria per istanza. Le attività pianificate faranno il loro dovere e rilasceranno immediatamente la memoria.
La parola 'serv'ice ha qualcosa in comune con' serv'er. Ci si aspetta che sia sempre in funzione e 'serv'e. Un compito è un compito.
Gioco di ruolo. Se sono un altro sistema operativo, applicazione o dispositivo e chiamo un servizio, mi aspetto che sia in esecuzione e mi aspetto una risposta. Se (os, app, dev) ho solo bisogno di eseguire un'attività isolata, allora eseguirò un'attività, ma se mi aspetto di comunicare, possibilmente comunicazione a due vie, voglio un servizio. Questo ha a che fare con il modo più efficace per comunicare due cose, o una singola cosa che vuole eseguire una singola attività.
Poi c'è l'aspetto della pianificazione. Se vuoi che qualcosa venga eseguito in un momento specifico, pianifica. Se non sai quando ne avrai bisogno, o quando ne avrai bisogno "al volo", assistenza.
La mia risposta è di natura più filosofica perché è molto simile a come gli umani interagiscono e lavorano con un altro. Più comprendiamo l'arte della comunicazione e le "entità" comprendono il loro ruolo, più facile diventa questa decisione.
Filosofia a parte, quando "prototipi rapidamente", come fa spesso il mio reparto IT, fai tutto il possibile per sbarcare il lunario. Una volta che la prototipazione e la prova del concetto sono fuori mano, di solito nella pianificazione e nella scoperta iniziali, devi decidere cosa è più affidabile per la sostenibilità a lungo termine.
OK, quindi, in conclusione, dipende fortemente da molti fattori, ma si spera che questo abbia fornito informazioni anziché confusione.
Un servizio Windows non richiede l'accesso a nessuno e Windows dispone di funzionalità per arrestare, avviare e registrare i risultati del servizio.
Un'attività pianificata non richiede di imparare a scrivere un servizio Windows.
NT AUTHORITY\LocalServiceo NT AUTHORITY\NetworkService). Qualsiasi password fornita viene ignorata perché gli account non hanno password.
Perché non fornire entrambi?
In passato ho inserito i bit "principali" in una libreria e ho inserito una chiamata a Wwhat.GoGoGo () sia in un servizio che in un'app console.
Con qualcosa che spari ogni due minuti le probabilità sono buone che non stia facendo molto (ad esempio solo una funzione di tipo "ping"). I wrapper non dovrebbero contenere molto di più di una singola chiamata al metodo e alcuni log.
Questa è una vecchia domanda, ma mi piacerebbe condividere ciò che ho affrontato.
Recentemente mi è stato richiesto di catturare lo screenshot di un radar (da un sito web meteorologico) e salvarlo nel server ogni 10 minuti.
Ciò mi ha richiesto di utilizzare WebBrowser. Di solito creo servizi Windows, quindi ho deciso di creare anche questo servizio, ma avrebbe continuato a bloccarsi. Questo è ciò che ho visto nel percorso del modulo di errore del Visualizzatore eventi : C: \ Windows \ system32 \ MSHTML.dll
Poiché l'attività era urgente e avevo molto meno tempo per cercare e sperimentare, ho deciso di utilizzare una semplice applicazione console e l'ho attivata come attività ed è stata eseguita senza problemi.
Mi è piaciuto molto l' articolo di Jon Galloway consigliato come risposta accettata da Mark Ransom.
Recentemente le password sui server sono state modificate senza riconoscermi e tutti i servizi non sono stati eseguiti poiché non potevano accedere. Quindi ppl affermando nell'articolo commenta che questo è un problema. Penso che i servizi di Windows possano affrontare lo stesso problema (per favore correggimi se sbaglio, sono solo un principiante)
Anche la cosa menzionata, se si utilizza l'utilità di pianificazione, le finestre si aprono o si apre la finestra della console. Non l'ho mai affrontato. Potrebbe apparire ma è almeno molto istantaneo.
In generale, il messaggio principale è e dovrebbe essere che il codice stesso deve essere eseguibile da ogni "trigger / client". Quindi non dovrebbe essere scienza missilistica passare da un approccio all'altro.
In passato abbiamo utilizzato più o meno sempre i Servizi Windows ma dal momento che anche sempre più clienti passano ad Azure passo dopo passo e lo scambio da App Console (distribuita come Attività Pianificata) ad un Lavoro Web in Azure è molto più semplice che da un servizio Windows, per ora ci concentriamo sulle attività pianificate. Se ci imbattiamo in limitazioni, aumentiamo semplicemente il progetto del servizio Windows e chiamiamo la stessa logica da lì (a condizione che i clienti lavorino su OnPrem ..) :)
BR, y
I servizi Windows richiedono più pazienza finché non vengono completati. Ha un po 'difficile eseguire il debug e l'installazione. È senza volto. Se hai bisogno di un'attività che deve essere eseguita in ogni secondo, minuto o ora, dovresti scegliere Servizio Windows.
L'attività pianificata viene sviluppata rapidamente e ha una faccia. Se hai bisogno di un'attività giornaliera o settimanale, puoi utilizzare Attività pianificata.