.NET Hot Reload Support via CLI

Scott Hunter [MSFT]

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! 🙏


Discussion is closed. Login to edit/delete existing comments.

  • Alex Lambert 0

    Thanks so much for everyone in the .NET team who made it possible to bring this back.
    But why are you not open about that the removal was a management decision (against the will of .NET developers) not a technical decision or where the articles wrong?

    • Someone 0

      Management guys should be fired because of doing bad decisions which makes damage to community, ecosystem and Microsoft company itself.

      • Bjarke Sporring 0

        I disagree. If you fire people for bad decisions you’ll quickly run out of people to hire. Life is a learning process and everyone should have the opportunity to fuck up. Defaulting to “fire that guy!” is toxic.

        • Kirk Wood 0

          For line level you would be right. But this was an executive decision and the lack of accountability has far too long been a problem. An executive should step forward and be fired. Not quit – be fired. Executive’s boss should follow with an announcement that they are transitioning out.

  • Kexy Biscuit 0

    Good to hear this!

    • Przemysław Kamiński 0

      Good decision cause VS is a garbage you do any git operation and it’s freezed. Much better option is rider. I believe that code will soon be better 😂🤣

      • Maximilien Noal 0

        That’s weird, in my experience VS doesn’t freeze at all and is way better than any alternative.

      • Vaclav Elias 0

        I have been using Visual Studio for 15+ years and I am pretty much happy with VS, including happy with 2019 and 2022.

      • Jorge Morales Vidal 0

        I’ve been using the Git Tools in Visual Studio 2019 since their introduction last year and it works flawlessly. If Rider works for you, that’s fine. You’re free to choose whatever works best for you.

  • Filip Navara 0

    Fine, that’s damage control over dotnet watch. What are you going to change to prevent this from happening again? Mind you, the community loves .NET and incidents like this erode trust. It drives people away from .NET and hurts Microsoft’s bottom line too. This time there was enough people to make uproar, next time there may not be.

    • Eric Pellegrini 0

      It seems like the most important thing to do is listen and respond to the community. Which is the core of what solved the issue before it was even released. Sounds like how this should work.

      • Allan Lindqvist 0

        i get what you’re saying but consider this: Is removing a feature in the RC phase without even talking to the community and locking the PR “listening to the community”?

        sure, i agree that its good that they listened and put it back, but the problem is that it happened in the first place.. i think anyone will be hard pressed to find a member of the community saying “please remove this existing functionality from the cli and make it VS only”

        • Andries Spies 0

          there are in actual fact 2 “communities” here:

          1. The public community
          2. The corporate Microsoft Team.
    • Someone 0

      @Filip Navara: You are right.

  • Georg Dangl 0

    Great write up, thank you for sharing! This was a good demonstration of the open source idea – the problem was acknowledged and feedback was quickly addressed.

  • Reuben Swartz 0

    Thanks for listening we appreciate it.

  • Cory Crooks 0

    we inadvertently ended up deleting the source code instead of just not invoking that code path

    Does that mean the code will be there, but still not available for use from the command line?

    Like others, I agree this blog post was addressing a symptom, and not the real issue. Who made this (from the outside looking in, obvious business) decision, and why did they make it? Can you address the feeling now that .NET is “fully supported cross-platform, as long as that platform is Windows”

    I see no mention here about steps taken to ensure this won’t happen again, which make me personally think someone higher up intends to try and make it (or something like it) happen again.

    • anonymous 0

      this comment has been deleted.

  • Rutger Storm 0

    I feel this blog post is mostly about doing damage control than being totally sincere. You try to make it seem that the source code was deleted by accident, but as we learned from inside sources etc. A lot of internal employees did not agree with the decision in the first place. I am happy that it got added back but lying about how it happened and keeping a hand above the responsible person head leaves a bad taste. What is going to prevent from that person trying to force his or her decision in the future?

  • Nikolai Bjørndalseter 0

    Thank you, it’s nice to get some clarification on this. Although, there are still questions left unanswered. To quote: We are always listening to our customers’ feedback to deliver on their needs. Why then, was the decision and the following pull request not open for discussion (locked to collaborators), and as others here mention, what was the driving factor behind this change? Management or technical? Economical, or good intentions? The original PR was rapidly merged in RC 2 of the upcoming GA, going against your own OSS policies. Some degree of trust has been lost here, maybe permanently for many.

  • Allan Lindqvist 0

    While this is great news, I think alot of damage has already been done by this even happening in the first place.
    There are also some things that are not addressed very well imo:

    So you’re saying removing the code from the cli was a mistake? What about the blog post detailing these changes? it feels like a lot more than a persons finger slipped and they accidentally hit delete. Why was the PR locked? Do you mean this was a lapse in judgement by management? Was it a miscommunication? if this was just a simple mistake why did it take so long to respond? Just calling it a “mistake” is a little opaque. Microsoft has to be way more transparent to repair the damage in trust this move has made.

    What about dotnet watch? a person on the team (i believe) said it will not receive any new features, is this also a mistake in the sense that they misspoke? was that the plan and now its not anymore? is the plan still to not add features to dotnet watch?

    There has been rumors floating around about internal struggles with regards to VS features and .net sdk features. you’re not denying this in this post.. please address these as well, Is Microsoft, or some parts of Microsoft trying to make visual studio a more first class citizen in the .net eco system at the expense of other platforms? Saying “we want to make sure VS delivers the best experience for .NET 6.” will not reassure people who worry every other platform is second class

    I can absolutely understand that scope can get away from you and some features may need to be pushed, but then why not just say “dotnet watch will get hot reload in a sdk update post 6 RTM”

    Alot of people are like “so what” about this, but years of trust and advocacy only take a single blogpost to destroy, you have to be aware of the legacy perception that microsoft still has. People on outside or on the edge of the ecosystem will take this in when choosing the stack for upcoming projects and tipping things over for these people wont take a lot. This has real implications on peoples careers and professional reputation

    “I thought you said microsoft had changed?” will be a discussion that many of us will have because of this. At least give us the full and honest story.

    • Mark Murphy 0

      I think Allan you have made some very good points. As a startup founder with a tech strategy based on .NET due to Microsoft’s compelling multi-platform & open-source vision, I have been a bit unnerved by what happened here. I definitely don’t want to be locked into Visual Studio because I chose .NET….

    • Shawn Mclean 0

      Well said.

      I was senior eng in .net and went into node/go for their OSS nature.

      I’m building my startup on the node/go/aws stack.

      However, I’m always keeping an eye out for a reason to go back, as we have a lot of Microsoft connections and knowledge of the dev ecosystem. If my company is successful, then we create a demand for .net developers and for us to contribute back into that ecosystem with tooling, etc.

      But seeing one of the reasons why I left actually played out makes it hard to return. A company open sourcing tools that may compete with their paid products is asking for trouble. For a company as big as MS, OSS dev ecosystem is a huge play, one that turned the company around. But at the level of product organizations, such as visual studio, where their metrics will compete against the OSS tool they own, human nature is to sabotage the competitor, right?

    • Martin H. Andersen 0

      You nailed it. Very good sum up.

      As I wrote on Github I was VERY disappointed. Have been working with hot-reload in Flutter and was really looking forward to having this in Blazor WASM.

      But I think the decision was made because of blurred lines between tooling and features in a SDK.

      Should scaffolding be part of the sdk? Should hot-reload? Someone saw a chance to add a killer feature to VS. But way too late in the process.

      After so many community videos demonstration hot-reload no one can take it away,

    • Joren Thijs 0

      Well said!

      This is not a good look and erodes much hard earned trust.
      Second the rumors around dotnet watch make me less enthusiastic about dotnet 6 and straight up scared about the roadmap for dotnet 7

  • Paul Quinn 0

    I mean, this (of course!) is positive. Yet also not really making sense.

    Even if the decision was made not to invoke the code path, that decision would have only have been put in place post RC1 (breaking the production-ready contract with the community), without the involvement of the community (again, breaking that contract).

    It hs been discussed on this very blog mechanisms which are being put in place to demark features as being in preview. And/or kicked to v7. Neither of these were also apparently an option.

    It stinks. And I don’t believe MS is willingly this incompetent.
    a) can you state why this won’t happen again? I honestly don’t think being taken on trust is the mood of the community
    b) what is the overall commitment here to the restated feature? Can you honesty say it’ll be developed collaboratively without prejudice in future (for Rider etc to use effectivly)?
    c) part of the draw of the new dotnet was both its openness and it’s cross platform nature. Are you committed to providing the same tooling fundementals on other platforms (so that 3rd parties can provide a 1st class development tools on these platforms), or is the future intent to gate those?
    d) the way this reads is that dotnet has a core dependency on VS. If VS wasn’t ready, support in dotnet had to pulled. Shouldn’t this dependency be the other way round? If you’re really saying this is correct then maybe be more open with the community about the VS road map, what these (still making no sense) dependencies are?

    I know you all know someone has messed up and has destroyed a lot of good will and positivity on where this release should have taken us. I can believe you’ve flubbed this launch window… no blood letting, but, let’s be honestly about why this happened and what needs to change.

    • wilton lazary 0

      Very sad to see that the “embrace then extinguish” will always be around.

Feedback usabilla icon