Type to search pages and rules.

Browse pages

.NET Configuration

Configuration in a .NET backend pins the SDK, build settings, packages, and tools through MSBuild files.

Markdown5 rules

Intent#

Configuration in a .NET backend pins the SDK, build settings, packages, and tools through MSBuild files. The shared provisions live on the stack-neutral page (Configuration); this page holds what .NET alone requires.

Standards#

Set the SDK floor at the workspace root#

ruleguidance

Requirement The root global.json MUST set the first feature band of the manifest .NET major release as its SDK version and roll forward with latestMajor.

Rationale Any SDK from that major release builds the workspace, so a patch or feature band release needs no change to the workspace. The manifest names the major release, and Directory.Build.props sets its target framework.

litespec/backend/dotnet/config#set-the-sdk-floor-at-the-workspace-root

Centralize .NET build settings#

ruleguidance

Requirement apps/api/Directory.Build.props MUST set the target framework of the manifest .NET stack release, and enable nullable types, implicit usings, and warnings as errors.

Rationale One file then owns the settings that would otherwise drift between projects.

litespec/backend/dotnet/config#centralize-net-build-settings

Centralize NuGet versions#

ruleguidance

Requirement apps/api/Directory.Packages.props MUST enable central package management and carry the exact manifest pins.

Rationale Individual project files then reference package names without versions, so no project can drift.

litespec/backend/dotnet/config#centralize-nuget-versions

Commit the tool manifest#

ruleguidance

Requirement The root .config/dotnet-tools.json MUST pin every local .NET tool that a documented command invokes.

Rationale When a tool ships in the manifest .NET stack release, its pin matches that release, so local and CI runs use one version.

litespec/backend/dotnet/config#commit-the-tool-manifest

Validate backend options at startup#

ruleguidance

Requirement A configuration section MUST bind to a named options class validated for required fields, ranges, and formats at startup.

Rationale Reading a required setting through a raw configuration lookup defers the failure to the first request that needs it. This binding realizes litespec/workspace/config#validate-backend-configuration-at-startup.

litespec/backend/dotnet/config#validate-backend-options-at-startup

Conventions#

None.

Verification#

IDMarkEvidence
litespec/backend/dotnet/config#set-the-sdk-floor-at-the-workspace-rootguidanceDoes the root global.json set the manifest major release's first feature band, such as 10.0.100, with latestMajor roll-forward?
litespec/backend/dotnet/config#centralize-net-build-settingsguidanceDoes Directory.Build.props set the manifest target framework, nullable types, implicit usings, and warnings as errors?
litespec/backend/dotnet/config#centralize-nuget-versionsguidanceDoes Directory.Packages.props enable central management with the manifest pins, and do projects omit versions?
litespec/backend/dotnet/config#commit-the-tool-manifestguidanceDoes .config/dotnet-tools.json pin each local tool a documented command invokes?
litespec/backend/dotnet/config#validate-backend-options-at-startupguidanceDoes each configuration section bind a validated options class that fails startup on bad values?