Perché l'implementazione di un'interfaccia in una sottoclasse di EventSource genera un'eccezione in fase di runtime?

Question

Sto cercando di utilizzare Event Tracing for Windows (ETW) nella mia applicazione .NET tramite la classe EventSource inclusa in .NET 4.5. Sto sottoclasse EventSource come MyEventSource e cercando di implementare un'interfaccia IMyEventSource (a scopo di scherno) come segue:

public interface IMyEventSource 
{ 
    void Test(); 
} 

public class MyEventSource : EventSource, IMyEventSource 
{ 
    public static MyEventSource Log = new MyEventSource(); 

    [Event(1)] 
    public void Test() 
    { 
    this.WriteEvent(1); 
    } 
} 

Quando eseguo PerfView ed eseguire questo codice, ottengo una IndexOutOfRangeException sulla chiamata a WriteEvent. Se rimuovo l'interfaccia modificando il codice ...

public class MyEventSource : EventSource 
{ 
    public static MyEventSource Log = new MyEventSource(); 

    [Event(1)] 
    public void Test() 
    { 
    this.WriteEvent(1); 
    } 
} 

... quindi tutto funziona perfettamente.

Ecco il codice che ho usato per la prova in entrambi i casi:

static void Main(string[] args) 
{ 
    MyEventSource.Log.Test(); 
} 

Perché il mio sottoclasse di EventSource pausa, se si implementa una semplice interfaccia?

Questo è un related post.

Answer 1

Al momento di chiedere la domanda, la risposta da @LarsSkovslund era corretta. Tuttavia, con la versione stabile di Microsoft.Diagnostics.Tracing.EventSource (non il sistema .Diagnostics.Tracing.EventSource whih è buildin al .Net Framework dalla versione 4.5), Microsoft changed this according to their blog post:

Con il rilascio RTM che abbiamo ha allentato alcune delle regole di convalida della sorgente di eventi per abilitare determinati scenari di utilizzo avanzati.

Le due modifiche in questa zona

• tipi EventSource possono ora implementare le interfacce per consentire l'uso di tipi di origine evento a sistemi di registrazione avanzati che utilizzano interfacce per definire un target di registrazione comune.

• Il concetto di un tipo di utilità origine evento (definito come una classe derivante estratto EventSource) viene introdotto per sostenere la condivisione di codice su più tipi di origine evento in un progetto (ad esempio per ottimizzare WriteEvent() sovraccarichi).

Answer 2

Quando la classe EventSource sta costruendo la sua struttura di eventi in base alla riflessione, considererà solo i metodi diretti, ad es. i membri ereditati non sono considerati come nel tuo caso con l'uso di IMyEventSource.

Si sta ottenendo IndexOutOfRangeException perché WriteEvent utilizzerà il parametro ID evento per cercare un blocco descrittore con un indice che corrisponda all'ID evento generando così l'eccezione quando l'indice non esiste.

Quindi, in breve, DONT ha utilizzato le interfacce per definire gli eventi ETW utilizzando EventSource.

Acclamazioni Lars

Answer 3

Anche se non si può avere l'origine evento implementare un'interfaccia, è possibile avvolgere con un'altra classe che fa. (Questo è un esempio del Adapter design pattern)

public class EventSourceAdapter : IEventSource 
{ 
    private MyEventSource log; 

    public EventSourceAdapter(MyEventSource log) 
    { 
     this.log = log; 
    } 

    public void Test() 
    { 
     log.Test() 
    } 
} 
} 

Answer 4

A partire da oggi (29 settembre 2014), il codice il manifesto originale fornito non funziona con il codice nativo che viene fornito con .NET 4.5. Genera ancora un'eccezione "IndexOutOfRange" e, come dice, lo fa solo se gli eventi ETW vengono monitorati (sto usando PerfView).

Detto questo, ho verificato con .NET versione 4.0 utilizzando la libreria EventSource di Microsoft da nuget.org e il suo codice funziona con quello.

I successivo installato Microsoft EventSource Library da nuget in un progetto .NET versione 4.5. Mi sono assicurato di ereditare da Microsoft.Diagnostics.Tracing.EventSource e non da System.Diagnostics.Tracing.EventSource dalla libreria nativa .NET 4.5. Questo ha funzionato, ma ho anche scoperto che dovevo contrassegnare quei metodi ereditati dall'interfaccia con l'attributo [Microsoft.Diagnostics.Tracing.Event (int)].

Ho anche osservato alcuni comportamenti strani che non sono riuscito a spiegare. Talvolta alcuni dei miei eventi vengono visualizzati in PerfView con il nome "EventID (0)" anziché il nome del metodo. A volte ho ottenuto eccezioni IndexOutOfRange inaspettate. Come meglio posso dire che la registrazione di una precedente prova è rimasta in memoria. Ho iniziato a rinominare la mia classe EventSource tra le prove, e non avevo più questi problemi.

JR

Answer 5

C'è una soluzione per questo problema (mi dispiace non so come spiegare il problema). Se il metodo è decorato con lo NonEventAttribute, sarà possibile utilizzare la propria interfaccia.

L'interfaccia:

public interface IMyEventSource 
{ 
    void Test(); 
} 

e l'implementazione:

public class MyEventSource : EventSource, IMyEventSource 
{ 
    public static MyEventSource Log = new MyEventSource(); 

    [NonEvent] 
    public void Test() 
    { 
     this.InternalTest(); 
    } 

    [Event(1)] 
    private void InternalTest() 
    { 
     this.WriteEvent(1); 
    } 
}