Il .Net permette di scrivere un servizio di windows con veramente pochissime linee di codice, ma per scrivere un servizio veramente robusto sono necessari alcuni accorgimenti.
Prima di tutto faccio sempre una classe che ha solo due metodi: Start() e Stop(), in modo da poterla utilizzare con il servizio integrato di Spring.Net oppure da un proprio servizio. La cosa più importante è per me il logging, il servizio non è interattivo e non ha quindi un utente che lo utilizza e che rileva le eccezioni che vengono generate. In un normale programma windows infatti al generarsi di un eccezione non gestita il programma si chiude, ma l'utente può riaprirlo subito e soprattutto segnalare questa anomalia al team di sviluppo. Per un servizio questo non è possibile, una eccezione non gestita farà chrashare il servizio stesso che di fatto risulterà stoppato.
Come prima cosa imposto le proprietà del servizio facendo in modo che ai primi tre arresti inattesi il servizio venga comunque fatto ripartire, ma chiaramente è necessario avere un log tempestivo di cosa è andato storto. Utilizzando le API di logging dell'enterprise library è facile inserire un log per le eccezioni e far si che questo log venga segnato sia negli eventi di sistema del pc, sia spedito per mail al team di sviluppo che può cosi essere avvertito immediatamente del verificarsi dell'errore.
Il progetto del servizio è poi un normalissimo programma windows, per cui inserisco un controllo sui parametri di linea di comando e se presente il parametro /GUI, invece di far partire il servizio, faccio partire una form di diagnostica con cui posso chiamare il metodo start del servizio premendo un bottone ed inoltre posso aggiungere vari controlli con funzionalità diagniostica. Uno dei principali problemi è che se il servizio genera un'eccezione praticamente dopo pochi secondi dallo start, è difficile attaccarci un debugger, mentre lanciandolo con il parametro /GUI ho tutto il tempo di attaccare il debugger e poi premere un bottone, inoltre impostando /GUi come parametro dal visual studio posso sviluppare il servizio e lanciarlo come un normale programma windos.
Ah: naturalmente scrivere una gran quantità di unit test, che possano raggiungere il 100% di code coverage assicura che il codice sia ben testato e rende spesso superfluo dovere attaccare un debugger al servizio per capire cosa non va.
Alk.