SLAB, out-of-process: changing the signature of an

Question

I implemented an event source class for logging events. After repeatedly changing the signature (parameters names and parameters types) of one method that logs events, the events are no longer correctly logged. For instance when an event is logged, instead of setting the Payload with the current parameters name, the events are logged using the parameters used for the previous version of the method. Eg:

Version n of the method:

    [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 for logging events, they are logged setting the Payload value with the parameter name paramName instead of newParamName.

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

LE: I tested logging with PerfView. Funny thing, it reads the logs correctly. I tested again with SemanticLogging-svc.exe, the logs are still displayed incorrect. It looks like the problem is not on logging the events, but in reading them.

Answer 1

I would guess that event source is not publishing the manifest changes or SLAB is not recognizing the changes.

Note that by just changing the parameter name that looks to be violating the Event Source versioning rules: "Once you add an event with certain set of payload properties, you cannot rename the event, remove any properties, or change the meaning of the existing properties." However, I can see that in development before the interface is formalized this can still cause issues.

You can also check the manifest schema cache folder which is in the Path.GetTempPath()\7D2611AE-6432-4639-8B91-3E46EB56CADF\ folder. e.g. C:\Users\\AppData\Local\Temp\7D2611AE-6432-4639-8B91-3E46EB56CADF or perhaps 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 that helps with picking up the latest changes.

Answer 2

We ran into the same issue. We 'solved' it by re-naming the EventSource for every new deployment, by adding a version number to the end of it. I'm sure this is something that will be fixed at some stage.