Skip to content

Fix storefront rendering with no CSS/JS (Razor tag helper regression) - #784

Merged
KrzysztofPajak merged 3 commits into
developfrom
fix/storefront-missing-styles-taghelpers
Aug 14, 2026
Merged

Fix storefront rendering with no CSS/JS (Razor tag helper regression)#784
KrzysztofPajak merged 3 commits into
developfrom
fix/storefront-missing-styles-taghelpers

Conversation

@KrzysztofPajak

Copy link
Copy Markdown
Member

Resolves #issueNumber
Type: bugfix

Issue

Freshly built/deployed storefront (e.g. via the repo's Dockerfile) rendered with no CSS or JS at all. View-source showed tag helper elements passed through as literal, unprocessed markup instead of being expanded - e.g. <partial name="Partials/Head"/>, <resources asp-type="HeadLink"/>, <meta-keywords>, <vc:widget .../> all appeared verbatim in the response HTML instead of becoming <link>, <script>, <meta> tags. The admin area was unaffected.

Two separate causes, both triggered by the same symptom:

  1. Plugins (Theme.Modern and every other plugin) couldn't see host tag helpers.Grand.Plugin.props referenced Grand.Web.Common with ExcludeAssets="all", which also excludes compile-time assets - the ones Razor's tag helper discovery needs at plugin-build time. The comment on that line already stated the actual intent ("referenced for its views and tag helpers, nothing is linked from it"), which is what ExcludeAssets="runtime" does (matching every other reference in the file) - all was the wrong value.

  2. A Razor compiler regression between .NET SDK feature bands. Building the exact same source with mcr.microsoft.com/dotnet/sdk:10.0.301 produces a working storefront; building it with mcr.microsoft.com/dotnet/sdk:10.0.400 (what the floating 10.0 tag currently resolves to) reproduces the broken rendering, on Grand.Web's own precompiled views - no plugin or ExcludeAssets involved. Confirmed the two SDKs ship genuinely different Microsoft.CodeAnalysis.Razor.Compiler.dll builds (10.0.0-preview.26270.133 vs 10.4.0-preview.26379.115, ~109 days of commits apart). Root mechanism inside the compiler not identified; reproduced and pinned as a workaround.

Solution

  • src/Build/Grand.Plugin.props: ExcludeAssets="all" -> "runtime" on the Grand.Web.Common reference.
  • Dockerfile: pin the build image to mcr.microsoft.com/dotnet/sdk:10.0.301 instead of the floating 10.0 tag.
  • global.json: rollForward tightened from latestFeature to latestPatch against 10.0.301, so a local build or CI runner with only a 400-band SDK installed doesn't silently reproduce the same breakage outside Docker.

Breaking changes

None. Pinning the SDK is stricter, not looser - anyone building with an SDK older than 10.0.301 already failed under the previous 10.0.100/latestFeature config too.

Testing

  1. docker build -t grandnode2:local .
  2. Run the image against a MongoDB instance and complete installation (or reuse an already-installed App_Data).
  3. curl -s http://localhost:8090/ | grep -c 'resources asp-type\|<partial name' -> expect 0.
  4. curl -s http://localhost:8090/ | grep -oc '<link\b' -> expect several real <link> tags, and confirm /bundles/style.min.css, /bundles/libs.css, /bundles/app.runtime.bundle.js all return 200.
  5. Load the homepage in a browser and confirm it is styled.

🤖 Generated with Claude Code

KrzysztofPajakand others added 2 commits August 14, 2026 19:23
Grand.Plugin.props referenced Grand.Web.Common with ExcludeAssets="all",
which also strips compile-time assets. Razor's tag helper discovery for
a plugin's Views relies on that compile-time reference, so no plugin
(Theme.Modern included) could see host tag helpers (<partial>,
<resources>, <vc:*>, etc.) - they were baked into the precompiled view
as literal, unprocessed markup.
The comment on the line already stated the intent - "referenced for its
views and tag helpers, nothing is linked from it" - which is exactly
what ExcludeAssets="runtime" does, matching every other reference in
this file. Changed all -> runtime.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The 10.0.400 feature-band SDK ships a different Razor compiler build
(Microsoft.CodeAnalysis.Razor.Compiler.dll: 10.4.0-preview.26379.115
vs 10.0.301's 10.0.0-preview.26270.133) that fails to wire up tag
helpers on Grand.Web's own precompiled views - <partial>, <resources
asp-type=...>, <meta-keywords> etc. rendered as literal, unprocessed
markup, so the storefront shipped with no CSS/JS at all.
Reproduced by building the same source with sdk:10.0.301 (works) vs
sdk:10.0.400 (broken), both from mcr.microsoft.com/dotnet/sdk:10.0.
Dockerfile now pins the build image to 10.0.301 instead of the
floating 10.0 tag.
global.json's rollForward was "latestFeature", which is how a local
build or CI runner with only the SDK's 400-band installed silently
picks up the broken compiler even though the Dockerfile is pinned.
Tightened to "latestPatch" against 10.0.301 so every environment
building this repo gets the same, verified-working compiler.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CopilotAI lite review requested due to automatic review settings August 14, 2026 17:23

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

The floating 'dotnet-version: 10.0.x' / 'version: 10.0.x' inputs let
actions/setup-dotnet and UseDotNet@2 install whatever the newest 10.0
patch is - currently 10.0.400, the feature-band with the broken Razor
compiler this PR works around.
Tightening global.json's rollForward to latestPatch (previous commit)
without fixing this meant CI would install 10.0.400, then dotnet build
would refuse to run against it (global.json now demands a 10.0.301.x
SDK) - confirmed live on the Azure Pipelines run right after global.json
landed: 'dotnet/sdk] ##[error]Error: ... failed with exit code 155'
after installing 10.0.400. Pinning every CI SDK install to 10.0.301
keeps it consistent with the Dockerfile and global.json.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@KrzysztofPajak
KrzysztofPajak merged commit f51835e into developAug 14, 2026
8 checks passed
@KrzysztofPajak
KrzysztofPajak deleted the fix/storefront-missing-styles-taghelpers branch August 14, 2026 18:04
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@KrzysztofPajak