.NET Hot Reload Support via CLI
Last week, our blog post and the removal of the Hot Reload capability from the .NET SDK repo led to a lot of feedback from the community.
First and foremost, we want to apologize. We made a mistake in executing on our decision and took longer than expected to respond back to the community. We have approved the pull request to re-enable this code path and it will be in the GA build of the .NET 6 SDK.
As a team, we are committed to .NET being an open platform and doing our development in the open. The very fact that we decided to adopt an open posture by default from the start for developing the Hot Reload feature is a testament to that. That said, like any development team, from time to time we have to look at quality, time, resources to make tradeoffs while continuing to make forward progress. The vast majority of the .NET developers are using Visual Studio, and we want to make sure VS delivers the best experience for .NET 6.
With the runway getting short for the .NET 6 release and Visual Studio 2022, we chose to focus on bringing Hot Reload to VS2022 first. We made a mistake in executing on this plan in the way it was carried out. In our effort to scope, we inadvertently ended up deleting the source code instead of just not invoking that code path. We underestimated the number of developers that are dependent upon this capability in their environments across scenarios, and how the CLI was being used alongside Visual Studio to drive inner loop productivity by many.
We are always listening to our customers’ feedback to deliver on their needs. Thank you for making your feedback heard. We are sorry that we made so many community members upset via this change across many parameters including timing and execution.
Our desire is to create an open and vibrant ecosystem for .NET. As is true with many companies, we are learning to balance the needs of OSS community and being a corporate sponsor for .NET. Sometimes we don’t get it right. When we don’t, the best we can do is learn from our mistakes and be better moving forward.
Thank you for all of your feedback and your contributions over the years. We are committed to developing .NET in the open and look forward to continuing to work closely with the community.
Thank you! 🙏
Light
Dark
60 comments
There is no decision in the world that satisfies everyone.
However, we want you to at least engage the community when making decisions for MS.
In my opinion, there seems to be no significant decision maker representing the will of the community, and this seems to be the problem with creating the .NET ecosystem.
But anyway, the good news is that the mistake was acknowledged and corrected.
And we know that Microsoft is the biggest contributor to the .NET ecosystem. good luck
I am working with MS tech more than 15 years from vb6, asp, webform, winform, mvc, core, xamarin. since last two years we decided to move another tech like react, react-native, one project with node.
I think there is no future in winform, xamarin, maui, blazor. we are stuck with windows os. Only asp .net core is trustable product in ms.
Pure damage control. First time i can think of .NET leaving a bad taste in my mouth!!! (Unless you want to talk about the renaming of ATLAS…) Just be truthful about who made this decision! This is the kind of thing that will reverse all of the OSS trust and momentum that you have going for you.
Thank you for listening to the community, but there seem to be some fundamental issues over and above what happened, that I think should trigger some introspection internally.
Otherwise, this is a welcome change, and I sympathize with being caught in the difficult position between the needs of the community and those of the business!
Then why was the PR locked within one minute after creation? That was planned action and nothing else.
I really don’t understand a few point :
– We know for a long time even last year that Hot reload will still have bug and missing feature in .Net 6. I can’t find reason to take a U turn like you do.
– You say you “Underestimate” the impact of removing it. How can you have underestimate such a big feature. All i read all this year show me that you are not that unreponsable.
– How can you remove a big feature after RC1 ? When any other team doing so would be a huge fact.
– Why visual studio 2022 doesn’t use the feature to enable Hot reload ? Why do you have to do work specific for them.
– What is the plan to avoid this to happen again
– It’s really not the good time with all the problem expose in dotnet foundation https://github.com/dotnet-foundation/Home/discussions/39
– May i talk about the support of VS2019. Why no support at all we don’t ask for new feature just build and debug ? If you want to make VS first class citizen why di you make it so hard to use VS. It
I start to thinks i should stop using VS because it feel like encouraging you to do this.
Awesome!
Allow me to be more blunt and direct than most comments here:
I love to hobby-code in F#, and implicitly in .Net, but my day job is in Scala (and Python, yikes).
Now, personally, I find the .Net ecosystem to be much better than Scala/JVM’s. The community is better by far, miles ahead of the Scala’s.
However, pulling this kind of BS – removing a core, super-wanted, feature from the RC, an RC many in the community contributed to, due to a management decision aimed at maximizing M$ profits, not because of an engineering problem, and then lying about it, like you do in this post…
Well, if M$ wants .Net to revert to its “only for a single platform, ours, Windows” roots, with all that that implies… well, that’s M$’s call, I guess.
But don’t be surprised if it hurts M$ bottom line, in the long run.
The thing is, we do have options.
And those options are also evolving, much like M$’s offerings.
And those options are multi-platform by default, always have been.
And they have their own share of bells and whistles.
Sure, moving over will hurt.
It will take time and adjustments.
It will NOT be easy.
But it CAN be done.
If M$ wants to keep the multi-platform, OSS community it has painstakingly amassed over the last few years it needs to stop playing games with us.
That also means, BTW, stop punishing M$ employees who contribute and better OmniSharp, the multi-platform .Net SDK, that’s being starved, on purpose.
M$, needs to make up its mind: does it love OSS and multi-platform, or does it push for a closed-garden, Windows-only platform like you were before.
And once M$’s mind has been made up, it needs to let us, the community, know it and don’t lie about it.
Own the decision.
Even if it hurts the bottom line.
This deal with the hot reload was strike one, issued by the community.
Personally, I feel OmniSharp is strike “one and a half”.
Does M$ really want to strike out with the community?!
If your goal was to apologise and retain and/or re-earn the trust of the community, this post should have been direct, honest, and truthful, and you blew it.
Mischaracterising the removal of the feature as “inadvertent” and that you somehow “ended up” deleting source code is just yet another insult to the community.
The removal of 2,560 lines of code is a deliberate act. The deletion of source code is quite obviously reflected in the diff. The review process was followed as per normal, with another MS employee reviewing the code, asking questions, and ultimately approving the removal. About the only thing non-standard was the immediate locking of the PR to prevent community feedback and criticism and review, something which could have perhaps avoided the situation altogether.
And in a blog post where you outright admit that you deleted rather than disabled a code path (however you try to spin it), you contradict your own apology and mischaracterise the community-lead PR that restores it as the “enabling of a code path”.
If you truly believe the PR process was not satisfactory and lead to “inadvertent” code change, what does that mean for your platform and SDLC as a whole and what are you going to do to rectify it? And what of immediately locking & limiting the scope of PRs to prevent community involvement, will there be a policy to address this?
There is absolutely no way this is an accurate description of what just happened. Presumably “Inadvertently deleted” is chosen to be so obviously risible that you’re effectively winking at us out of sight of your boss.
The most depressing aspect of corporate life is that it rewards such dishonesty.