From 292b52ddcb51ddfe950f6c46e0c27c4896dbad0e Mon Sep 17 00:00:00 2001 From: Thorsten Sommer Date: Wed, 12 Aug 2026 20:43:06 +0200 Subject: [PATCH] Apply the provider access rule to Razor markup as well --- .../UsageAnalyzers/ProviderAccessAnalyzer.cs | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/app/SourceCodeRules/SourceCodeRules/UsageAnalyzers/ProviderAccessAnalyzer.cs b/app/SourceCodeRules/SourceCodeRules/UsageAnalyzers/ProviderAccessAnalyzer.cs index a0fc03d1..2c57bd33 100644 --- a/app/SourceCodeRules/SourceCodeRules/UsageAnalyzers/ProviderAccessAnalyzer.cs +++ b/app/SourceCodeRules/SourceCodeRules/UsageAnalyzers/ProviderAccessAnalyzer.cs @@ -34,7 +34,12 @@ public sealed class ProviderAccessAnalyzer : DiagnosticAnalyzer public override void Initialize(AnalysisContext context) { - context.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.None); + // + // We analyze generated code as well, because Razor markup ends up in generated files. Without + // this, any `ConfigurationData.Providers` access written directly in a `.razor` file would + // bypass this rule entirely. The Razor compiler maps the diagnostic back to the `.razor` line: + // + context.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.Analyze | GeneratedCodeAnalysisFlags.ReportDiagnostics); context.EnableConcurrentExecution(); context.RegisterSyntaxNodeAction(this.AnalyzeMemberAccess, SyntaxKind.SimpleMemberAccessExpression); }