WCF System.Diagnostics логирование в реальном времени

Скачать проект.

Оглавление:

1. WCF service. С чего начать. Основные моменты создание службы. 
2. WCF. Callback через BasicHttpBinding без дуплексной связи.
3. Realtime WCF Tracker вызовов клиентского приложения.
4. Как отключить публикацию метаданных mex WCF сервисом. 

Введение

При разработке не раз была потребность понять, кто вызывает в конкретный момент мой сервис с клиента. Для этого (лично я) у сервиса в каждом методе добавлял Breakpoint и далее производил TestCase, выясняя из каких мест на клиенте производятся вызовы по Call Stack. Или представьте, когда происходит какая то проблема, не на вашем компьютере, влияющая на отзывчивость приложения и вам надо найти подозреваемого, а значит понять дело в сервере или клиенте путём анализа вызовов.
Для этого можно в приложении включить полную троссировку вызовов, воспользовавшись Trace Viewer (Using Service Trace Viewer for Viewing Correlated Traces and Troubleshooting) но он пишет все в лог файл, при этом требует каких то действий для настройки его на клиенте. Не спорю, его может быть достаточно, но там будет лог всех сообщений за время работы  клиента и в этой куче не сразу найдёшь что было вызвано в нужный интервал времени. Но хочется, что то на уровне - нажал - посмотрел вызовы, нашёл что надо - закрыл, отключил.

WCF Tracker в реальном времени.

Хочу представить альтернативный вариант, который, помимо возможности видеть все вызовы, имеет возможность ставить breakpoint.

Демонстрация работы:

Описание проектов и работы с ними.

Список проектов решения:

Как это работает?

Программисту требуется у ServiceEndpoint экземпляра proxy (для работы со службой), вызвать метод расширения AttachTracker(), внутри которого произойдёт "Подписка" на все вызовы работы с сервисом. Далее в ходе работы, если окно "WCF Tracker" открыто то происходит полный sniffing исходящих сообщений на сервер с возможностью остановки (путём закрытия окна) и просмотра текста самого SOAP сообщения. В демонстрации используется пример с логированием proxy, созданного через ClientFactory.
Так же существует возможность осуществить подписку в application.config файле. Пример использование на msdn <behaviorExtensions>, требуется только правильно указать путь до EndpointTrackerBehavior в сборке Wcf.Tracking. На момент публикации его namespace:

namespace Wcf.Tracker.Behaviors
{
    /// <summary>
    /// Endpoint tracker behavior.
    /// </summary>
    public class EndpointTrackerBehavior : IEndpointBehavior
    {
        ...
    }
}

 
Далее нам достаточно в нужный момент вызвать метод LogService.ShowWindow(); (в примере приведён показ по нажатию HotKey и кнопкой) и окно должно появиться.

Описание функционала

Описание "Главного окна" у Wcf.Tracker:

1. Если к приложению прицеплен какой то Debugger, то эта колонка отображается, и можно установить Breakpoint. Нет, это не установка внутри студии на соответствующей строке точку останова. Я использую Debugger.Break() функцию, которая заставляет при проходе через неё отладчик остановиться и программист без проблем, открыв окно "Call Stack" в Visual Studio, может подняться выше и посмотреть вызываемый метод.
   
2. Стрелка, указывающая направление пакета с сообщением. Если метод OneWay, то ответного сообщения не будет.
3. Время пересылки сообщения.
4. Метод вызываемого сервиса. На примере рисунка, у контракта IService вызывается метод Sum.
5. Продолжительность вызова. Выводится только для сообщений приходящих в ответ (имеющих в конце метода вызова пост-фикс *Responce) и при этом, я не вывожу вызовы, продолжительность которых меньше 1 секунды.
6. Размер сообщения в битах, килобайтах мегабайтах.
7. В данном столбце располагается кнопка, по которой можно отрыть и посмотреть исходный текст сообщения в отдельном окне. Позже о нем будет рассказано.
8. Содержит окно стека, при этом из него убраны все строки, у которых классы методов лежат в пространствах имён начинающихся с "System.", "MS.", "Microsoft.".
9. Кнопка экспорта всей таблицы в файл.
   
10. Очистка списка сообщений.

Что произойдёт если нажать по кнопке из пункта 7:
Появится окно, в котором можно визуально изучить отправленное сообщение как в виде дерева, так и в плоском виде.

В виде дерева:

В плоском виде:

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

Буду рад если кому то пригодится.