Live reloading

[SteveSandersonMS]

No description provided.

[SteveSandersonMS]

This is not ready to go in yet as there are problems to be debugged:

• If you're using IISExpress, when you Ctrl+F6 in VS to rebuild a standalone project, sometimes the app doesn't restart correctly. It might be that the page tries to reload so fast that some part of the interplay between VS, IISExpress, and dotnet blazor serve isn't ready yet. Usually this surfaces as 502 errors in the browser, though sometimes you get HTTP requests randomly cut off in the middle (which can appear as .NET exceptions if the assembly files were incomplete). Often pressing F5 in the browser will bring it back, but eventually you'll get to a permanent 502 where the only way to ressurect it is to kill IISExpress completely and get VS to restart it.
• Also when this is enabled, if you Ctrl+F6 on the server project in a hosted scenario, sometimes the build tools will be unable to copy the client assembly into the server bin dir because the old files are still locked. I haven't tracked down why enabling live reloading causes this (though probably it's because some browser in the background is quickly making HTTP requests and preventing the old ASP.NET Core instance from stopping, or maybe starting up a new one using the old DLLs)

These problems occur much more frequently if you're using Firefox (presumably because it's so much faster to do a reload on a WebAssembly app page).

[SteveSandersonMS]

Update This is now rebased on dev as of March 16.

I haven't tracked down why the E2E test fails in AppVeyor when it works reliably both locally on Windows and on Mac/Linux on Travis (and it used to work on AppVeyor before the move to the new build mechanism).

Currently this works really well for standalone projects when you're hosting directly on Kestrel, or for hosted projects when you do a single-project build (e.g., shift+F6) for the client project.

Problems:

• Still if you're using IISExpress a standalone project, it tries to reload too fast and IISExpress hasn't finished shutting down the previous app instance. The reload request often gets cut off with a 502 as the server is shut down while that request is in progress. Even when it does work, it's quite slow on IISExpress because you're waiting for the webserver to come back up, which is totally pointless since the dev server itself never changes so shouldn't need to recycle.
• In the hosted scenario, if you do a full-solution build (e.g., ctrl+shift+b), then the client project builds first and immediately triggers a reload. While this is happening, the server project builds and VS recycles the IISExpress train, so you can get the same 502s. Also on rare occasions, VS can't complete the server build because the early reload sometimes causes the app .dll files to get locked. Ideally there'd be some way to signal that the entire build is completed (whether that's a single project, or a whole solution) but I'm not aware of a way to know when that happens, short of implementing a VS extension (which we could do, since we already have one). And if we did that, we'd need some other mechanism for console builds.

[rynowak]

Is this the work that billhie is going for us? Or will we need to add something ourselves?

[SteveSandersonMS]

Bill is doing some work to avoid the unwanted IISExpress recycles - it's related to this work item, but not to this comment.

We will have to do some work in our VS extension ourselves to detect when a build completes and write the signal file. I was expecting to do that, though I may have to ask for your advice on it since I have no experience of writing any VS extension code.

[rynowak]

We could also consider using files as a notification. Write a file with a particular name as the first change and then delete it when the build is complete.

[SteveSandersonMS]

That's (almost) exactly what we do :) https://github.com/aspnet/Blazor/pull/193/files#diff-017c9b5955fe407916ebe35f7ee07012R63

Only difference is we both write and delete it at once, when the build is complete. We don't need to notify the client that a build is beginning (at least we don't have any need for that yet).

[SteveSandersonMS]

@rynowak I'll merge this as-is unless you have any concerns.

[SteveSandersonMS]

Now merged into dev. Will add VS support next.

[szalapski]

I'm confused; does this mean auto-reloading is working? I am unable to find another issue that describes this feature as either done or not ready yet.

[danroth27]

does this mean auto-reloading is working?

@szalapski Not quite. Currently we support auto-rebuild, where the Blazor app will rebuild automatically in VS when you make changes, but you still have to refresh the browser. Support for full auto reload is tracked by dotnet/aspnetcore#5456.

[szalapski]

Thanks for the update. So this merge is to get auto-rebuild without using "dotnet watch run"? Is the way to configure this documented somewhere?

[danroth27]

This update enabled auto build in VS. You still use dotnet watch from the command line. there really isn't anything to configure.

[SQL-MisterMagoo]

If you are working with standalone Blazor, I've found you don't even need dotnet watch, you just save the code and reload the browser - that triggers a rebuild.

[szalapski]

Working from the command line, I find that edits to a .cshtml do not trigger a rebuild, and so I think I do indeed have to use dotnet watch run rather than dotnet run, coupled with the added line of <Watch Include="**\*.cshtml"/> in <ItemGroup> in my .csproj.

[Tiberriver256]

Is there a guide for how to get the auto-build set up? I just created a new Blazor server project in Visual Studio and I have to restart from Visual Studio whenever I make changes. I would love for it to be as easy as refreshing the browser.

[Tiberriver256]

@danroth27 - Sorry to bump a super old thread again. Still haven't seen any documentation on how to enable the 'Auto Build' feature in Visual Studio 2019. Any pointers?

[danroth27]

@Tiberriver256 To turn on auto rebuild and refresh in VS, use this option:

It's admittedly a bit hard to find unless you know where to look. dotnet watch run should also work.

[DMW007]

I enabled auto build and refresh after save as you showed and also set the automated Kestrel restart to true (cause I'm not using the IIS):

Now I change Counter.razor in a freshly created Razor server project with target framework net5.0 and save the file, nothing happens. Also not after reloading the browser. I'm using the Firefox instance which got started by Visual Studio together with the debugger.

My VS Version was 16.8.1, I updated to 16.8.5 but the only difference was that after the first save VS asked me where to store the file (like with save as). After that it behaves the same. When I set breakpoints, then change and save the code, VS grays them out with a notice that they won't be reached.

I tried running dotnet watch run, this worked out of the box without any modifications on the csproj file as @szalapski said: It detects the changed Counter.razor file, restarts Kestrel and 2-3 seconds later the browser got automatically refreshed.

But I don't have a debugger there, for that reason I'd prefer to use Visual Studio. I can't get it work there, even not when using the IIS Express.

Installed .NET version

dotnet --version
5.0.103

[danroth27]

But I don't have a debugger there, for that reason I'd prefer to use Visual Studio

@DMW007 When running in VS are you running with the debugger attached? Auto restart and refresh are only supported when running without the debugger (Ctrl+F5).