S SimplicityTools Measure complexity before it measures your team.

Integration

IDE setup

The analyzer package is most useful when it behaves like a normal part of the editor. Install it once, keep the PackageReference clean, and let the diagnostics show up where developers already work.

Baseline PackageReference

Use the analyzer package as an analyzer-only dependency so it does not leak into downstream consumers.

<ItemGroup>
  <PackageReference Include="SimplicityTools.Analyzers" Version="x.y.z" PrivateAssets="all" />
</ItemGroup>

PrivateAssets="all" is part of the contract, not decoration. It keeps the analyzer package from becoming part of your public compile-time surface.

Visual Studio

Visual Studio is the richest experience for the current analyzer + code-fix surface.

  1. Add the analyzer package and rebuild the project.
  2. Enable full solution analysis if diagnostics do not appear immediately.
  3. Use the lightbulb for SF0001 and SF0002 when the fix matches the architectural intent.

Rider

Rider works well as long as inspections are running at the solution level.

  1. Add the package, restore, and rebuild once so Rider loads the analyzer assemblies.
  2. Confirm solution-wide inspections are enabled.
  3. If diagnostics look stale after an upgrade, clean bin/obj and restart Rider to flush analyzer caches.

VS Code / C# Dev Kit

The analyzer package still works, but the experience depends on the C# language service being healthy.

  1. Install the C# extension or C# Dev Kit and reload the workspace after restoring packages.
  2. Run a normal build once if diagnostics do not appear immediately in the editor.
  3. Use command-line build output as the tie-breaker when the editor seems out of sync.
Good reset command 
dotnet clean
dotnet build --no-incremental

Related pages

Use the diagnostic pages for rule details and the csproj guide for packaging specifics.

Analyzer overview csproj reference Filter reference