SLAB, Out of Process: Changing the signature of the event source method causes an incorrect event logging

I implemented an event source class to register events. After repeatedly changing the signature (parameter names and parameter types) of one method that registers events, events are no longer logged correctly. For example, when an event is logged, instead of setting a payload with the name of the current parameter, events are logged using the parameters used for the previous version of the method. For example:

Method n version:

[Event(5, Message = "Action: {0}", Task = Tasks.PAGE, Keywords = Keywords.USER_ACTION, Level = EventLevel.Informational)] public void LogAction(string action, string paramName) { this.WriteEvent(5, action, paramName); } 

Version n + 1 of the method:

  [Event(5, Message = "Action: {0}", Task = Tasks.PAGE, Keywords = Keywords.USER_ACTION, Level = EventLevel.Informational)] public void LogAction(string action, string newParamName) { this.WriteEvent(5, action, newParamName); } 

When this method is called to register events, they are logged by setting the payload with the paramName parameter name instead of newParamName.

And now the question arises: how can I clear the "cache", so the system forgets the old version of the method and the new method can correctly register events?

LE: I checked the logging with PerfView. Funny, he reads magazines correctly. I tested again with SemanticLogging-svc.exe, the logs still display incorrectly. It seems that the problem is not in recording events, but in reading them.

+1
methods signature out-of-process slab
source share
2 answers

I would suggest that the event source does not publish the manifest changes or SLAB does not recognize the changes.

Please note that simply by changing the name of the parameter that appears to violate Source Source version control rules: "After adding an event with a specific set of payload properties, you cannot rename the event, delete any properties, or change the value of existing properties." However, I see that during the development process before the interface is formalized, this can still cause problems.

You can also check the manifest schema cache folder, which is located in the Path.GetTempPath () \ 7D2611AE-6432-4639-8B91-3E46EB56CADF \ folder. e.g. C: \ Users \\ AppData \ Local \ Temp \ 7D2611AE-6432-4639-8B91-3E46EB56CADF or possibly C: \ Windows \ ServiceProfiles \ LocalService \ AppData \ Local \ Temp \ 7D2611AE-6432-4639-8B91-3E46EB56CADF .

If you see your manifest in the cache, you can delete it to see if this helps in getting the latest changes.

+5
source share

We faced the same problem. We decided to β€œrename the EventSource for each new deployment, adding the version number at the end. I am sure that this will be fixed at a certain stage.

0
source share

All Articles