Scenario: sono stanco di farmi filtri sul registro degli eventi per avere i messaggi (d’errore, di warning, di info…… a seconda del trace level) che riguardano la mia applicazione, oggi faccio i capricci come i bambini, e voglio un EventSource tutto per me
Semplice da realizzare, e forse non è nemmeno da considerare un capriccio,perchè effettivamente scrivere nell’eventlog in un’area riservata solo a me mi da la possibilità di distinguere facilmente poi eventuali errori in maniera più efficiente e senza dover ricorrere a dei filtri, che poi dovrò esportare ed importare, quando passerò dall’ambiente di sviluppo a quello di test, e mi toccherà rifarlo quando passerò da test a produzione (no vi prego, io al massimo voglio fare click su “publish” per andare in produzione)
il codice che potete usare per testare il tutto è:
EventSourceCreationData source = new EventSourceCreationData("test";, "testLogFile");
if (!EventLog.Exists("testLogFile"))
EventLog.CreateEventSource(source);
EventInstance inst = new EventInstance(20, 1, EventLogEntryType.Error);
EventLog.WriteEvent("test", inst, "messaggio da loggare");
//e qui il codice per pulire se non vogliamo lasciare nessuna traccia del nostro log
if (EventLog.SourceExists("test"))
EventLog.DeleteEventSource("test");
if (EventLog.Exists("testLogFile"))
EventLog.Delete("testLogFile");
A questo punto (in verità l’avrei già detto almeno 20 righe fa) perché dovrei scegliere di loggare in questo modo e non usare log4net…e farlo in altri modi: su un file di log, o su un db…o tanti altri modi. Vi risponderò parafrasando un noto personaggio…”LA RISPOSTA E’…NON LO SO”. Volendo essere più professionali in realtà è questione di requisiti, nel senso che ci sono realtà in cui non è permesso l’uso di librerie sviluppate dall’esterno, o situazioni che richiedono una soluzione ad alta personalizzazione, insomma…ci sono svariati motivi per scegliere di loggare così.
E.