MTA-7228 C# Roslyn provider for analysis

[Pkylas007]

JIRA

• MTA-7228

Version

• 8.2.0

Preview

• 3.1. Provider capabilities in custom rules - removed the generic binary point
• 3.7. C# provider

Summary by CodeRabbit

Summary by CodeRabbit

• Documentation
  • Updated the “Creating custom rules” assembly to remove the C#-specific procedure, so it now transitions from the Python section directly to the following conditional block.
  • Removed the standalone “Creating a custom C# rule” page, including its example configuration and validation instructions.
  • Revised the C# referenced provider documentation to describe Roslyn-based analysis, replaced the old scoping option with location (case-insensitive), and clarified supported selectors.
  • Updated “Provider capabilities in custom rules” to explicitly include Python, Go, and Node.js.
  • Removed the associated provider-capabilities content from the rules YAML conditions assembly.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

The rules development documentation removes C# custom-rule and provider-capability pages from assemblies, updates C# referenced provider semantics and configuration, and expands the documented external provider list.

Changes

Rules development documentation

Layer / File(s)	Summary
Remove obsolete rule content assemblies/rules-development-guide/assembly_creating-rule.adoc, assemblies/rules-development-guide/assembly_rule-yaml-conditions.adoc, docs/topics/rules-development/create-csharp-custom-rule.adoc, docs/topics/rules-development/con_provider-capability-in-custom-rules.adoc	The C# custom-rule and provider-capability documentation pages are removed from the guide and no longer included by their assemblies.
Update .NET provider reference docs/topics/rules-development/yaml-dotnet-provider.adoc	The referenced capability now documents Roslyn-based analysis, supported construct types, dynamic member access, value-flow tracking, and the location setting with ALL as the default.
Expand external provider documentation docs/topics/rules-development/con_external_providers.adoc	The supported provider list adds Python, Go, and Node.js, and the generic-provider initialization note is commented out.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related PRs

• migtools/mta-documentation#309: Overlaps the C# custom-rule guide and .NET provider documentation.
• migtools/mta-documentation#329: Overlaps the csharp.referenced capability’s namespace to location documentation changes.
• migtools/mta-documentation#359: Overlaps the C# custom-rule content in the rules-development guide.

Suggested reviewers: jonahsussman

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately captures the main change: added documentation for the C# Roslyn provider for analysis.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch mta-7228-roslyn

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/topics/rules-development/yaml-dotnet-provider.adoc`:
- Line 28: Update the csharp.referenced location documentation to include FIELD
alongside CLASS, METHOD, and ALL. Clarify that System.Web.Mvc is an example
search pattern or source-code value, not a location value.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 38f7055a-b3a0-48bf-91ef-0a43fe4c1d5a

📥 Commits

Reviewing files that changed from the base of the PR and between 092b125 and fe55ffb.

📒 Files selected for processing (3)

• assemblies/rules-development-guide/assembly_creating-rule.adoc
• docs/topics/rules-development/create-csharp-custom-rule.adoc
• docs/topics/rules-development/yaml-dotnet-provider.adoc

💤 Files with no reviewable changes (2)

• docs/topics/rules-development/create-csharp-custom-rule.adoc
• assemblies/rules-development-guide/assembly_creating-rule.adoc

[Pkylas007]

@mguetta1 @JonahSussman @dymurray Please could you check the updates to C# provider documentation for technical accuracy?

I have not addressed the following points. So, please let me know if I should add any of them:

• .NET SDK 9.0 or higher (please confirm if this is a prerequisite for the C# provider)

• Ad-hoc fallback behavior for legacy .NET Framework applications. Please confirm if I must briefly mention that C# provider handles such apps too. Also, please confirm if paket is a dependency that users must install to handle such cases.

• Related to the point above, have not mentioned that C# provider can analyze .NET Framework app targets: net20 (v2.0), net35 (v3.5), net45 (v4.5), and net472 (v4.7.2).

• Did not mention that the provider uses the .sln file or .csproj files for the analysis (without getting deeper into implementation details).

• Please confirm if the C# provider can resolve dependencies too. Earlier C# provider document mentioned source-only mode. I removed it in the Roslyn-based provider documentation.

[dymurray]

Changes look sane to me; I'm going to defer to @JonahSussman with respect to the capability declarations

[Pkylas007]

@JonahSussman @mguetta1 Can you please help me gain some clarity on the Roslyn-based C# provider? I've listed some queries for your clarification above.

[JonahSussman]

Hey @Pkylas007, here are answers to your questions based on the current provider implementation:

Typo: "inheritence" should be "inheritance" in yaml-dotnet-provider.adoc.

".NET SDK 9.0 or higher" prerequisite: The .NET 9.0 SDK is bundled inside the provider's container image. Users don't need to install it if they are using the container workflow.

Ad-hoc fallback / paket: Worth a brief mention. The provider tries to load projects via MSBuild first (.sln or SDK-style .csproj), then falls back to an ad-hoc compilation for legacy .NET Framework projects. Paket is NOT a dependency users need to install. The provider just reads paket.lock files if they already exist in the analyzed project (same for packages.config and <PackageReference> in .csproj).

.NET Framework targets: Yes, the provider can analyze .NET Framework apps (net20, net35, net40, net45, net472, etc.). For these, it downloads Microsoft.NETFramework.ReferenceAssemblies NuGet packages to provide type information. Worth mentioning that both modern .NET and legacy .NET Framework apps are supported.

.sln / .csproj files: Yes, the provider uses these. It looks for .sln first, then SDK-style .csproj. For non-SDK-style projects it falls back to ad-hoc compilation. A brief mention is fine without going deep into implementation.

Dependency resolution / source-only mode: The provider resolves dependencies internally for compilation purposes (downloads NuGet packages, resolves framework assemblies), but it does not report a dependency graph back to the analyzer. GetDependencies and GetDependenciesDAG are stubs.

"you do not need external tools": This line is slightly misleading. The provider does shell out to dotnet restore for SDK-style projects at runtime. It's bundled in the container so users don't worry about it, but saying "no external tools" isn't strictly true. Maybe rephrase to something like "the provider handles dependency resolution internally using the bundled .NET SDK."

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/topics/rules-development/yaml-dotnet-provider.adoc`:
- Line 14: Update the dependency-resolution guidance in the provider
documentation to explicitly state that it invokes dotnet restore. Clarify that
the bundled .NET SDK removes the need for users to install an SDK in the
container workflow, while network access remains required unless all
dependencies are available locally.
- Line 12: Update the C# provider project-loading description to state
explicitly that it checks `.sln` files first, followed by SDK-style `.csproj`
files; qualify `.csproj` as SDK-style and avoid implying that all project files
use the MSBuild path.
- Line 46: Make the `location` requirement for `csharp.referenced` consistent
between `yaml-dotnet-provider.adoc` and `yaml-provider-conditions.adoc`: verify
the provider’s actual behavior, then update the documentation that disagrees so
both describe the same required/optional status and default handling.
- Line 26: Update the operator reference in the YAML .NET provider documentation
from `typeOf()` to the correct C# spelling `typeof`, preserving the existing
operator list formatting.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: a71c753c-f627-4577-b6aa-ab45ba9006d8

📥 Commits

Reviewing files that changed from the base of the PR and between 55a22c0 and b4dda15.

📒 Files selected for processing (6)

• assemblies/rules-development-guide/assembly_creating-rule.adoc
• assemblies/rules-development-guide/assembly_rule-yaml-conditions.adoc
• docs/topics/rules-development/con_external_providers.adoc
• docs/topics/rules-development/con_provider-capability-in-custom-rules.adoc
• docs/topics/rules-development/create-csharp-custom-rule.adoc
• docs/topics/rules-development/yaml-dotnet-provider.adoc

💤 Files with no reviewable changes (4)

• docs/topics/rules-development/con_provider-capability-in-custom-rules.adoc
• docs/topics/rules-development/create-csharp-custom-rule.adoc
• assemblies/rules-development-guide/assembly_rule-yaml-conditions.adoc
• assemblies/rules-development-guide/assembly_creating-rule.adoc

🚧 Files skipped from review as they are similar to previous changes (1)

• docs/topics/rules-development/con_external_providers.adoc

[Pkylas007]

@JonahSussman Thank you for your explanations! I've modified the draft to include your suggestions. Can you please take a look at the updates?