News

Beyond Hot Reload: 'Live Reload' and More

• By David Ramel
• 12/17/2021

What's beyond Hot Reload?

A recent online summit presented by Visual Studio Magazine provides a clue.

Hot Reload may have been late in coming to the .NET dev ecosystem, but Microsoft's "Hot Reload everywhere" push was welcomed by many developers, even if it was just catching up to what was already available in other dev tooling and frameworks.

While it's nice not to have to restart a running project to see code changes reflected, there are even better things in the works as the dev world shifts to more client-side work, said consultant Peter Vogel in the recent summit titled "What's New in Enterprise .NET Development," now available for on-demand viewing.

Vogel, principal at PH&V Information Services near Toronto, was discussing "The .NET 6 Development Landscape for 2022" when he provided a glimpse into the future, starting with more client-side development, which is where the industry is trending.

Improved Hot Reload functionality will inevitably lead to doing more client-side development, he said, and much of that will actually be done in the browser. You'll do the initial work in Visual Studio, VS Code or whatever, but when it comes to debugging, you'll be fixing things in the browser itself.

"So you're going to see more debugging integration," Vogel said. "You're going to see more Hot Reload. The ultimate -- and I think we will be here by the end of the year, if we're not already -- the ultimate will be when you're doing client-side development, and you go, 'oh, that's not right.' You'll press F 12 to open your developer window. You'll go into the HTML and in developer window, you'll change the HTML. You will then surf to your JavaScript files -- still in your browser -- you will make changes to your JavaScript file. You will then rerun your page, and now it's working right and now you'll click the Save button and it'll save your changes back to your project."

One way in which some of that magic is coming to fruition is increased integration between VS Code and Microsoft Edge DevTools via the Microsoft Edge Tools for VS Code extension, with more than 290,000 installs.

"Show the browser's Elements and Network tool inside the Visual Studio Code editor and use it to fix CSS issues with your site and inspect network activity," the description reads. "A Visual Studio Code extension that allows you to use the browser's Elements and Network tool from within the editor. The DevTools will connect to an instance of Microsoft Edge giving you the ability to see the runtime HTML structure, alter layout, fix styling issues, read console messages and view network requests. All without leaving Visual Studio Code."

In practice, though, there's work to be done, as this reporter found out with some initial testing that was fraught with error messages.

Microsoft documentation says DevTools doesn't track live changes to the code as you write, but you can get the browser to automatically refresh when you change a file by setting up what it calls a "live reload."

I followed the instructions, including installing the reload npm package, but when I tried the CLI reload command from my project's folder (stock Blazor example app), I got this error message:

    "reload: C:\Users\david\AppData\Roaming\npm\reload.ps1    
    cannot be loaded. The file 
    C:\Users\david\AppData\Roaming\npm\reload.ps1    
    is not digitally signed. You cannot run this     
    script on the current system. For more 
    information about running scripts and setting    
    execution policy, see about_Execution_Policies   
    at 
    https:/go.microsoft.com/fwlink/?LinkID=135170.   
    At line:1 char:1
    + reload
    + ~~~~~~
        + CategoryInfo          : SecurityError: (:  
       ) [], PSSecurityException
        + FullyQualifiedErrorId : UnauthorizedAccess

I changed the execution policy and then reload worked, but when I made changes that were instantly reflected in the browser, they didn't persist when I relaunched the instance. I also made changes to the code file in the folder that reload was monitoring and saved it, which was supposed to trigger a browser refresh, according to documentation ("All changes that are saved in this folder now trigger a browser refresh."), but that didn't happen.

I was able to launch DevTools, fire up a browser instance and target the Blazor example app served up via localhost, whereupon I could then make simple text edits and color tweaks and see them immediately reflected in the running app, which says "Microsoft Edge is being controlled by automated test software."

But I couldn't open source files from the Elements tool like you're supposed to be able to do. Microsoft documentation says: "One of the features of the Elements tool is that it displays the source file that applied styles and event handlers to a selected node in the DOM tree. Source files appear in the form of links to a URL. Selecting a link opens that file in the Visual Studio Code editor."

However, when I tried to open a CSS file, it didn't work, generating an error message that said:

"An error occurred: Error while mirroring css content to document. Could not mirror css changes to document. No workspace mapping was found for 'http://localhost:59700/css/booststrap/bootstrap.min.css'."

I also tried out some other functionality with CSS Mirror Editing, with no luck. Microsoft says: "CSS mirror editing is an experimental feature that automatically applies changes made in the DevTools panel to CSS files in your workspace."

When CSS Mirror Editing feature was toggled off, I could make a color change and see it instantly reflected. However, when I toggled it on and then tried a color change I got error messages saying:

"Unable to open file in editor. http://localhost:59700/css/bootstrap/bootstrap.min.css does not map to a local file"

and then

"no workspace mapping was found for 'http://localhost:59700/css/bootstrap/bootstrap.min.css'."

So I could make text and CSS changes and see them instantly reflected in the DevTools-controlled browser instance, but I couldn't figure out how to save those changes in the actual code files. Of course, I was working on deadline and didn't have a lot of time to investigate things, so take my experience with a grain of salt.

With that said, a couple of GitHub issues titled Error while mirroring css content to document and also CSS Mirror Editing: Known Issues and Feedback lead me to believe maybe I wasn't the only one experiencing the mirroring problem. The first one specifically mentions the "Could not mirror css changes to document" problem and the second one tracks feedback on the experimental issue, where several posts say similar things.

Anyway, the experimental feature will probably be smoothed out and become workable for even dolts like me, and Vogel alluded to other Hot Reload goodies coming.

".NET 6 continues this," he said. "With .NET 6, you can embed that pdb file, the program debug file that that basically establishes (among other things) the relationship between your compiled code and your source code -- that cross reference. You can embed that pdb file and your source files ... in your executables. The result is you do not have to open your project to start a debug session. All of the debug information is in your deployed executable. And again, this is going to be a Hot Reload session.

"There you go, then, if not now soon. So this is the way your world's going. And again, the client-side environment brings out many of the themes I'm talking about here. If you're working in Visual Studio Code and you decide to do client-side testing, you are effectively working in a constant Hot Reload environment."

I caught up with Vogel after his presentation last week to see what else he's thinking about Hot Reload and beyond.

"I'm the archetype for the .NET developer who, as client-side development has grown, have become more expert at developing in JavaScript/TypeScript," he said. "What's interesting about that to me about that movement is the impact that's had on what we expect in .NET. 'Hot Reload' is becoming more important to us everywhere, not just in our Angular/React/Vue apps (though it's also brings back my days of Visual Basic 6 and edit-and-continue).

"Now, we're seeing a merging of our execution environment and our development environment ... at least if we're working in Visual Studio Code. We've been able to use Chrome's DevTools to change our HTML and our CSS in the browser, see the results and save our changes. Now there are extensions that integrate Chrome and Edge DevTools into Visual Studio so that we'll be able to save our changes back into our application.

"This seems to be a trend because I see all kinds of integration happening in other areas, too: In .NET 6 you can embed your debug files and your source code into your exe. With that, you won't need to find your project or check it out of source control to debug it."

It will be interesting to see how all this stuff matures and emerges in its final form. How tightly will browsers and code editors/IDEs become integrated? Will they be the same thing one day? Only time will tell.

Of course, Vogel discussed much more than Hot Reload, and his presentation is just one of the three sessions included in the summit, where Shawn Wildermuth discussed Reasons to Move Your Development to Visual Studio 2022 and sponsor Progress discussed hot third-party tools.

For even more detailed .NET dev guidance, check out the on-demand VSLive! 2-Day Seminar: ASP.NET Core 6 Service and Website event and the upcoming live shows:

• VSLive! Las Vegas Feb. 27-March 4, 2022
• VSLive! Austin June 13-17, 2022