Skip to content

Run the documentation tooling on .NET 8 and up, tested in CI#111

Merged
Reefact merged 3 commits into
mainfrom
claude/tooling-multi-target-runtime-p4fzmi
Jul 13, 2026
Merged

Run the documentation tooling on .NET 8 and up, tested in CI#111
Reefact merged 3 commits into
mainfrom
claude/tooling-multi-target-runtime-p4fzmi

Conversation

@Reefact

@Reefact Reefact commented Jul 13, 2026

Copy link
Copy Markdown
Owner

Summary

The fce documentation tooling — the CLI, GenDoc and the GenDoc.Worker — targeted net10.0, so a team whose newest runtime is .NET 8 could consume the netstandard2.0 library but could not run the documentation generator at all. This lowers the tooling floor to net8.0 and reaches every newer runtime by roll-forward, then guards both ends in CI. The tooling minimum now matches the analyzer floor (ADR 0001), so the product's support statement is a single ".NET 8 and up".

Type of change

  • Bug fix
  • New feature
  • Breaking change
  • Refactoring
  • Analyzer / diagnostic change
  • Tests
  • Documentation
  • Build / CI / tooling

Changes

  • Target net8.0 (was net10.0) for FirstClassErrors.Cli, FirstClassErrors.GenDoc and FirstClassErrors.GenDoc.Worker, keeping <LangVersion>latest</LangVersion> so the lower floor does not drop the C# level.
  • RollForward=Major on the CLI (the net8 build runs on any newer major — a .NET 10-only machine rolls 8→10) and RollForward=LatestMajor on the worker (it must out-rank the target it loads via Assembly.LoadFrom, so it binds the highest installed major).
  • Multi-target the Usage sample net8.0;net10.0 to give the CI floor job a real net8 target (and dogfood the netstandard2.0 library on the floor runtime).
  • ci.yml: add a floor job that runs the shipped net8 fce + worker on the .NET 8 runtime (pinned with DOTNET_ROLL_FORWARD=LatestPatch) and documents a net8 assembly end to end.
  • canary.yml: new weekly (and on-demand) non-blocking job that runs the net8 tooling on the next .NET preview (LatestMajor + DOTNET_ROLL_FORWARD_TO_PRERELEASE) as an early warning for roll-forward regressions on the next major.
  • Docs: update the runtime note in FirstClassErrors.Cli/README.nuget.md (.NET 8+), add maintainers/adr/0002-floor-the-tooling-runtime.md.

Testing

  • dotnet build FirstClassErrors.sln — Release, 0 warnings / 0 errors.
  • dotnet test FirstClassErrors.sln — Release, 609 passed, 0 failed, 0 skipped.
  • Analyzer tests pass (FirstClassErrors.Analyzers.UnitTests) — 51 passed.

Additional manual checks:

  • End to end: a net8.0 fce documented a net10 Usage assembly on a runtime that has only .NET 10 — fce rolls 8→10 (Major) and the worker binds the highest major (LatestMajor).
  • Verified DOTNET_ROLL_FORWARD=LatestPatch overrides the baked-in Major/LatestMajor and pins to major 8 (the net8 host fails when .NET 8 is absent), which is what the floor job relies on.

Not run locally (left to CI): the floor job's execution on a real .NET 8 runtime and canary.yml on a .NET preview — installing the .NET 8 runtime and preview SDKs is blocked by this environment's egress policy. Each underlying mechanism was verified separately as above.

Documentation

  • Public API / error documentation updated
  • README / doc/ updated
  • French translation (doc/README.fr.md) updated if user-facing behavior changed
  • No documentation change required

doc/README.fr.md documents only the analyzer compiler floor (unchanged); it makes no statement about the tooling runtime, so no French translation change was required. The fce NuGet README (English-only) carries the runtime note.

Related issues

None.


Generated by Claude Code

claude added 3 commits July 13, 2026 16:11
The fce tool, GenDoc and the GenDoc worker targeted net10.0, so a shop whose
newest runtime is .NET 8 could reference the netstandard2.0 library but could
not run the documentation generator at all.

Target net8.0 (the same floor as the analyzer, ADR 0001) and cover newer
runtimes with roll-forward instead of a target matrix: RollForward=Major on the
CLI, so the net8 build runs on any newer major (a machine that has only .NET 10
rolls 8->10), and RollForward=LatestMajor on the worker, so it binds the highest
installed major and can load a target built for a runtime newer than the floor.
Keep LangVersion=latest so the net8 floor does not drag the source back to C# 12.

See maintainers/adr/0002-floor-the-tooling-runtime.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015HeXL6s4yGMAgZitfWijs1
build-test covers the tooling only on the latest .NET (10). Add a floor job that
runs the shipped net8 fce and worker on the .NET 8 runtime and documents a net8
assembly end to end, proving the tooling works on its advertised minimum runtime.

DOTNET_ROLL_FORWARD=LatestPatch pins both processes to the highest .NET 8 patch
(env overrides the Major/LatestMajor baked into their runtimeconfigs), so they
cannot roll onto the .NET 10 the runner also carries. Multi-target the Usage
sample net8.0;net10.0 so the job has a real net8 target to document.

See maintainers/adr/0002-floor-the-tooling-runtime.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015HeXL6s4yGMAgZitfWijs1
The floor job pins the low end of the supported range; nothing watched the high
end — the worker reaches newer runtimes by LatestMajor roll-forward, so a runtime
breaking change in the next major would only surface in a user's CI after it ships.

Add canary.yml: on a weekly schedule (and on demand) it installs the next .NET
preview and runs the net8 tooling on it with DOTNET_ROLL_FORWARD=LatestMajor and
DOTNET_ROLL_FORWARD_TO_PRERELEASE=1, so both processes bind that prerelease major.
It is non-blocking by design: a missing or non-newer preview ends the run neutral,
while a genuine roll-forward regression turns the scheduled run red and notifies
the maintainer before that major ships.

See maintainers/adr/0002-floor-the-tooling-runtime.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015HeXL6s4yGMAgZitfWijs1
@Reefact Reefact force-pushed the claude/tooling-multi-target-runtime-p4fzmi branch from 556af8d to c3bd9c2 Compare July 13, 2026 16:13
@Reefact Reefact merged commit 782309e into main Jul 13, 2026
12 checks passed
@Reefact Reefact deleted the claude/tooling-multi-target-runtime-p4fzmi branch July 13, 2026 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants