5

.NET Hot Reload Support via CLI

 2 years ago
source link: https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

.NET Hot Reload Support via CLI

Scott

October 23rd, 2021

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!

Scott Hunter

Director Program Management, .NET

Follow

Posted in .NET .NET Core

Read next
Update on .NET Hot Reload progress and Visual Studio 2022 Highlights
.NET Hot Reload progress update. This includes what's new in platform support, user experiences, supported edits and more since our May 2021 blog post. We'll also cover how far we've come with Visual Studio 2022 integration.
What’s new in F# 6
F# 6 is now a release candidate. Checkout all of the new features available in this release.

15 comments

Log in to join the discussion.

  • Alex Lambert

    October 23, 2021 2:27 pm

    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?

  • Kexy Biscuit

    October 23, 2021 2:27 pm

    Good to hear this!

  • Filip Navara

    October 23, 2021 2:35 pm

    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

      October 23, 2021 2:43 pm

      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

        October 23, 2021 3:08 pm

        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”

  • Georg Dangl

    October 23, 2021 2:35 pm

    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

    October 23, 2021 2:36 pm

    Thanks for listening we appreciate it.

  • Cory Crooks

    October 23, 2021 2:41 pm

    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.

  • Rutger Storm

    October 23, 2021 2:46 pm

    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

    October 23, 2021 2:50 pm

    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

    October 23, 2021 2:57 pm

    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

      October 23, 2021 3:47 pm

      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

      October 23, 2021 6:07 pm

      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?

  • Paul Quinn

    October 23, 2021 4:10 pm

    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.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK