What should I identify with the id argument in TraceSource.TraceEvent method?

Question

I use the TraceSource class for logging in my .NET projects.

However a point that has never been clear to me is, what the intent of the id parameter in the TraceEvent method. Currently, I always set it to 0.

But what is the expected or typical useful usage of it?

I can think of a few possibilities:

• It is an ID for the occurrence of the event (i.e. the same line of code produces a different ID on each execution);
• It is an ID for the method call (i.e. you can infer the line of code from the ID);
• It is an ID for a family of similar events (e.g. all error messages that say that the database is absent share the same ID);
• It is an ID for a set of events that are related to a logical operation, in combination with the TraceEventType.(Start|Stop|Suspend|Resume|Transfer) enumeration values;

Nannette

Answer 1

I've asked myself the same question and I didn't found anything to clarify this in any Microsoft documentation. What I've manage to find is an article written by a Microsoft MVP, Richard Grimes: "The id parameter is whatever you choose it to be, there is no compulsion that a particular ID is associated with a particular format message." He uses 0, for the id argument, in all examples.

In MSDN articles, I've seen it used random, not providing any additional info. I believe that you can use in any way that helps you best when reading the logs, as long as you maintain the same code convention. It may prove useful afterwards in trace filtering, if you want to use the SourceFilter.ShouldTrace method, that accept an id argument too.

I use it to describe the error type, if I have an error, or use 0 for anything else.

Myrmecology

I believe (no proof), when you first TraceEvent() with an id and right after TraceData() with same id, listeners are able to link the data with event?! Example: You first TraceEvent() an exception and right after that TraceData() the stack trace. – Tetrastich

Answer 2

As far as I've seen in the documentation, it's not specifically intended for one purpose. I think it's there for you to tie in with your own logic for tracing events. The ShouldTrace() method on SourceFilter takes a matching id parameter, so you can also use it to determine which events or event types go where.

Personally, when I use TraceSource (which admittedly isn't much, having only discovered it recently) I use it to track event types or categories. In one application I already had an enum for event types that I was using with another logging method, with values Debug, Info, Warn, Error, Fatal, so I cast that to int and used that as the id, which helped with filtering later so I could filter out anything below the level I was interested in to de-clutter the trace.

Another possibility is that you could use different values to relate to different parts of the application, so Data Access = 1, User Accounts = 2, Product Logic = 3, Notifications = 4, UI = 5 etc. Again, you could then use this to filter the trace down to only the type of thing you're looking at.

Alternatively, you could (as you suggested) use different id values to mean different event types, so you could use them like error codes so that (for example) any time you saw an id of 26 you'd know that the database connection could not be established, or whatever.

It doesn't particularly matter what you use the id parameter for, as long as:

• It is useful to you in building and debugging the program
• It is clear and understandable to programmers reading through your code
• It is used consistently throughout the program

One possibility is that you could have a centralised class that manages the event ids and provides the values based on some sort of input to make sure that the whole application uses the same id for the same thing.

Armandoarmature