Лучшая практика, чтобы пометить метод, который вызывается с помощью отражения?

Наше программное обеспечение имеет несколько классов, которые должны быть динамически найдены с помощью отражения. Все классы имеют конструктор с определенной сигнатурой, посредством которой код отражения создает объекты.
Однако, когда кто-то проверяет, есть ли ссылка на метод (например, через Visual Studio Code Lens), ссылка через отражение не учитывается. Люди могут пропустить свои ссылки и удалить (или изменить) явно неиспользуемые методы.

Как мы должны пометить / документировать методы, предназначенные для вызова через отражение?

В идеале метод должен быть помечен таким образом, чтобы как коллеги, так и Visual Studio / Roslyn и другие автоматизированные инструменты «видели», что метод предназначен для вызова с помощью отражения.

Я знаю два варианта, которые мы можем использовать, но оба они не совсем удовлетворяют. Поскольку Visual Studio не может найти ссылки:

• Используйте пользовательский атрибут и пометьте конструктор этим атрибутом.
  • Проблема заключается в том, что свойства атрибута не могут быть ссылкой на метод, поэтому конструктор все равно будет отображаться как имеющий 0 ссылок.
  • Коллеги, не знакомые с пользовательским атрибутом, вероятно, проигнорируют его.
  • Преимущество моего текущего подхода состоит в том, что часть отражения может использовать атрибут, чтобы найти конструктор, который он должен вызвать.
• Используйте комментарии, чтобы задокументировать, что метод / конструктор предназначен для вызова через отражение.
  • Автоматизированные инструменты игнорируют комментарии (и коллеги могут делать то же самое).
  • Комментарии к XML-документации могут использоваться для подсчета в Visual Studio дополнительной ссылки на метод / конструктор:
    Позвольте MyPluginбыть классом, конструктор которого вызывается через отражение. Предположим, что вызывающий код отражения ищет конструкторы, которые принимают intпараметр. Следующая документация показывает, что кодовая линза показывает конструктор, имеющий 1 ссылку:
    /// <see cref="MyPlugin.MyPlugin(int)"/> is invoked via reflection

Какие лучшие варианты существуют?
Какова наилучшая практика для маркировки метода / конструктора, который должен вызываться с помощью отражения?

Комбинация предложенных решений:

• Используйте теги XML Documentation для документирования вызова конструктора / метода с помощью отражения.
  Это должно прояснить предполагаемое использование коллегам (и моему будущему я).
• Используйте трюк через <see>-tag, чтобы увеличить количество ссылок для конструктора / метода.
  Это делает этот код объективным, а поиск ссылок показывает, что на конструктор / метод ссылаются.
• Аннотировать с Решарпером UsedImplicitlyAttribute
  • Resharper является стандартом де-факто и [UsedImplicitly]имеет точно предполагаемую семантику.
  • Те, кто не использует Resharper, могут установить аннотации JetBrains ReSharper через NuGet:
    PM> Install-Package JetBrains.Annotations.
• Если это частный метод, и вы используете анализ кода Visual Studio, используйте SupressMessageAttributeдля сообщения CA1811: Avoid uncalled private code.

Например:

class MyPlugin
{
    /// <remarks>
    /// <see cref="MyPlugin.MyPlugin(int)"/> is called via reflection.
    /// </remarks>
    [JetBrains.Annotations.UsedImplicitly]
    public MyPlugin(int arg)
    {
        throw new NotImplementedException();
    }

    /// <remarks>
    /// <see cref="MyPlugin.MyPlugin(string)"/> is called via reflection.
    /// </remarks>
    [JetBrains.Annotations.UsedImplicitly]
    [System.Diagnostics.CodeAnalysis.SuppressMessage(
        "Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode",
        Justification = "Constructor is called via reflection")]
    private MyPlugin(string arg)
    {
        throw new NotImplementedException();
    }
}

Решение предоставляет предполагаемое использование конструктора как читателям-людям, так и трем системам статического анализа кода, наиболее часто используемым в C # и Visual Studio.
Недостатком является то, что и комментарий, и одна или две аннотации могут показаться немного излишними.

У меня никогда не было этой проблемы в проекте .Net, но у меня регулярно есть такая же проблема с проектами Java. Мой обычный подход заключается в использовании @SuppressWarnings("unused")аннотации с добавлением комментария, объясняющего почему (документирование причины отключения любых предупреждений является частью моего стандартного стиля кода - всякий раз, когда компилятор не может что-то выяснить, я предполагаю, что, вероятно, человек может бороться тоже). Преимущество этого заключается в том, что инструменты статического анализа автоматически получают информацию о том, что в коде не должно быть прямых ссылок, и дают подробное объяснение для читателей.

С # эквивалент Java @SuppressWarningsэто SuppressMessageAttribute. Для приватных методов вы можете использовать сообщение CA1811: избегайте невостребованного приватного кода ; например:

class MyPlugin
{
    [System.Diagnostics.CodeAnalysis.SuppressMessage(
        "Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode",
        Justification = "Constructor is called via reflection")]
    private MyPlugin(int arg)
    {
        throw new NotImplementedException();
    }
}

Альтернативой документированию было бы проведение модульных тестов, обеспечивающих успешное выполнение вызовов отражения.

Таким образом, если кто-то изменяет или удаляет методы, ваш процесс сборки / тестирования должен предупредить вас, что вы что-то сломали.

Ну, не видя ваш код, вроде бы это было бы хорошим местом для введения некоторого наследования. Может быть, виртуальный или абстрактный метод, который может вызвать конструктор этих классов? Если вы метод, который вы пытаетесь пометить, это просто конструктор, то вы действительно пытаетесь пометить класс, а не метод, да? Что-то, что я сделал в прошлом, чтобы пометить классы, - создать пустой интерфейс. Затем инструменты проверки кода и рефакторинга могут искать классы, которые реализуют интерфейс.