microsoft / microsoft/fhir-server
Investigate and remove suppressed build diagnostics
- Dominant language
- TSQL
- Stars
- 1.4k
- Forks
- 592
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 41
Description
**User story**
As a FHIR Server maintainer, I want the diagnostics suppressed during the .NET 10 and Healthcare Shared migration to be investigated and addressed so that real compatibility, correctness, performance, and dependency issues are not hidden from CI.
The following suppressions added or retained by the migration branch require review:
- `CA1873`
- `CA2024`
- `CA2025`
- `ASPDEPR005`
- `ASPDEPR006`
- `ASPDEPR008`
- `NU1510`
They currently appear in `CustomAnalysisRules.ruleset` and/or `Directory.Build.props`.
**Acceptance criteria**
1. When each diagnostic is enabled independently, then all resulting findings are inventoried and classified as actionable, false positive, generated-code issue, or intentional compatibility exception.
2. When a finding is actionable, then the underlying code or dependency declaration is corrected with appropriate tests rather than globally suppressed.
3. When a suppression must remain, then it is narrowed to the smallest practical scope and documented with a concrete rationale and follow-up condition.
4. When remediation is complete, then redundant entries are removed from both `CustomAnalysisRules.ruleset` and `Directory.Build.props`.
5. When the repository is built for `net8.0` and `net10.0` with warnings treated as errors, then both builds pass without globally ignoring these diagnostics.
Contributor guide
Research direction
Start with CustomAnalysisRules.ruleset and Directory.Build.props, enabling CA1873, CA2024, CA2025, ASPDEPR005, ASPDEPR006, ASPDEPR008, and NU1510 independently. Build the repository for net8.0 and net10.0 with warnings treated as errors, inventory each finding, then verify that actionable fixes have appropriate tests and any retained suppression is narrowly scoped and documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100