Summary
The client page loader builds the module bundle URL as _content/${h}/${h}.pages.js, where h is the module identifier the server supplies. That identifier is the SimpleModule.-prefixed module name, but the Razor Class Library serves its static assets under the project's AssemblyName, which sm new module sets to the bare directory basename.
Result: a 404 on every page load.
Reproduction
sm new project MyApp && cd MyApp
sm new module Invoicing
# add a Pages/index.ts + a view endpoint, then
npm run build && dotnet run --project src/MyApp.Host
Open any module page and watch the console.
Result
GET /_content/Invoicing/Invoicing.pages.js -> 200
GET /_content/SimpleModule.Invoicing/SimpleModule.Invoicing.pages.js -> 404 <-- what is requested
Console on every page load:
Failed to load resource: the server responded with a status of 404 ()
@ /_content/SimpleModule.Invoicing/SimpleModule.Invoicing.pages.js?v=...
Failed to load resource: the server responded with a status of 404 ()
@ /_content/SimpleModule.Customers/SimpleModule.Customers.pages.js?v=...
Vite emits the bundle named from the directory basename (Invoicing.pages.js), which the scaffold's own .csproj comment says is required:
<!-- AssemblyName must equal the project directory basename so the RCL
serves wwwroot at /_content/Invoicing/ and the Vite pages bundle
(Invoicing.pages.js, named from the directory basename) resolves. -->
<AssemblyName>Invoicing</AssemblyName>So the build side is consistent with the directory name, and only the runtime lookup uses the prefixed module name.
Why it matters
- A failed request and a console error on every page navigation, which buries real errors during debugging.
- Pages do still render, so the failure is silent to anyone not watching the console — which makes it likelier to be diagnosed as something else later.
- It costs a wasted round trip per navigation.
Suggested fix
Have the server hand the client the module's assembly name (what the RCL actually serves under) rather than the SimpleModule.-prefixed module name — or register the static asset base path under the prefixed name so both resolve.
Environment
SimpleModule.Cli 0.0.39, packages 0.0.39- .NET SDK 10.0.201, Node 23.5.0, macOS
Related: #284 (same mismatch between module name and project/assembly name, in extract-ts-types.mjs), #283.
Summary
The client page loader builds the module bundle URL as
_content/${h}/${h}.pages.js, wherehis the module identifier the server supplies. That identifier is theSimpleModule.-prefixed module name, but the Razor Class Library serves its static assets under the project'sAssemblyName, whichsm new modulesets to the bare directory basename.Result: a 404 on every page load.
Reproduction
Open any module page and watch the console.
Result
Console on every page load:
Vite emits the bundle named from the directory basename (
Invoicing.pages.js), which the scaffold's own.csprojcomment says is required:So the build side is consistent with the directory name, and only the runtime lookup uses the prefixed module name.
Why it matters
Suggested fix
Have the server hand the client the module's assembly name (what the RCL actually serves under) rather than the
SimpleModule.-prefixed module name — or register the static asset base path under the prefixed name so both resolve.Environment
SimpleModule.Cli0.0.39, packages 0.0.39Related: #284 (same mismatch between module name and project/assembly name, in
extract-ts-types.mjs), #283.