A free and open-source web framework that enables developers to create web apps using C# and HTML, developed by Microsoft.
Hi @iKingNinja ,
Thanks for reaching out.
The scoped CSS bundle is generated at build time and its route is wired up through that pipeline, so there isn’t a supported way in MapStaticAssets() to change just the route for <ProjectName>.styles.css. While you may be able to modify the generated staticwebassets.endpoints.json with a custom MSBuild target, I wouldn’t recommend it since that file is treated as build output and can change between SDK versions.
Please also treat the code snippets below as reference examples. You may need to adjust the project name, paths, middleware order, base path, or hosting setup to match your specific project structure.
In normal scenarios, the suitable approach is to avoid hardcoding the URL altogether and let Blazor resolve it for you:
<link rel="stylesheet" href="@Assets["MyApp.styles.css"]" />
This way the framework handles the correct path (including fingerprinting), and you don’t have to worry about where the file is physically served from.
If your goal is to influence where static assets are exposed more broadly, you can set a base path in your project file:
<PropertyGroup>
<StaticWebAssetBasePath>assets</StaticWebAssetBasePath>
</PropertyGroup>
That shifts the base URL for all static web assets, not just the scoped CSS bundle. You’d still reference the file using @Assets[...], and Blazor will resolve the updated path automatically.
If you’re trying to control the bundle name itself, that comes from the project/package identity. For example:
<PropertyGroup>
<PackageId>MyCustomName</PackageId>
</PropertyGroup>
which would result in:
<link rel="stylesheet" href="@Assets["MyCustomName.styles.css"]" />
For cases where you specifically need a custom public-facing URL (for example /custom/path/styles.css), the suggested approach is to introduce a rewrite rather than changing how the asset is generated:
app.Use(async (context, next) =>
{
if (context.Request.Path.Equals("/custom/path/styles.css", StringComparison.OrdinalIgnoreCase))
{
context.Request.Path = "/MyApp.styles.css";
}
await next();
});
app.MapStaticAssets();
You can then reference /custom/path/styles.css, and the app will internally serve the original bundle. If you’re using a reverse proxy or CDN, doing the rewrite there is often even cleaner.
If you need full control over the file name, location, and route, the supported escape hatch is to opt out of the built-in bundling:
<PropertyGroup>
<DisableScopedCssBundling>true</DisableScopedCssBundling>
</PropertyGroup>
At that point you’d take over the process yourself (collecting the generated scoped CSS from obj, bundling or copying it into wwwroot, and referencing it however you like). It gives you complete flexibility, but you’re also responsible for maintaining that pipeline.
Hope this helps! If my answer was helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.