Optimize analyzer performance with syntax-based filtering

[Copilot]

Addressed review feedback to improve analyzer performance and modernize test code.

Performance optimization

• Added syntax-based checks before semantic model lookups to avoid expensive symbol resolution for every invocation in the compilation
• Filter by method identifier name ("EnableFeature", "Defaults") and class declaration presence before querying semantic model
• Reduces unnecessary semantic analysis for non-matching invocations

Test modernization

• Converted test code blocks from verbatim strings (@"") to raw string literals (""") for better readability and consistency with C# 11+ conventions

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• f.feedz.io
  • Triggering command: dotnet build src/NServiceBus.Core.Analyzer/NServiceBus.Core.Analyzer.csproj (dns block)
  • Triggering command: dotnet build src/NServiceBus.Core.Analyzer/NServiceBus.Core.Analyzer.csproj --no-restore (dns block)
  • Triggering command: /opt/hostedtoolcache/CodeQL/2.23.3/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[danielmarbach]

@copilot I'm wondering if we could make it more performant by checking the inside defaults method first before we check the lambda part or is that not a good idea?

[Copilot]

@copilot I'm wondering if we could make it more performant by checking the inside defaults method first before we check the lambda part or is that not a good idea?

The current order is actually optimal. We can't check for Defaults before checking the lambda because:

1. We need to traverse up to find a lambda first (line 61)
2. Only then can we access defaultsInvocation through the lambda's parent structure (lines 63-72)
3. Then we can check if that invocation is named "Defaults" (lines 75-85)

The lambda check is a prerequisite for accessing the defaultsInvocation variable, so we can't reorder them. The current flow already filters efficiently:

• EnableFeature name check (cheapest, filters most invocations)
• Lambda existence check (cheap tree traversal)
• Defaults name check (also cheap, using the invocation we found via the lambda)
• Class declaration check
• Then semantic model lookups (most expensive)

[danielmarbach]

@copilot Are the additional name checks on the semantic model now redundant or best practice?

[Copilot]

@copilot Are the additional name checks on the semantic model now redundant or best practice?

Best practice. The syntax-based name checks are optimizations to bail early, while the semantic name checks verify we have the exact correct methods:

Syntax checks (lines 55, 82): Filter out obviously wrong invocations quickly

• Check identifier text only
• Could match any EnableFeature/Defaults method

Semantic checks (lines 103, 116): Authoritative verification

• Verify the method is from the correct type (SettingsExtensions.EnableFeature and Feature.Defaults)
• Essential to avoid false positives (e.g., user-defined EnableFeature methods)

This pattern (fast syntax filter → precise semantic verification) is the recommended approach for Roslyn analyzers.