ReSharper InspectCode.exe не учитывает настраиваемые слои - PullRequest
0 голосов
/ 28 мая 2020

У меня довольно много C# проектов, которые можно условно разделить на самодостаточные системы и пакеты NuGet. Я хотел бы использовать ReSharper для проверки качества кода обоих типов. Большинство правил одинаковы, но некоторые, в основном в отношении видимости, отличаются. Мой подход заключался в создании настроек в централизованном репозитории. Конфигурация RootSettings имеет все настройки, которые я хотел бы иметь везде, а конфигурация Settings_NuGet перезаписывает желаемые настройки.

Решение NuGet, следовательно, будет выглядеть следующим образом:

enter image description here

Это отлично работает, но я также хотел бы использовать Azure DevOps CI для проверки качества кода. Для этого я использую задачу из Alan Wales https://marketplace.visualstudio.com/items?itemName=alanwales.resharper-code-analysis, в которой используется InspectCode.Exe

К сожалению, это, похоже, вообще не работает: насколько я могу Я не использую настройки ReSharper из-за разных путей, мой подход был бы таким вызовом (с разными путями этот вызов только локально для тестирования =:

inspectcode.x86.exe "C:\MyGit\Personal\MLH\MLH.LanguageExtensions\MLH.LanguageExtensions.sln" -o="tra.txt" --profile="C:\MyGit\Personal\MLH\MLH.LanguageExtensions\MLH.LanguageExtensions.sln.DotSettings"

Как MLH.LanguageExtensions.sln. DotSettings - это просто прокси для RootSettings, похоже, что InspectCode игнорирует это. Я проверил это, вместо того, чтобы нацеливаться на RootSettings, скопировав все настройки непосредственно в MLH.LanguageExtensions.sln.DotSettings. Этот подход будет работать , но это противоречит моей идее иметь только один источник истины и все остальные настройки, нацеленные на него или расширяющие его.

Действительно ли это ошибка ReSharper? Я не нашел ничего или специального упоминания в документации.

Изменить: еще немного пояснений по поводу варианта использования: я вижу два рабочих процесса:

  • Разработчик разрабатывает локально, используя все t Он доброта ReSharper. В этом случае соглашение о настройках по умолчанию MLH.LanguageExtensions.sln "с абсолютным путем к настройкам root работает хорошо, поскольку мы можем определить структуру папок для машин разработчиков.
  • Во втором рабочем процессе Azure Конвейер сборки DevOps должен проверять код. В этом случае я не могу использовать абсолютный или относительный путь "MLH.LanguageExtensions.sln", поскольку каталоги совершенно разные. Поэтому я хотел бы передать замена на "MLH.LanguageExtensions.sln" через параметр, который, похоже, не работает

Почему я вообще все это возился? У нас есть много разных репозиториев, например для Пакеты NuGet. Поэтому было бы здорово иметь ровно один источник правды о настройках ReSharper и местных разработчиков, а также CI, нацеленную на один и тот же файл, без необходимости его копировать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...