Creating a Blazor project with a space in its name breaks the styling

[danroth27]

This user created their first Blazor app with a project that had a space in its name, which broke downloading the styles bundle: dotnet/core#8939.

Repro steps:

• Create a new Blazor Web App named "Blazor Test"
• Run the app

Expected result: App runs fine
Actual result:

[javiercn]

@danroth27 It's been that way since Blazor 3.0/3.1 and MVC.

It's a well-known template/bug/limitation, I believe.

[javiercn]

Dug out how to do this.

Should be doable I think with a generated parameter and a regex like:

{
  "regex": " ",             //The regular expression whose matches will be replaced with '[Replaced]`
  "replacement": "_"   //The value to replace matches of the expression '^test' with
},

Then we would need to change that in the layout, so that it replaces AssemblyName.styles.css or similar.

https://github.com/dotnet/templating/wiki/Available-Symbols-Generators#samples-7

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

Adding to the symbols

"StyleBundleName":{
  "type": "generated",
  "generator": "regex",
  "replaces": "StyleBundleName",
  "parameters": {
    "source": "name",
    "steps": [
      {
        "regex": " ",
        "replacement": "_"
      }
    ]
  }
},

And

<link rel="stylesheet" href="BlazorWebStyleBundleName.styles.css" />

to App.Razor should fix it.

We should do this across all our templates.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.