I am logging to ETW using EventSource. We are using .Net Framework 4.5.
Since I am in the infancy of development I will be changing the method signatures frequently within my subclass of EventSource. I really don't want to have to increment the Version every time I make a change. Version is only a byte so I will run out of versions really quickly.
Is there a way I can force ETW to recognize the signature changes without adding/changing the Version attribute?
It feels like it might have something to do with the generation of the manifest file but I can't really find a lot of information on how this is done in v4.5. Seems in the past the manifest file needed to be generated manually and now it is somehow magically generated.
Any help on this would be greatly appreciated.
EDIT:
When I change the signature the log still looks like the old signature. For example, if my method looks like this
public void MyLogMethod(string name, int id)
Later, if I want to add another parameter, such as
public void MyLogMethod(string name, int id, string message)
the message value does not show up in the payload unless I increment the Version attribute. I want ETW to recognize my changed signature without having to change the Version attribute.
ETW is a strongly type logging system, and EventSource is .NET layer built on top of it. Yes, nowadays EventSource is injecting into ETW stream its own manifest automatically. But you have to use the latest stable version distributed via Nuget feed. The version that is a part of .NET 4.5 has few bugs and lacks of some features.
The latest version of EventSource emits manifest information into underlying ETW provider during the start and each time new ETL file is going to be created. If you're using Tx LINQpad driver or SfvPerf, you could see that the first event(s) in recorded ETL file has event id equals to 64567 (as far as I remember) which is a EventSource system event, it also uses the same id to log its error messages, so you could check those for diagnostic purposes.
The only purpose of Version attribute is to support the scenario when you have multiple client using different versions to feed the same ETW provider, so the result trace events could be potentially deserialized based on version tag. In your case, it does not seem to be a problem to retain compatibility beetwen previous versions of ETW manifest for your event source.