Make ScopeAfterManualDispose actually dispose while a scope is active

[matt-edmondson]

Related to #88 — this is a finding produced by the local SonarCloud reproduction that issue asked for, and the first end-to-end confirmation that the setup surfaces real problems.

The defect

ScopeAfterManualDisposeOfCodeBlockerShouldThrowException was byte-identical in behaviour to ScopeWithDisposedCodeBlockerShouldThrowException — Sonar's S4144. Both disposed the CodeBlocker and then asserted that constructing a Scope throws.

That is not what the test's name says, and not what its own comment says:

// Act - Dispose the CodeBlocker while scope is still active
codeBlocker.Dispose();

No scope was ever active. The path the test claims to cover — a CodeBlocker disposed out from under a live scope — had no coverage at all.

It now opens a scope first, disposes the CodeBlocker, and asserts that closing the scope throws ObjectDisposedException, which is what happens when EndScope writes its brace to the disposed writer.

CA2000 is suppressed on that one line with a justification: disposing the scope is the act under test and it throws, so a using block would let the exception escape the assert instead of reaching it. Same pragma style as CodeBlocker.cs:180, and scoped to the single statement.

On #88 itself

The issue reads as outstanding, but its implementation landed on main in 233a1b7. Verifying it against the acceptance criteria:

• ✅ A documented local command runs the Sonar analyzers over every project. .sonarlint/sonar-local.props + .globalconfig exist and work; the invocation is documented in CLAUDE.md.
• ❌ Its output matches what SonarCloud reports for the same commit. Still unverified. sonarcloud.io is not reachable from the agent sandbox (CONNECT tunnel failed, response 403), so the one unidentified issue from Generalize CodeBlocker into a code-generation substrate #87 cannot be named, and the globalconfig cannot be calibrated against the real quality profile. Enabling every rule the analyzer ships would be a superset, not a match, so it would not satisfy this criterion either. This needs someone with dashboard access; I'd leave Add a local SonarCloud reproduction #88 open for it.
• ✅ Nothing imports the config automatically. Confirmed — plain builds are unaffected.

What the run reports on main today, now recorded in CLAUDE.md as a calibration baseline: S4144 on ScopeTests.cs (fixed here) and five S2699 warnings for test methods that assert nothing. The S2699 ones are left alone — several look like deliberate "does not throw" tests, and deciding that is a judgement call rather than a defect fix.

Testing

• dotnet test — 168 passed, 0 failed.
• dotnet build -p:CustomAfterMicrosoftCommonProps=$PWD/.sonarlint/sonar-local.props — build succeeded; S4144 gone, five pre-existing S2699 warnings remain.

One caveat: the sandbox has .NET SDK 10.0.111 (Roslyn 5.0) and ktsu.Sdk.Analyzers requires Roslyn 5.9, so both runs above had that one analyzer package dropped (CSC : error CS9057 otherwise). The Sonar and .NET analyzers themselves ran normally — CA2000 firing on the first draft of this change is the evidence.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N1cVfacJWw1uM42DUmPfUg

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud