Integration

csproj reference

Use a boring, explicit PackageReference shape. Analyzer packages should stay analyzer-only, and primary-path annotations should come from the metrics package only when you need that extra clarity.

Analyzer package contract

The analyzer package should never leak into downstream consumers. Keep the reference private and explicit.

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

PrivateAssets="all" keeps the analyzer package out of your published compile-time surface.
The analyzer package contributes diagnostics and code fixes only. It is not a runtime or API dependency.
Keep analyzer versioning independent from the Metrics / Filters / Tca package line when that serves your rollout cadence.

When to add SimplicityTools.Metrics

Add the metrics package only when your code wants the runtime/library surface or explicit primary-path annotations.

<ItemGroup>
  <PackageReference Include="SimplicityTools.Metrics" Version="x.y.z" />
</ItemGroup>

Explicit primary path

using SimplicityTools.Metrics;

[PrimaryPath]
public sealed class CheckoutHandler
{
    public Task HandleAsync(Request request) => Task.CompletedTask;
}

Best practices

These keep the package boundaries honest instead of hiding architectural drift behind clever MSBuild tricks.

Keep analyzer references in the app or solution layer that actually benefits from the diagnostics.
Use Directory.Build.props only if the whole solution wants the analyzer contract, not because editing many project files is annoying.
Do not add the metrics package everywhere just to get [PrimaryPath]; add it where explicit annotation provides real value.