能否在Razor、CSS与C#文件中统一压缩CSS类名？Blazor栈的理论可行性及相关文件探究

Great question! Let’s break this down clearly—yes, compressing CSS class names across your Blazor app is absolutely feasible in theory, and we can map out exactly which files in the bin directory you’d need to target for a custom implementation. This aligns with the post-processing work you’re familiar with in Pug/Stylus/TypeScript stacks, just with different file types to handle.

Core Feasibility #

At its core, Blazor still relies on mapping CSS class names between markup, styles, and logic—just like the HTML/CSS/JS stack you know. The key difference is that some of the markup and logic lives in compiled .NET assemblies instead of plain text files, but that doesn’t prevent us from safely replacing class names as long as we target the right files.

Target Files in the bin Directory #

Here’s exactly what you’ll need to process in your build’s output directory:

1. Static Web Assets (wwwroot) #

These are the most straightforward, mirroring your frontend stack workflow:

• Compiled CSS files: Found in bin/[Configuration]/[TargetFramework]/wwwroot/css/ (e.g., bin/Debug/net8.0/wwwroot/css/site.css or scoped files like Component.razor.g.css for CSS isolation). You can process these using regex or AST parsers just like you would with Stylus-compiled CSS.
• Static HTML files: Any .html files (like index.html) in the wwwroot subdirectory will have hardcoded class names—treat these the same way you handle Pug-generated HTML.
• Blazor JS glue files: For WebAssembly apps, look for blazor.webassembly.js; for Server apps, blazor.server.js. If you use JS interop to manipulate class names (e.g., document.querySelector('.menu--s--')), these strings will live in this file and need replacement.

2. Compiled Blazor Component Assemblies #

Your .razor components get compiled into .NET DLLs, which live directly in bin/[Configuration]/[TargetFramework]/ (e.g., YourApp.dll). These assemblies contain hardcoded class name strings from your component markup (like builder.AddAttribute(2, "class", "menu--s--"); in the generated C# code).

To modify these safely, you’ll need a .NET IL manipulation library like Mono.Cecil—this lets you scan the assembly’s string constants, find matches to your target class names, and replace them with compressed values. This is analogous to using an AST parser instead of naive regex for TypeScript files, ensuring you don’t break unrelated code.

3. CSS Isolation Special Case #

If you use Blazor’s built-in CSS isolation (.razor.css files), the framework automatically appends a unique hash to class names (e.g., .menu--s--_xyz123). You’ll need to:

• Process the generated scoped CSS file (in wwwroot/css/) to replace the hashed class name with your compressed version.
• Update the corresponding component DLL to replace the original class name + hash string with your compressed name.

Critical Implementation Notes #

• Strict Naming Convention: Just like you used the --s-- suffix in your frontend example, define a unique pattern for class names you want to compress. This avoids false positives (especially important in .NET DLLs, which are full of unrelated strings).
• Build Pipeline Integration: Hook your post-processing step into the .NET build pipeline using MSBuild targets or a custom tool that runs after compilation. This mirrors how you automate Gulp tasks for your frontend stacks.
• Avoid Naive Regex on DLLs: Never use raw regex to modify DLL files directly—always use a dedicated IL manipulation library to ensure you don’t corrupt the assembly.

内容的提问来源于stack exchange，提问作者Takeshi Tokugawa YD