Communicate plans with the community about the future of .NET debugging and feedback loops (Removal of dotnet watch?)

https://github.com/dotnet/sdk/issues/22247 already gained a lot of traffic and asks the question why hot reload is only supported for VS. Discussions about this should take place there.

This issue is about a perhaps even more concerning subject. The possible removal of dotnet watch according to this comment: https://github.com/dotnet/sdk/pull/22217#discussion_r733047263

This was mentioned in !22247 here: https://github.com/dotnet/sdk/issues/22247#issuecomment-949046711.

If Microsoft plans to only support hot reload in their own systems like VS and VS4Mac, there will probably be a lot of dissapointment.

But if Microsoft also plans to entirely remove dotnet watch, I think this will be suicide for this new “Microsoft ❤️ open source” image and the image of this new .NET ecosystem. You will force people to stop their program, rebuild it and then run dotnet run again?

I thought it was important to create an issue for this so this doesn’t fly under the radar.

Please communicate your plans about the future of .NET development, debugging and the feedback loops we as developers can expect during development. Is Microsoft’s plan to cripple the productivity of all .NET development that doesn’t take place in VS(4MAC)? Why?

[sander1095]

That does not answer the question about the future plans for dotnet watch. This issue should at least receive a comment from MS

[revuniversal]

It’s been 2 days since this issue was opened. I wouldn’t assume bad faith this early; it’s not constructive.

I don’t think it’s an assumption at this point. MS has demonstrated that the core developer feedback loop is subject to any changes they deem necessary–even if it violates their own support policies and covenants they’ve forged with the community.

They’ve also demonstrated that direct, honest communication on these matters is disallowed by policy.

They lost the benefit of the doubt when they removed tooling without community input. They did further damage to their credibility when they tried to spin it as “Oops! We didn’t mean to remove all that code” as if the number of deleted lines was a primary concern.

Six months ago, I’d need more evidence to believe they’re acting in bad faith, but they have given sufficient cause to shift the burden of proof to them. There has been a pattern of behavior that indicates that they have pivoted from a strategy of maintaining an open dotnet ecosystem to one of maintaining the appearance of an open dotnet ecosystem.

Something needs to change in the governance of dotnet to convince me that its future is safe from the whims of an out of touch management structure.