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.

[Joshua-Ashton]

If Microsoft had nothing to hide, they wouldn't pre-emptively lock the PR which does it https://github.com/dotnet/sdk/pull/22217

Pretty sad and pathetic tbh.

But hey, Microsoft :heart: Open Source

[thorpj]

To add to the discussion, hot reload in VS22 does not work with Blazor Webassembly Hosted.

So CLI actually has a feature that VS22 hot reload doesn't, and now my team cannot use hot reload (which is one of the major reasons for choosing .NET for this project).

And of course, we don't all use VS. There are far better IDEs, and this is not how you make yours the most compelling.

Reverse this decision Microsoft. Reverse it now.

[MatthewKing]

Decisions like this really erode trust in the platform. Please reconsider this.

[supertr0n]

In my experience with Blazor (Server) so far, this feature was working exceptionally well and significantly decreased the dev loop time.

Dropping it completely makes very little sense to me (without visibility of the reasoning behind it) and so close to the release of .NET 6 too.

This feature has been talked about for a long time, and .NET had been lagging behind other frameworks' hot reload capabilities for years. So this really feels like a lose-lose for the platform and for all of us already using it.

Notwithstanding all the other great work the .NET team has been doing, this decision is really disappointing.

[mducharm]

Well, this deflates a lot of my excitement about .NET 6 and the future of C# development. The support for CLI-driven workflows is something I love about .NET Core and above; whether I'm building a quick console app with VSCode or something more involved in Visual Studio, I loved that I could think of everything in terms of dotnet commands. But the long-term implications of this are concerning.

[onionhammer]

This definitely should be behind a flag or a very good explanation should be written up for why it needed to be removed.

[crozone]

Decisions like this really erode trust in the platform. Please reconsider this.

It's possible that there are sensible engineering justifications for this change, however the complete lack of communication is alarming, especially considering the discussion was insta-locked on the PR.

This doesn't just erode my trust in the platform, it erodes my trust in the entire .NET foundation. If MS are willing to push PRs which cut features at the drop of a hat, without any community engagement, ostensibly to force people to use their other proprietary paid products, they're not exactly ♥ing open source, are they?

[raaffaaeell]

As someone that works mostly using Linux (backend), moves like these do not bold well to the future. Not only keeping it behind their own IDE (making it even less interesting vscode for c#), but stripping the last bit that made this new feature cross platform.

Also, from their messages, it seems that they arent even considering revisiting this decision in the future.

A sad day for the .Net ecosystem and I hope they reconsider this decision.

[bwong365]

Was super excited to see .net moving in a great trajectory until this. I hope the team reconsiders, otherwise there's always going to be some level of suspicion now, especially when combined with the wix toolset mess.

[kensykora]

As someone who's bought 100% into WSL2, this is hugely disappointing. The momentum to support VSCode with C# workflows and the promise this had, this is a mistake to put it behind Visual Studio

[francofgp]

I think we all lost something today

[3nprob]

There is a PR for reverting the change in #22262

[ShreyasJejurkar]

This literally halved my excitement about .NET 6 and hot reload in general.

ping me when .NET 7 arrives

Edit - Jetbrains Rider just added support for Hot reloads to their EAP. https://twitter.com/JetBrainsRider/status/1451555367117275163

And also one more thing EAP builds are free until the final release happens! So enjoy!

[Je12emy]

Looks like MS just doesn't care about it's community... :/

[larsw]

I left for Kotlin/JVM and the Spring ecosystem.

[AKruimink]

As a Linux user that is required/forced to use other editors then Visuals Studio (VS-Code and Rider), it's rather sad seeing features like these being locked away to garner some sort of exclusivity, i agree that this is is a big step backwards and hope this will be reconsidered.

[christiansparre]

Very sad to see such a useful feature make it so far, only to be ripped out just "days" before GA. We had begun relying on this feature for greatly improved Blazor development flow. We use Visual Studio, but rely on dotnet watch A LOT, and it works a lot better than Ctrl+F5 I think 🤷‍♂️

This will likely push us away from Blazor I'm afraid, and I will have a very hard time justifying investment in Blazor over other frameworks if hot reload is missing from dotnet watch. One of the selling points of Blazor right now was that hot reload was part of .NET 6 and we could move forward with that choice.

How do Microsoft expect us to just wait another year when this feature have been part of the RC's!? I'm really disappointed!

[Atulin]

I left for Kotlin/JVM and the Spring ecosystem.

Personally, looking into Elixir. always wanted to learn functional programming.

[Martin-Andersen]

This was the only thing I was looking forward to. In my company we has chosen Blazor WASM for all applications and hot reload would have help me save a lot of time. I am working on a Mac using Rider so please please reconsider your decision.

SO many frameworks has hot reload, you can't jump ship now

[lukblazewicz]

Although we develop a Blazor Server Side app on Windows using mostly Visual Studio, I vastly preferred running hot reload via dotnet watch as it seemed way more stable than its VS counterpart. The general UX was also way more pleasant.

Shocking move, to be honest. Especially taking into consideration how buggy VS 2022 currently is.

Reconsider this, please.

[alexyakunin]

Same for us. We're on Windows, but using Rider - and IMO hot reload support in CLI is a must-have thing.

Once I read the news, I've instantly got a feeling that Microsoft from Y2K is coming back. And no, it wasn't good at all.

[anddrzejb]

Reading through all the comments it is clear that everyone prefers even the occasionally failing hot reload in dotnet watch than lack of it. I also do believe it should be kept, at least as a preview. I mostly use it for blazor (I work a lot with one of the largest component libraries for blazor), and as others, even though I work with VS 2022, I constantly have dotnet watch on. Hot relaod IS invaluable.

[Yanitrix]

So I guess.. it's gonna be back again?

[crozone]

So I guess.. it's back again?

🔥🔥🔥

[filipnavara]

I agree with most of the comments above. This eroded my trust to the point where I am reconsidering whether to spend any more time to contribute to .NET.

My team is working with Visual Studio, Visual Studio for Mac and VS Code. The Microsoft team working on VS4Mac is seriously underfunded and features like support for .NET 6 arrive late and often there's too many bugs for us to use it. If we want to develop with the bleeding edge bits we need to use the CLI and VS Code simply because there's nothing else available. Taking features away from it seriously hinders our development flow.

[KalleOlaviNiemitalo]

So I guess.. it's gonna be back again?

Anyone can approve pull requests… for now.

[3nprob]

4h later and #22262 is now the most :+1: 'd issue/PR in this repo ever.

[kevingosse]

I do not want to derail the topic (full disclosure: I don't use hot reload), but there's also something else bothering me in the matter: RC1 was advertised as "go live" and "supported for production": https://devblogs.microsoft.com/dotnet/announcing-net-6-release-candidate-1/ How is it even possible to remove a feature from a release candidate? What is the meaning of RC for Microsoft if major features can still be removed?

[KieranDevvs]

I do not want to derail the topic (full disclosure: I don't use hot reload), but there's also something else bothering me in the matter: RC1 was advertised as "go live" and "supported for production": https://devblogs.microsoft.com/dotnet/announcing-net-6-release-candidate-1/ How is it even possible to remove a feature from a release candidate? What is the meaning of RC for Microsoft if major features can still be removed?

I didnt even think of this, it makes it so much worse.

[GlebChili]

One can say, that features on which hot reload is based on are somewhat public (both in runtime and Roslyn), so folks from JetBrains Rider and VSCode/Omnisharp can develop their own implementation. But there is just a couple of weeks before .NET 6 GA release, no one has enough time to maneuver around it.

It is also worth mentioning that current removal of hot reload from .NET SDK breaks Microsoft own products. For example, it will not be possible to work comfortably with Blazor WebAssembly apps in GitHub Codespaces, which is VS Code based. And GitHub Codespaces allowed me to grab my iPad and try some things with my Blazor app on the run.

[delneg]

And just when I thought "Well, maybe MS is not that bad after all" - they hit us with "IDE no one I know uses - only feature" for hot reloading of all things

[willdean]

What is the meaning of RC for Microsoft if major features can still be removed?

It's just the label for a date on the calendar, really, and .NET Core has been characterized by late changes of direction throughout. The early core days had clearly alpha-grade stuff being called "RC" at some stages. I don't suppose any previous MS project has been less plagued by late changes of direction, it's just that we didn't used to see so much of the sausage-making process.

I suppose a pedant could argue that not all candidates are successful, so a release candidate is no more certain to be released than a presidential candidate is to become president.

This latest spat is clearly just flying shrapnel from some internal bust-up about the current condition of the hot-reload stuff which is as flaky as hell, in both VS and CLI versions. My prediction is that today we'll be told that what was half-done yesterday is now against the laws of physics to complete, but that within a month it will be back on the table after some jostling about who's working on what project on what team for which manager.

[filipnavara]

Your feedback matters In this early preview release, we want to acknowledge that there will be bugs. Sometimes if you try to apply a change it might silently fail, or your app might crash, etc. If you do encounter any problems, please take a moment to report issues to us, as only with your feedback can we ensure that critical problems are resolved, and future decisions are prioritized based on your input.

I'd like to point out this was present in the original blog post on Hot Reload. If you really meant it about the feedback then now it's time to act on it.

[En3Tho]

This is very dissapointing. My whole team is using Rider (simply because it is really much faster, truly cross platform and doesn't hang every 5 seconds for some god only knows reason). Also, like 80% of team is using Linux. This is basically saying "do it manually, waste your time!" to all of them.

[sander1095]

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.

I have created an issue for this: #22265

I would like to ask everyone to give this one a lot of attention too. Only supporting hot reload for VS is one thing, but the possible removal of dotnet watch is another! People will have to go from this process to the other:

now:

• dotnet watch

future:

• dotnet run
• dotnet build
• dotnet run

That's insane!

[cwoodruff]

This just shows there is still a division inside Microsoft around the developer experience of .NET. I am seeing that the VS tooling team is wanting to protect their product from the competition. Hopefully, the .NET team can talk some reason into them to reverse this opinion. Not the best action with all of the issues with the .NET Foundation at the present time.

[filipnavara]

This just shows there is still a division inside Microsoft around the developer experience of .NET. I am seeing that the VS tooling team is wanting to protect their product from the competition. Hopefully, the .NET team can talk some reason into them to reverse this opinion. Not the best action with all of the issues with the .NET Foundation at the present time.

From the outsider viewpoint it certainly looks like that. The way it was communicated left a lot to be desired and I hope that the decision will ultimately be reversed.

Note that the SDK components powering the Hot Reload experience (dotnet/roslyn support of generating Edit and Continue data, dotnet/runtime support for consuming it) are still available and public or semi-public APIs. The glue code in dotnet watch was 2560 lines including documentation and tests. Looking at its history it didn't need significant updates over time to maintain the existing functionality available in .NET preview releases, bulk of the work was done in the other repositories and just consumed as a dependency. If some other IDE, like Rider, wanted to implement the same functionality the maintenance cost would likely not be too high (for current feature set and .NET 6.x, at least). However, some of the interfaces in Roslyn (WatchHotReloadService) are closely tied to dotnet watch and Visual Studio debugger so forking and renaming the code would still be problematic. It would be possible with some friction but ultimately it would depend on the Roslyn not throwing another wrench into it.

I personally don't have problem with Visual Studio specific features that offer an additional value. Neither would I have problem with Microsoft team focusing effort on the VS experience, if communicated properly. Others may have different opinion on that and I want to stress that I certainly welcome efforts toward opening additional parts of the toolchain (more on that below). The proper communication did not happen here. The problem is that they removed an existing feature right before the public release with no prior communication whatsoever. The feature was not some obsolete unmaintained chunk of code, it was working and it was interacting with components that are supposed to be stable since mid-August with no breaking changes happening.

As for the benefits of this work staying in the SDK and open source: I was happy to debug and contribute back to the related closed-source Hot Restart functionality in order to unblock scenarios important for my team. The additional friction by the component being closed source is something I complain about but ultimately understandable business decision. I felt similar pain when MonoDevelop was essentially turned into closed source Visual Studio for Mac. I used to debug some of the big performance issues but now I have to rely on Microsoft doing that for me and the priorities don't always align. In both cases, the developers on the respective teams were helpful and communicative but it's still a process with a lot of friction. Microsoft should realise that these business decisions are negatively affecting even customers of their own products. It's not giving advantage to their tools, it's ultimately a lose-lose situation.

[Kryptos-FR]

@cwoodruff

This just shows there is still a division inside Microsoft around the developer experience of .NET. I am seeing that the VS tooling team is wanting to protect their product from the competition. Hopefully, the .NET team can talk some reason into them to reverse this opinion. Not the best action with all of the issues with the .NET Foundation at the present time.

Exactly why I opened a discussion with the .NET Foundation board of directors. The mentioned PR was locked by the @dotnet admin account which is supposed to be owned by the foundation not by Microsoft. Why woudl Microsoft employees have privileges over that account (while it should instead be overseen by an independent person named by the foundation). If Microsoft doesn't want to have a foundation anymore, they should just tell it and stop wasting everybody's time.

https://github.com/dotnet-foundation/Home/discussions/63

There is a huge governance/conflict of interests issue here.

[willdean]

They clarified in the blog post, dotnet watch isn't going anywhere.

Well, maybe, but there's a follow-up to Dan Roth's comment saying there'll be further clarification about that, and historically MS have often really, really struggled to be straightforward and up-front about tech that they're discontinuing, which is perhaps why people see an exchange like that as concerning.

Things like MFC and Silverlight (and WPF to some extent) spent years in a strange twilight where their demise could only be read between the lines. "Being maintained and used" is not a very high level of corporate enthusiasm - it might mean little more than that someone changes the framework version in the csproj once a year.

[vchirikov]

450+ reactions and 0 MSFT employee in the issue :D I bet that they just won't answer here, that's all. That's "open-source" by MS.