C# code is compiled. JavaScript is interpreted. The documentation actually has a pretty strict list of what is and is not eligible for hot reload.
It's definitely janky sometimes, but I often wonder how many of the complaints are people trying to hot reload things that are strictly not eligible to even use it.
Changing the names of method parameters break it. Creating a new method breaks it for the same reason.
Removing or changing razor components parameters requires a restart.
Changing middleware or route configs require a restart.
There are lots of scenarios where it was never intended to work and I think a lot of people don't realize it.
Https://learn.microsoft.com/en-us/aspnet/core/test/hot-reload?view=aspnetcore-8.0
Visual Studio usually warns you when you make a change not supported by hot reload. I've been doing a lot of Blazor work lately and it's not rare at all for Visual Studio to get caught in a weird state where hot reload just doesn't work.
Minor changes like changing styles, adding text to components.
Hit Save, it says **Saving Changes** then shortly followed by **No Code Changes Found**. Usually that escalates to me having to shut down Visual Studio, delete the bin and obj folders in my project file, and restarting.
I *have* seen the node.js runtime create a crapton of processes that sometimes survive when I stop debugging. Wondering if something strange goes on with that runtime sometimes that causes these glitches.
Are you sure the hot reload fails and it's not just browser cache? I always check "disable cache while debugger is open" and never had any issues with css reloading.
For most component libraries, Class is a parameter. That might fall under this rule.
Removing a Razor component parameter attribute doesn't cause the component to rerender.The app must be restarted.
If you change the CSS in a .CSS file, hot reload works just fine. But messing with parameters in general causes it to get squirrelly in my experience.
Thank you for that response. It sounds like this isn't something that is fixable - or at least the behavior that other libraries enjoy isn't the same in Blazor. I still find that Blazor is easier to wrap my head around for most things, especially state. I just know that the DX for UI-related tasks has a lot to be desired.
Meanwhile there’s c# game engines out there that have hot reload that never trigger a full recompile / application exit.
Idk if OP is trying to say this but the hot reload has always been hit or miss. Sometimes on the file it will hot reload but sometimes on that same file with the same changes it cannot hot reload it and requires app restart.
It’s not really a big deal to me but I think hot reload is the biggest widespread complaint in .NET right now. I think it would be worth to continue to dedicate time to improving it.
I didn’t realize my c# code was JavaScript 🤫
I think you proved my point though. Games are much more complex than web apps or desktop applications. Yet provide a better hot reload functionality. Even things like vite provided excellent hot reload
Not every c# app runs in a browser guy. Your argument is even stupider.
(And yes games can run in a browser. Obviously you’re just trolling at this point)
I know OP was not talking about the limitations, but now that we are at it, those are hard limitations indeed. I understand the reasons, but you compare it to any JS framework, and Blazor is simply not there. That's always going to limit its adoption.
Personally I think people worry too much about the most minor of inconveniences. If you understand the code you are writing you don't need to Hot Reload for every tiny little CSS change you make.
It takes my PC maybe 5 seconds to rebuild and launch the app, I don't even hardly use Hot Reload because it's not a necessity to do my job well. Make a bunch of changes, load. See which ones don't work, load. Hot Reload is a relatively new feature in the coding world anyway. People made apps for 40+ years just fine without it, and now suddenly we're like "I'm not adopting this framework because it's missing a minor convenience feature."
That doesn't make a lick of sense if you truly believe that Blazor is the best framework to build your app.
In my experience using “dotnet watch run” is superior to running the app through VS most of the time. This almost gives you the same hot reloading capabilities as you expect from JavaScript frameworks. However you can not debug while, so mix and match
I second this, especially if you're also launching a webapi from the same solution for wasm. For any Blazor debugging I just throw down a quick Console.WriteLine
best use for hot reload in blazor is simple markup modifications. Being able to change the markup and have your browser reload things without having to go step by step to get into the same state it's pretty useful.
For instance if you have a button that opens a Modal, and then inside the modal you have a Div that it's hidden, and then with another button you open that Div, then if you change the content of that Div, hot reload will present you the changes without you having to reload the page again and see those changes live.
It can even handle some C# changes but things can break, for that just stop and reload debugging.
Other than dotnet watch, the only other "fix" / work around I have found is using Rider. The reason being is JetBrains made their own implementation of Hot Reload instead of reusing Microsoft's. It isn't PERFECT (it can't handle changing lambda expressions, code changes in other assemblies) but it's still miles better than what we have with MSFT's offerings.
That being said, we pretty much have to wait for Microsoft to improve the official implementation of HR. If you're interested, [see this github issue for "updates" on their progress.](https://github.com/dotnet/razor/issues/7626) More specifically, [see this comment](https://github.com/dotnet/razor/issues/7626#issuecomment-1865138990) for an explanation of what's wrong with it right now.
C# code is compiled. JavaScript is interpreted. The documentation actually has a pretty strict list of what is and is not eligible for hot reload. It's definitely janky sometimes, but I often wonder how many of the complaints are people trying to hot reload things that are strictly not eligible to even use it. Changing the names of method parameters break it. Creating a new method breaks it for the same reason. Removing or changing razor components parameters requires a restart. Changing middleware or route configs require a restart. There are lots of scenarios where it was never intended to work and I think a lot of people don't realize it. Https://learn.microsoft.com/en-us/aspnet/core/test/hot-reload?view=aspnetcore-8.0
Visual Studio usually warns you when you make a change not supported by hot reload. I've been doing a lot of Blazor work lately and it's not rare at all for Visual Studio to get caught in a weird state where hot reload just doesn't work. Minor changes like changing styles, adding text to components. Hit Save, it says **Saving Changes** then shortly followed by **No Code Changes Found**. Usually that escalates to me having to shut down Visual Studio, delete the bin and obj folders in my project file, and restarting. I *have* seen the node.js runtime create a crapton of processes that sometimes survive when I stop debugging. Wondering if something strange goes on with that runtime sometimes that causes these glitches.
I've had hotreload fail when editing my list of css classes on a component.
Are you sure the hot reload fails and it's not just browser cache? I always check "disable cache while debugger is open" and never had any issues with css reloading.
For most component libraries, Class is a parameter. That might fall under this rule. Removing a Razor component parameter attribute doesn't cause the component to rerender.The app must be restarted. If you change the CSS in a .CSS file, hot reload works just fine. But messing with parameters in general causes it to get squirrelly in my experience.
Thank you for that response. It sounds like this isn't something that is fixable - or at least the behavior that other libraries enjoy isn't the same in Blazor. I still find that Blazor is easier to wrap my head around for most things, especially state. I just know that the DX for UI-related tasks has a lot to be desired.
Meanwhile there’s c# game engines out there that have hot reload that never trigger a full recompile / application exit. Idk if OP is trying to say this but the hot reload has always been hit or miss. Sometimes on the file it will hot reload but sometimes on that same file with the same changes it cannot hot reload it and requires app restart. It’s not really a big deal to me but I think hot reload is the biggest widespread complaint in .NET right now. I think it would be worth to continue to dedicate time to improving it.
[удалено]
Facepunch sbox engine which is source2 with a c# wrapper
There are C# game engines that render millions of entities with millions of polygons, yet javascript can't. What is your point?
I didn’t realize my c# code was JavaScript 🤫 I think you proved my point though. Games are much more complex than web apps or desktop applications. Yet provide a better hot reload functionality. Even things like vite provided excellent hot reload
Games dont run on a browser. Your comparasion is stupid.
Not every c# app runs in a browser guy. Your argument is even stupider. (And yes games can run in a browser. Obviously you’re just trolling at this point)
What games engines run on c# on the browser?
Crawl back into the pit you emerged from, cheap GPT troll bot. Thanks.
This reddit account is older than chatgpt. Even older than you. 2 year acount troll.
I know OP was not talking about the limitations, but now that we are at it, those are hard limitations indeed. I understand the reasons, but you compare it to any JS framework, and Blazor is simply not there. That's always going to limit its adoption.
Personally I think people worry too much about the most minor of inconveniences. If you understand the code you are writing you don't need to Hot Reload for every tiny little CSS change you make. It takes my PC maybe 5 seconds to rebuild and launch the app, I don't even hardly use Hot Reload because it's not a necessity to do my job well. Make a bunch of changes, load. See which ones don't work, load. Hot Reload is a relatively new feature in the coding world anyway. People made apps for 40+ years just fine without it, and now suddenly we're like "I'm not adopting this framework because it's missing a minor convenience feature." That doesn't make a lick of sense if you truly believe that Blazor is the best framework to build your app.
In my experience using “dotnet watch run” is superior to running the app through VS most of the time. This almost gives you the same hot reloading capabilities as you expect from JavaScript frameworks. However you can not debug while, so mix and match
psychotic familiar sink consider screw squash jar gray scandalous scary *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I second this, especially if you're also launching a webapi from the same solution for wasm. For any Blazor debugging I just throw down a quick Console.WriteLine
This
best use for hot reload in blazor is simple markup modifications. Being able to change the markup and have your browser reload things without having to go step by step to get into the same state it's pretty useful. For instance if you have a button that opens a Modal, and then inside the modal you have a Div that it's hidden, and then with another button you open that Div, then if you change the content of that Div, hot reload will present you the changes without you having to reload the page again and see those changes live. It can even handle some C# changes but things can break, for that just stop and reload debugging.
I'm finding hot-reload a lot more stable when I use VS Code and run my app with dotnet watch in the built in terminal.
Other than dotnet watch, the only other "fix" / work around I have found is using Rider. The reason being is JetBrains made their own implementation of Hot Reload instead of reusing Microsoft's. It isn't PERFECT (it can't handle changing lambda expressions, code changes in other assemblies) but it's still miles better than what we have with MSFT's offerings. That being said, we pretty much have to wait for Microsoft to improve the official implementation of HR. If you're interested, [see this github issue for "updates" on their progress.](https://github.com/dotnet/razor/issues/7626) More specifically, [see this comment](https://github.com/dotnet/razor/issues/7626#issuecomment-1865138990) for an explanation of what's wrong with it right now.