Configuring Driver Design Analysis

Driver design analysis is controlled by MSBuild properties set in the driver project file or in a Directory.Build.props. The same settings govern both the live analysis in Visual Studio and the analysis performed at build time, so the Error List and the build always agree.

Turning analysis on or off

The master switch is the RunDriverDesignAnalyzers property. It defaults to true. Set it to false to skip driver design analysis at build time:

<PropertyGroup>
  <RunDriverDesignAnalyzers>false</RunDriverDesignAnalyzers>
</PropertyGroup>

Setting the severity of a diagnostic

Each diagnostic has a single severity knob: a property named NIM####Severity (for example, NIM0001Severity). The allowed values are:

Value	Effect
`None`	The diagnostic is disabled — neither reported at build nor shown in the IDE.
`Information`	Reported for awareness; never fails the build.
`Warning`	Reported as a warning; does not, on its own, fail the build.
`Error`	Reported as an error; fails the build.

<PropertyGroup>
  <NIM0002Severity>None</NIM0002Severity>   <!-- ignore missing help content -->
  <NIM0001Severity>Error</NIM0001Severity>  <!-- fail the build on broken help links -->
</PropertyGroup>

Default severities

When a NIM####Severity property is not set, the default depends on the build configuration:

Release configuration → Error (these checks fail a release build by default).
All other configurations (for example, Debug) → Warning.

NIM0004 is the exception: it defaults to Error in every configuration, because it reports generated output that Microsoft Help Viewer cannot index rather than authoring that may still be in progress.

This makes day-to-day Debug builds surface issues as warnings while a Release build holds the driver to a higher standard. Override any default by setting the property explicitly.

In the IDE versus at build

In Visual Studio, a live validator analyzes the driver during editing and lists diagnostics in the Error List at their configured severity.
At build time (command-line and CI builds), the analysis runs as part of the build and reports through the build log; a diagnostic configured as Error fails the build.

Because both paths read the same NIM####Severity settings, what appears in the Error List matches what the build enforces.

Enforcing standards in CI

To make a continuous-integration build fail when a check is violated, set that diagnostic to Error (or rely on the Release default). For example, to require that every documented item has a summary:

<PropertyGroup>
  <NIM0002Severity>Error</NIM0002Severity>
</PropertyGroup>