Статический анализ для ConfigureAwait

Question

Я пытаюсь реализовать статический анализ, чтобы проверить, действительно ли методу и его графику вызовов будет нужен контекст пользовательского интерфейса или запроса (ASP.NET). Ответ будет определять необходимость ConfigureAwait в выражении (ожиданиях) ожидания в теле метода.

Мой план состоит в том, чтобы использовать Roslyn для проверки символа доступа каждого члена в графе вызовов, являются ли они производными от класса System.Windows.UIElement. Работает ли этот подход? Что относительно контекста ASP.NET?

Answer 1

Любой статический анализ такого рода будет очень сложно реализовать правильно. Вы можете использовать эвристику (например, UIElement), но вы, вероятно, столкнетесь с некоторыми ложными срабатываниями и/или ложными негативами.

Например, FlowDocument не является результатом UIElement. Вы можете изменить свою эвристику для тестирования DispatcherObject -удаленных типов, но тогда это также будет включать Freezable, что может потребовать или не потребовать контекста - вы не всегда можете знать во время компиляции. Таким образом, это гарантированный ложноположительный (или отрицательный) в общем случае.

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

Аналогичные проблемы существуют в ASP.NET. HttpContext.Current очевидно, но как насчет методов форматирования строк, которые неявно используют текущую культуру? На стороне ASP.NET также есть несколько «gotchas».

Это, я думаю, это хорошая идея; просто убедитесь, что у вас есть простой способ игнорировать ложные срабатывания и ложные негативы.

Answer 2

Я думаю, что это просто, сравнивая количество вхождений строки «ожидание» и строку «ConfigureAwait» в том же файле.

Это может быть наивно, но первая линия обороны.