Skip to content

feat(extract): discover Razor Pages / MVC views (.cshtml) and route their @page - #2024

Merged
DeusData merged 2 commits into
mainfrom
feat/cshtml-razor-pages
Sep 4, 2026
Merged

feat(extract): discover Razor Pages / MVC views (.cshtml) and route their @page#2024
DeusData merged 2 commits into
mainfrom
feat/cshtml-razor-pages

Conversation

@DeusData

@DeusData DeusData commented Sep 3, 2026

Copy link
Copy Markdown
Owner

Follow-up to #1824 (thanks @The1nk), which mapped Blazor .razor to the C# host and extracted @page routes from it. This extends the same treatment to the rest of the Razor family, and stops there.

Why .cshtml specifically

.cshtml is the same Razor syntax with the same C# host, and it was equally unmapped — an ASP.NET Core MVC or Razor Pages application produced no nodes at all for its entire view tree.

@page matters more here than it does for components. On a Blazor component the directive is an optional annotation; in Razor Pages it is the directive that defines a page, so the routable surface of a Razor Pages app lives exclusively in this file type.

The extension mapping alone would not have worked

cbm_path_is_razor() hardcoded a single .razor suffix. Adding {".cshtml", CBM_LANG_CSHARP} to the extension table would have given .cshtml discovery and parsing but left it skipped by the directive scan — files present in the graph with none of their routes, which is the more confusing of the two failure modes. The gate is now a suffix table covering both.

Scope: the Razor family only

  • .vbhtml — excluded. There is no VB.NET language in this repo, so there is no host to map it to.
  • .aspx / .ascx — excluded. Web Forms is a different templating syntax (<%@ %>, runat="server") with no @page directive, so neither the C# error recovery nor the directive scan applies. Mapping them would produce parse noise and no routes.

Best-effort on the same terms as .razor: the C# grammar recovers the @{ } and @functions blocks, and the surrounding markup lands in ERROR regions reported through parse_partial.

Tests

  • lang_ext_cshtml — the extension mapping.
  • extract_razor_page_directive_routes_cshtml_view — a Pages/Orders/Index.cshtml with @page "/orders", asserting the extracted route path and method.
  • extract_razor_layout_without_page_has_no_route — a Pages/Shared/_Layout.cshtml, asserting no Route node. Most .cshtml files are layouts and partials; a spurious Route per view would be worse than the missing ones this fixes.

Local: language + extraction suites pass (566), lint-ci clean.

…heir @page

Follow-up to #1824, which mapped Blazor `.razor` to the C# host and extracted
`@page` routes from it. `.cshtml` is the same Razor syntax with the same C#
host and was equally unmapped: an ASP.NET Core MVC or Razor Pages application
produced no nodes at all for its entire view tree.

`@page` matters more here than it does for components. On a Blazor component
the directive is an optional annotation; in Razor Pages it is the directive
that *defines* a page, so the routable surface of a Razor Pages app lives
exclusively in this file type.

That is why the extension mapping alone is not enough. `cbm_path_is_razor()`
hardcoded a single `.razor` suffix, so a `.cshtml` file would have been
discovered and parsed but skipped by the directive scan -- present in the
graph, with none of its routes. Widened to a suffix table covering both.

Scope is deliberately the Razor family and nothing else:

  - `.vbhtml` is excluded because there is no VB.NET language in this repo,
    so there is no host to map it to.
  - `.aspx` / `.ascx` are excluded because Web Forms is a different templating
    syntax (`<%@ %>`, `runat="server"`) with no `@page` directive, so neither
    the C# error recovery nor the directive scan applies.

Best-effort on the same terms as `.razor`: the C# grammar recovers the `@{ }`
and `@functions` blocks, and the surrounding markup lands in ERROR regions
reported through parse_partial.

Tests: the extension mapping; a Razor Page asserting the extracted route path
and method; and a negative case for a layout with no `@page`, since most
`.cshtml` files are layouts and partials and a spurious Route node per view
would be worse than the missing ones this fixes.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
@DeusData DeusData added enhancement New feature or request parsing/quality Graph extraction bugs, false positives, missing edges language-request Request for new language support priority/normal Standard review queue; useful PR with ordinary maintainer urgency. labels Sep 3, 2026
@DeusData
DeusData merged commit 9ed01a4 into main Sep 4, 2026
35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request language-request Request for new language support parsing/quality Graph extraction bugs, false positives, missing edges priority/normal Standard review queue; useful PR with ordinary maintainer urgency.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant