Hot Reload removed from dotnet watch - Why?

[rgwood]

Hot Reload functionality in dotnet watch was recently deleted and it seems that Hot Reload will be VS-only going forward. I've been using that functionality in dotnet watch happily for a while now, and this seems like a huge step backward for .NET. Most new .NET developers aren't using VS, and many aren't even on Windows.

Could we get some more information on why this change was made? The linked blog post is very light on details and the PR has been locked to collaborators.

[AnthonyMastrean]

@rgwood you say you've been using the feature "for a while now" but it's only been in since April/May as part of the .NET 6 previews... you've been using it in preview?

[rgwood]

Correct. It’s been working well for me in the .NET 6 previews.

[AnthonyMastrean]

My team is very interested in this feature being available cross-platform, since we have folks on all platforms and primarily use Visual Studio Code. I hadn't noticed the initial announcement, only this mention of it being removed! I don't think it made it into a .NET 6 preview blog post.

https://devblogs.microsoft.com/dotnet/introducing-net-hot-reload/

[rgwood]

@LyalinDotCom was kind enough to clarify on Twitter (and to be clear, I do appreciate it; please don't shoot the messenger):

Sorry for any confusion. To clarify, given the number of scenarios we are working on, we had to prioritize :(. As a result, Hot Reload will not release as a feature of dotnet watch tool. We are doubling down on VS 2022 with support for VS4Mac coming later

I can certainly appreciate competing priorities, but this is still very disappointing. dotnet watch hot reload already seemed great to me, and if necessary it could have been moved behind a preview flag like other .NET 6 features (ex: generic math).

I've been using this feature as part of my cross-platform workflow, and I was incredibly excited for it in the broader context of the .NET ecosystem. A big part of the appeal of .NET is excellent developer tooling, but all too often that's been lacking for developers who stray from Windows+Visual Studio. This was going to be a flagship developer experience feature that I could get other, newer .NET developers excited about.

This seems like a short-sighted decision that will harm the .NET ecosystem in the long run. I can only assume this decision is being made by people outside of the .NET team, and I hope they're willing to reconsider the decision.

A former PM for F# said it better than I could:

It’s disappointing to see dotnet watch have the existing support it’s had for a long time now get dropped. It worked very well. Furthermore, it offered a credible .NET version of the kinds of things you see in other ecosystems (vercel/nextjs, reactjs, etc.) that are all delivered via a package manager. It’s even more disappointing looking at the source code to see that support for it was ~1-2k lines of code, and that code has now been ripped out at the last moment.

Orthogonality and cross-platform always wins in the end. The .NET team understands this. This is a clear backslide, especially because hot reload did not start out as being only for Visual Studio. I really hope this isn’t the start of a pattern.

In the meantime, the most productive development stack for me is nextjs with vercel, where I get seamless UI and sever-side hot reloading capabilities all delivered in a single NPM package. Hot reloading isn’t special anymore, it’s table stakes for modern app development. I hope the folks making these last-minute decisions realize that soon.

[Atulin]

Hiding it behind a flag and even dropping some "this feature is unfinished and might be unstable" warning in bold red letters into the console when the user runs it does seem preferable over a complete removal.

Especially since the response quoted above doesn't instil confidence in the feature ever coming back to anything but Visual Studio once it's removed.

[Cheeseless]

This comment seems especially ominous, even if the following one seems to contradict it somewhat. dotnet watch being put on the shelf is just as bad as having Hot Reload removed as a single incident.

[Atulin]

The comment does read as if there are plans, or at least talks, about deprecating dotnet watch altogether and locking the entirety of its functionality behind Visual Studio, indeed...

[qcc-na]

Microsoft does not want you to use .NET or RIDER that's why.

Edit: Or emacs, vim, vs code, or any other editor that works with Microsoft's own Language Server Protocol. If you use any of these on any operating system, you are a second class citizen now.

[KieranDevvs]

To outright remove the feature rather than put it in preview and make the user opt-in, really does make it seem like a conspiracy. You have System.CommandLine in beta (https://github.com/dotnet/command-line-api/releases) for two years encounting and yet you decide to remove existing and functioning features, rather than delaying them, for what? Its an anti-pattern, you want visual studio to use the CLI rather than VS use its own implementation.

I think the work had already been completed by the dev team and now management have seen an opportunity to capitalise on Visual Studio licence exclusivity so enterprises dont flock to Rider / VS Code, so it's not just been cut from this release, but cut forever.

Just look at the management decisions in Windows 11 (granted, I know this is isn't related to .NET but it illustrates the MS management mentality), Ads in the start menu... At least try and pretend you respect your customers.

[Kryptos-FR]

@LyalinDotCom was kind enough to clarify on Twitter (and to be clear, I do appreciate it; please don't shoot the messenger):

Sorry for any confusion. To clarify, given the number of scenarios we are working on, we had to prioritize :(. As a result, Hot Reload will not release as a feature of dotnet watch tool. We are doubling down on VS 2022 with support for VS4Mac coming later

First the .NET Foundation fiasco, now this. Someone at Microsoft wants to kill the Foundation.

I don't care that they have to prioritize it internally. The SDK repo and all other .NET Foundation repos are supposed to be open-source, developed in the open and with the community involvement. There should have been an open discussion about it before making that decision behind the scene. The Microsoft's employees could have focused in VS support only while letting the community help for the wider audience support.

If the SDK repo is vendor-focused (here Microsoft) then it shouldn't be part of the foundation organization and moved back to the Microsoft one. After all these years, it appears Microsoft teams still don't understand how open-source works. It's all about communication and community involvement.

There could already be people working on supporting it for other IDE (Rider, VS code). By not involving the community, you saw the branch there were sitting on. Microsoft's backlog of issues shouldn't be the only backlog but a part of a bigger picture. There are a lot of .NET developers out there, some could have ideas to solve some of the general issues. By shielding their team from the outside world, Microsoft is removing any such opportunity. Nobody wants to spend time contributing to a project where the owners can just kill a feature on a whim.

[misyltoad]

If Microsoft had nothing to hide, they wouldn't pre-emptively lock the PR which does it #22217

Pretty sad and pathetic tbh.

But hey, Microsoft ❤️ Open Source