There’s been a bit of a hoopla lately around Microsoft pulling a feature from the upcoming .NET 6 release. The feature in question is “Hot Reload”. I’m going to do a post in the future that goes more in depth as to what hot reload can and can’t do, but it’s pretty darn impressive and works in ways you actually don’t expect it to.
The cliff notes for what hot reload does is that it allows you to apply code changes to a running application *without* recompiling and restarting the application. If you’ve used the dotnet watch command before, it’s similar, expect that with dotnet watch it recompiles the entire application and restarts. Hot reload literally applies the changes right there and then as the application is running.
To give you an idea of just how bananas this is, here’s a gif of a console application below. I have it outputting “ABC” every 1 second. I then go ahead and change the text output, and hit the Hot Reload button on the toolbar and without the application closing, my changes are applied in realtime without skipping a bit. Pretty incredible!
(Click to view the full size GIF)
So, amazing feature, works well, what’s all the kerfuffle about?
It all started with the following blog post : https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/
Most notably this quote :
With these considerations, we’ve decided that starting with the upcoming .NET 6 GA release, we will enable Hot Reload functionality only through Visual Studio 2022 so we can focus on providing the best experiences to the most users. We’ll also continue to pursue adding Hot Reload to Visual Studio for Mac in a future release. […] To clarify, we are not releasing Hot Reload as a feature of the dotnet watch tool
What Microsoft is saying here is that the hot reload functionality will be only available through Visual Studio 2022, not via Command Line, Visual Studio For Mac or VS Code. At first, this doesn’t seem like such a big deal right? A feature has been built for Visual Studio and not for anything else. It happens.
But there’s a problem. It actually does exist on the command line for preview versions of .NET 6, but this PR removes the feature : https://github.com/dotnet/sdk/pull/22217. So what we’re seeing is that Microsoft actively pulled a feature to make it available only in Visual Studio, and not on any other platform.
It’s also somewhat doubly annoying because back in May, the support for hot reload via dotnet watch was actually announced itself in a blog post : https://devblogs.microsoft.com/dotnet/introducing-net-hot-reload/
Today, we are excited to introduce you to the availability of the .NET Hot Reload experience in Visual Studio 2019 version 16.11 (Preview 1) and through the dotnet watch command-line tooling in .NET 6 (Preview 4).
Now there’s Github issues being raised getting hammered with commends (https://github.com/dotnet/sdk/issues/22247), and even a PR that attempts to revert the changes (https://github.com/dotnet/sdk/pull/22262) under the guise of “Well if .NET is open source, then you have to accept this change”.
I usually avoid any sort of pitchfork display, so let’s tone down the verbiage a bit and actually just break down what’s happened :
In May, it was announced that dotnet watch and Visual Studio 2019 would have Hot Reload and was available now (And presumably Visual Studio 2022 would soon follow)
In October, it was announced that Visual Studio 2022 would be the only developer tool to receive Hot Reload, and a PR was created to remove hot reload from dotnet watch.
Follow up posts mention that Hot Reload itself maybe wasn’t production ready inside dotnet watch, or that Microsoft wanted to focus their efforts on hot reload being the best it could be in Visual Studio 2022, but developers feel like it’s simply a way to push people towards Visual Studio.
Given that Visual Studio is Windows Only, it implies that other operating systems will not receive hot reload in the near future, if at all. Especially if you do not use Visual Studio for Mac.
dotnet watch itself is *not* removed (I saw some people confused about this). The typical “dotnet watch build” dev flow is still applicable, it will just recompile your code instead of using hot reload.
So what’s going to happen? Microsoft will revert the decision. Almost certainly. At the very least you will see the feature being put behind an “experimental” flag on dotnet watch. A few years ago there was a similar issue on whether ASP.NET Core 2.0 should support .NET Framework as a runtime, Microsoft said no (Which I agreed with by the way!), community said yes, Microsoft said yes.