Drop the two import keys that wedge dotnet format

[henrikottesorensen]

The problem

A consuming repository reported that dotnet format would not fix its using order, while the build kept failing on UA1000. Reproduced and measured: as shipped, three consecutive dotnet format runs leave the file byte-identical and dotnet format --verify-no-changes exits 2 every time.

after dotnet format run #1 -> verify EXIT=2  | md5 5cf85de64fb803cfd6e94c406ab9a686
after dotnet format run #2 -> verify EXIT=2  | md5 5cf85de64fb803cfd6e94c406ab9a686
after dotnet format run #3 -> verify EXIT=2  | md5 5cf85de64fb803cfd6e94c406ab9a686

The file on disk is already correct. There is nothing the consumer can do to make CI green.

Cause

dotnet format style runs an organize-imports stage, reported as error IMPORTS: Fix imports ordering. It switches on if and only if dotnet_sort_system_directives_first or dotnet_separate_import_directive_groups is explicitly set — at any value, including false. Isolated each:

setting	dotnet format --verify-no-changes
dotnet_sort_system_directives_first = true	EXIT=2
dotnet_separate_import_directive_groups = true	EXIT=2
dotnet_separate_import_directive_groups = false	EXIT=2
both absent	EXIT=0

Once armed it sorts flat-alphabetically after System, putting Nota.* above the vendors — the inverse of UA1000's third block. The style stage reorders, the analyzers stage puts it back, the file never changes on disk, and --verify-no-changes reports what the style stage wanted.

The note in the globalconfig reasoned that the per-vendor grouping was "checked by IDE0055 only, which is off here, so nothing reports it". True, and beside the point — the imports stage is not a diagnostic, has no severity, and dotnet_diagnostic.IDE0055.severity = none does not reach it. It checked what reports, not what enforces. Rider is unaffected, which is why this only ever bit whoever formats from the command line.

The change

Both keys removed from content/Nota.CodeAnalysis.globalconfig, with a comment recording why they must stay absent rather than be set to false.

What it costs, measured

SA1516 does lose one check. With UA silenced, on usings with no blank line after the System group:

dotnet_separate_import_directive_groups = ABSENT -> SA1516 hits: 0
dotnet_separate_import_directive_groups = true   -> SA1516 hits: 2
dotnet_separate_import_directive_groups = false  -> SA1516 hits: 0

UA1001 already requires that blank line, and knows first party from vendor where SA1516 only ever saw first-level namespaces. What goes is the blunter duplicate of a check we still have.

Verification

Removing the key broke verify.sh, which asserted SA1516 for exactly that blank line — the suite doing its job:

Verification failed:
  - SA1516 did not report - it is configured but not reaching consumers

Samples/Unseparated.cs now carries both faults: using blocks in the right order with no blank line between them (UA1001), and two members with no blank line between them (SA1516, on its own turf). Its members carry no doc comments deliberately — a comment between them is reported by SA1514 instead, and SA1600 is off here.

All three scripts pass:

verify.sh:             All 7 rules reported.
verify-encoding.sh:    All source files are valid UTF-8 or BOM-marked UTF-16.
verify-package.sh:     All rules survive packaging.

End to end against the reporting consumer's own two .editorconfig files: one dotnet format pass produces the canonical layout and --verify-no-changes exits 0 repeatedly.

Note for consumers

An .editorconfig entry beats a global analyzer config entry, so a consumer can re-arm this from their own repository. Both READMEs now say not to set either key, not even to false.

Interim workaround

Until this ships, a consumer on the current package can skip the style stage — verified against the published config:

dotnet format whitespace && dotnet format analyzers

🤖 Generated with Claude Code

[ddfreiling]

😆