News

Microsoft on Blazor WebAssembly Debugging Feedback: 'That Sounds Awful!'

Microsoft's Daniel Roth took to X (Twitter) to garner feedback on Blazor WebAssembly client-side debugging and received an earful in response, including complaints about associated Hot Reload functionality.

"That sounds awful!" said the Blazor product manager last week in response to a developer claiming it takes minutes for Hot Reload -- making code changes that are instantly reflected in a running app -- to display those code changes.

Roth's Oct. 24 post read: "Hey all you Blazor WebAssembly users out there! How are things going with Blazor WebAssembly debugging? What sorts of pain points are you still hitting with the debugging experience? Please include details of your .NET and Visual Studio versions if possible!"

One response read: "VS 17.8.0 Preview 3. A .NET7 Blazor Server project. Debugging is fine. Hot Reload is a real pain. Takes minutes to reflect changes. I am better off restarting the app after every change."

Roth's reply: "Minutes?!? That sounds awful! Is this in Visual Studio or using 'dotnet watch'? Have you opened any Visual Studio feedback tickets or GitHub issues for this?"

Roth further investigated the problem, which was also experienced by a dev team that said: "Same for us, any decent sized project takes a couple of minutes for hot reload to work, and even then sometimes it doesn't work at all. We're using latest Visual studio 2022."

Blazor Hot Reload in Animated Action
[Click on image for larger, animated GIF view.] Blazor Hot Reload in Animated Action (source: Microsoft).

He also repeated advice to open up an associated feedback issue to help guide the dev team in response to comments (44 in total) like:

  • When refreshing a page that is running in debug mode it takes about 15 seconds before it loads again. This started with Net 7. If I run it in VS Code with devkit and Blazor debug support it refreshes in a second or maybe two. VS version 17.7.6
  • Have you tried it yourself? It is pretty obious how horrid the blazor experience is, compared to any other .NET framework. But I still use it. A way to actually catch exceptions in code would be a start, I dont wanna sit with the Edge Console on half m acreen.
  • Not really debugging but hot reload is not working for me properly. It is a great feature that speeds up my development process, but I can't use it with #Blazor #WASM. I use .NET 7.
  • Blazor Wasm hot reload using the CLI takes at least 8 to 12 seconds on macOS M1. It could be much more of an awesome product if you guys make the DX on par or at least a few seconds behind what we get on JavaScript land. Please, guys, improve hot reload.
  • The biggest problem I was facing was that it broke the inner loop in hot reload, in my case hot reload successfully applies changes to c# but the changes don't reflect until complete restart. I think some improvements to Wasm C# Hot reload would be huge.

The feedback came with .NET 8 being just a few weeks away from shipping. It joins many GitHub issues in the aspnetcore repo marked "feature-hot-reload," with 174 closed and 33 still open.

The "Hot Reload for Blazor #5456" GitHub issue has been problematic since 2018, when Roth at one point said: "We've hit a snag with live reload for 0.2.0, so moving this out until we can work through a more robust design." Although that issue was closed in September 2021 when it was deemed "completed" for .NET 6, Roth's post and resulting feedback shows it is still problematic and top-of-mind for the dev team.

The team has advanced the feature since then, though, with this year's Visual Studio 2022 17.5 release supporting Hot Reload for CMake projects and even XAML.

However, the road has been bumpy, with a 2022 GitHub issue titled "Hot Reload nearly always fails, with Blazor WebAssembly and "dotnet watch" #45519" listing many related issues, as shown in this screenshot:

[Click on image for larger view.] Hot Reload GitHub Issues (source: GitHub).

That post also listed links to conversations about the issue around the web:

Microsoft's documentation for.NET Hot Reload in ASP.NET Core (the framework where Blazor lives) shows that Blazor WebAssembly Hot Reload supports the following code changes:

  • New types.
  • Nested classes.
  • Most changes to method bodies, such as adding, removing, and editing variables, expressions, and statements.
  • Changes to the bodies of lambda expressions and local functions.
  • Adding static and instance methods to existing types.
  • Adding static fields to existing types.
  • Adding static lambdas to existing methods.
  • Adding lambdas that capture this to existing methods that already captured this previously.

while not supporting these code changes:

  • Adding a new await operator or yield keyword expression.
  • Changing the names of method parameters.
  • Adding instance (non-static) fields, events, or properties.

With .NET 8 done at this point, some Hot Reload work items still showing as "Open" and marked ".NET 9 Planning" include:

  • Debugging & Hot Reload is Broken When App's Base Path is Changed
  • Improve error report on HotReloadAgent
  • Adding a constructor to a controller breaks hot reloading (dotnet watch)
  • Blazor AsyncLocal is null on first re-render following hot reload
  • When using Hot Reload endpoints get duplicated
  • Consider invalidating ComponentProperties cache when Hot Reload triggers metadata update
  • Blazor WebAssembly hot reload support broken when changing environment from Development
  • Handle hot reload refresh when disableDomPreservation = true

Some issues marked "Backlog" include:

  • Hot Reload (Blazor WASM) not working when Solution Configuration is not Debug
  • Simplify WebAssembly hot reload capabilities detection
  • [Blazor] Changing a parameter with default value to nullable causes it's name not to be unique when using hot reload
  • Styles from library component get lost after hotreload
  • Revisit hot reload browser refresh script injection
  • Blazor hot reload of scoped css loses referenced css
  • RenderFragment becomes visible after hot reload
  • When doing hot reload, if it must rebuild, add an option to have it start on the page it was last.
  • Blazor WebAssembly Hot Reload does not work if body tag is incorrect
  • .NET 6 Blazor Hot Reload fails depending on the port specified for the application Url

In last week's X thread, Roth also took time out to answer a question about the future viability of Blazor, whose main selling point is that it lets Microsoft-centric developers use C# for web-dev projects instead of the nearly ubiquitous JavaScript. Blazor WebAssembly is the client-side of the full-stack Blazor offering, paired with Blazor Server.

The question read: "Will Blazor be as performant as other js frameworks in the future? Is this possible?"

Roth's reply: "It depends on the scenario. .NET generally has a performance advantage on the server, like with server-side rendering. On the client JavaScript has an advantage because it ships as part of the web platform."

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube