O tym, jak dodać analizatory do projektu, pisałam całkiem niedawno. Dzisiaj czas na opisanie, jak takie analizatory skonfigurować.

Do konfiguracji potrzebny jest plik o rozszerzeniu .ruleset. Warto stworzyć taki na potrzeby solucji i dodawać ścieżkę do niego w pliku .csproj:

<PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <CodeAnalysisRuleSet>..\Analysers.ruleset</CodeAnalysisRuleSet>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>

https://roslyn-analyzers.readthedocs.io/en/latest/config-analyzer.html

Podążając za dokumentacją Microsoftu, można dotrzeć do informacji, gdzie zostały ściągnięte na nasz komputer predefiniowane zestawy zasad dla danego pakietu. Np. dla pakietu FxCop będzie to ścieżka %USERPROFILE%\.nuget\packages\microsoft.codeanalysis.fxcopanalyzers\<version>\rulesets.

Jest tam całkiem sporo plików (u mnie było ich 28). Możemy zwrócić uwagę na pierwsze 3:

• AllRulesDefault.ruleset – domyślne ustawienia Microsoftu dla zasad
• AllRulesDisabled.ruleset – wyłączenie monitorowania każdej zasady
• AllRulesEnabled.rulest – włączenie monitorowania każdej zasady

Może warto więc użyć któregoś z tych plików konfiguracyjnych?

Z jednej strony – lepiej użyć jednego z takich plików, niż żaden. Z drugiej – fajnie byłoby mieć połączone zasady dla różnych analizatorów, np.:

Na to niestety nie znalazłam innego sposobu, niż ręczny. Można przypatrzeć się różnym projektom opensource i wzorować się na ich plikach konfiguracyjnych.

Plik .ruleset w Visual Studio

Po otwarciu pliku o rozszerzeniu .ruleset w Visual Studio 2019 otwiera się specjalny widok:

Po rozwinięciu widać różne zasady włączone lub wyłączone, z określeniem ich akcji (None, Warning lub Error), które można edytować:

Edycja konfiguracji robi się więc bardzo łatwa.

Plik .ruleset dla testów

Warto zwrócić uwagę na to, że czasami potrzebujemy mniej restrykcyjnych reguł dla projektów testowych. Zamiast wyłączać poszczególne zasady lub (co gorsza) całą statyczną analizę kodu w testach, warto przygotować sobie plik, którego targetem będą testy. Można go nazwać Analysers.Tests.ruleset (a podstawową wersję Analysers.ruleset) i używać wersji pierwszej w testach, a wersji drugiej w pozostałych projektach solucji.

Przykładowe pliki .ruleset

Podrzucam linki do plików, w których korzystamy w pracy w projektach opensource:

• Analysers.ruleset
• Analysers.Test.ruleset