SLAB, вне процесса: изменение подписи метода источника события приводит к неправильной регистрации событий

Question

Я реализовал класс источника событий для регистрации событий. После многократного изменения подписи (имен параметров и типов параметров) одного метода, который регистрирует события, события больше не регистрируются правильно. Например, когда событие регистрируется, вместо того, чтобы устанавливать полезную нагрузку с именем текущего параметра, события регистрируются с использованием параметров, использованных для предыдущей версии метода. Например:

Версия n метода:

    [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);
    }

Версия n+1 метода:

    [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);
    }

Когда этот метод вызывается для регистрации событий, они регистрируются, устанавливая значение Payload с именем параметра paramName вместо newParamName.

А теперь вопрос: как очистить "кеш", чтобы система забыла старую версию метода, а новый метод мог правильно регистрировать события?

Л.Э.: Я тестировал логирование с PerfView. Забавно, он правильно читает логи. Я снова проверил с SemanticLogging-svc.exe, журналы по-прежнему отображаются неправильно. Похоже, проблема не в регистрации событий, а в их чтении.

Answer 1

Я предполагаю, что источник событий не публикует изменения манифеста или SLAB не распознает изменения.

Обратите внимание, что просто изменив имя параметра, которое, по-видимому, нарушает правила управления версиями источника событий: "После добавления события с определенным набором свойств полезной нагрузки вы не можете переименовать событие, удалить какие-либо свойства или изменить значение существующих свойств.". Тем не менее, я вижу, что в процессе разработки до формализации интерфейса это может вызвать проблемы.

Вы также можете проверить папку кэша схемы манифеста, которая находится в папке Path.GetTempPath()\7D2611AE-6432-4639-8B91-3E46EB56CADF\. например, C:\Users\\AppData\Local\Temp\7D2611AE-6432-4639-8B91-3E46EB56CADF или, возможно, C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\7D2611AE-6432-4639-8B91-3E46EB56CADF.

Если вы видите свой манифест в кэше, вы можете удалить его, чтобы увидеть, поможет ли это с последними изменениями.

Answer 2

Мы столкнулись с той же проблемой. Мы "решили" это, переименовав EventSource для каждого нового развертывания, добавив номер версии в конце. Я уверен, что это то, что будет исправлено на каком-то этапе.