2016-03-29 3 views
2

В настоящее время мы изучаем использование SonarQube/SonarLint для наших приложений .NET. Мы очень довольны тем, что мы видели до сих пор (и, кстати, пригодились для донесения SonarQube до сих пор - я использовал его пару лет назад для моего проекта PhD, и с тех пор он значительно улучшился!).SonarQube/SonarLint/Visual Studio: используйте один набор правил для всех проектов в решении

Однако, одна вещь была немного удивительной: когда я подключил свой экземпляр SonarLint к нашему серверу SonarQube (который работал очень хорошо) и начал синхронизировать связанный проект, SonarLint начал загружать пакеты nuget (что было отчасти ожидаемо) и затем создал один или даже два файла .ruleset для каждого проекта нашего решения (в дополнение к файлу SonarQube/<solution name>CSharp.ruleset, который, как я полагаю, является набором правил для решения).

Что я ожидал и предпочел бы только один набор правил, действительный для полного решения (и, возможно, возможность переопределить этот набор правил для проектов, где это имеет смысл (например, тестовые проекты)).

Возможно ли это вообще, т. Е. Я чего-то пропустил? Документация - единственная область, которую я идентифицировал до сих пор, где отсутствует SonarLint.

+0

Я немного удивлен, что не получил ответа на мой вопрос (команда SonarLint, по-видимому, контролирует тег SonarLint на SO), поскольку это, по-видимому, является довольно основным требованием, и я ожидаю, что многие команды будут иметь одинаковый вариант использования. Есть что-то глупое о моем вопросе? Если это так, укажите ссылку или что-то в этом роде ... Я смешиваю обязанности SonarLint и VS, или мой прецедент невозможен вообще? Опять же, пожалуйста, поделитесь своими знаниями ... Спасибо заранее. – csoltenborn

+1

Изменение набора правил на уровне решения будет применяться на уровне проекта, если набор правил на этом уровне не будет изменен. Если вы откроете файл с помощью XML-редактора, вы увидите разницу. –

ответ

1

Существует причина, по которой создаются эти дополнительные файлы правил. Ну на самом деле есть несколько:

  • Это позволит вам установить базовый уровень, к которому все проекты должны придерживаться, но включить дополнительные правила для проектов с конкретными типами кода. У вас может быть включено несколько правил MSOCAF, характерных для проектов Sharepoint, которые не имеют смысла для ваших проектов Unittest или Windows Service.

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

Один из файлов набора правил проекта будет перезаписан при каждой синхронизации с SonarQube. Другой останется, как вы его оставили. Позволяя вам сохранить настройки и по-прежнему позволяя вам безопасно синхронизировать изменения в базовой линии SonarQube.

Если я правильно помню это, набор правил решения входит в набор правил проекта, как и набор правил, в котором вы сохраняете свои настройки. В настоящее время у меня нет сервера SonarQube под рукой, чтобы проверить, какой именно файл-файл этого набора заданий, но это аргументы.

+0

Спасибо за ваш ответ! Однако мне все еще не ясно. Я определенно вижу необходимость использования разных наборов правил для разных проектов, но я думаю, что разделение наборов правил для каждого проекта - это кошмар обслуживания (и я признаю, что я не понял вашу точку зрения «Набор правил решения включен в «набор правил проекта» - в конце концов, у нас будет 1 решение и множество наборов правил проекта, так как первый может содержаться в последних?). Tbc ... – csoltenborn

+1

Что мы имеем в виду, это набор правил решения как основа для всех проектов, а также набор правил проекта (только), где это необходимо для настройки потребностей определенных проектов, например. добавлять или отключать правила «унаследованные» из набора правил решения. Это что-то вроде этого возможно, ведь это SonarQube? Можете ли вы указать на соответствующую документацию для этого случая использования? Опять же, спасибо за ваши идеи ... – csoltenborn

+1

Нет, набор в Sonar будет базовым, что действительно для всех проектов. Возможность иметь разные профили качества в одном проекте sonarqube была удалена с 4.something. Итак, что в Sonar будет базовым для всех проектов. Мне это больше не нравится, чем с точки зрения непрерывного улучшения. – jessehouwing

2

Я дал немного более подробную информацию о заинтересованности иметь несколько наборов правил в следующем блоге: SonarLint for VisualStudio 2.1 released, brings consistency with MSBuild, navigation to SonarQube and notifications

У вас есть один набор правил для каждого проекта, который настраивается в случае, если вы хотите, чтобы усилить определение качества для решение и один, соответствующий профилю качества SonarQube (соответствие с управлением в SonarQube)

+0

Это похоже на большой шаг в правильном направлении - спасибо, что дал мне знать через этот вопрос! – csoltenborn

Смежные вопросы