This project has moved and is read-only. For the latest updates, please go here.

ActivityScope Activity Name

Jan 2, 2016 at 5:58 PM
Edited Jan 2, 2016 at 6:07 PM
Currently the ActivityScope sets the ActivityName from a Resouce file. ‘Start’ is a bit redundant as it is indicated in the Level.


I’d like to add the following overload so that the Activity name can be set in the constructor of the scope.


With the following result:


Does this makes sense to you? I realize that the ActivityID can be used to relate events, but Activity Name should have a useful value too. This is particularly useful in Trace Viewer.

Let me know what you think!
Feb 15, 2016 at 12:45 AM
Edited Feb 15, 2016 at 12:50 AM
The resource, being passed into the TraceEvent() call, is actually the message (e.g. compare with the resource for the stop message).

... however, from doing some research, it looks like the XML tracewriter also defaults to using the message as the Activity Name.

There is a way to have both specified separately, by using TraceData():

According to the question, WCF has separate values for the message and Activity Name, so I would also look at the code inside WCF (use ILSpy or similar) to confirm how it handles the situation.

A possible negative of TraceData() is that it assumes you are logging to XML, so if you were logging to a text file instead it may look like a very weird start message (compared to plain text).

Keeping the simple messages is probably best for compatibility, but I like the idea of an overload.

To be semantically correct, however, you should use the following (keep only a single overload, to be simple):

public ActivityScope(ITraceSource source, int transferInId, int startId, int transferOutId, int stopId,
string transferInMessage, string startMessage, string transferOutMessage, string stopMessage) { }

I would simply add a separate overload (rather than use defaulting parameters) -- this is for backwards compatibility (otherwise callers would need to recompile for the new signature).

Passing in null should use the default (resource) message, however an empty string should be honoured (logged as an empty message); coalesce is probably the simplest operator.

_source.TranceTransfer(_transferInId, _transferInMessage ?? Resouce.ActivityScope_Transfer, newActivity);

Most importantly: Add doc comments explaining what the messages are, and that null uses the default message. In particular highlight that startMessage is also used as the default Activity Name. (Semantically, you are actually providing the trace message; it just happens to use the message as the activity name.)

If you code it up on a separate feature branch (in a fork) and submit a pull request.
Marked as answer by xsolon on 2/20/2016 at 7:00 PM
Feb 15, 2016 at 12:49 AM
Okay, so after adding an overload for transferInMessage, startMessage, etc... then you could look at a second overload that adds a further activityName parameter (so 10 params, which is pretty long).

If this is passed, then use the XML example to construct a data item with both _startMessage and _activityName.

Again, the most important thing is comments -- clearly explain that this version (where activityName is specified) logs XML data instead of a simple text message, and you may get unusual results unless you are using an XML-based tracewriter.
Feb 15, 2016 at 12:56 AM
One other comment on the transfer/start/etc messages -- you do want them to be already converted to strings (not format + args), because the arg values may not make sense at the time of logging (e.g. disposal).

If I ever did take args for something like this, I would call the string.Format() during init to convert into a string at that point (then save the string for logging later).

So, yeah, a single string message parameter is all I would use. (The caller needs to format if they want to include args).
Feb 21, 2016 at 2:40 AM
Edited Feb 21, 2016 at 2:41 AM
Thank you for the guidance.

I have implemented the overloads and a couple of test methods.

All seems well!

Pull request on the way