Updated Microsoft has enraged the open-source .NET community by removing flagship functionality from open-source .NET to bolster the appeal of Visual Studio, not least against its cross-platform cousin Visual Studio Code.
The two key pieces in this latest unrest are this pull request in the open-source .NET SDK repository on GitHub, in which 2,500 lines of code implementing a feature called Hot Reload are removed from a tool called dotnet watch; and this blog post in which Principal Program Manager Dmitry Lyalin revealed "we’ve decided that starting with the upcoming .NET 6 GA release, we will enable Hot Reload functionality only through Visual Studio 2022."
Hot Reload is a feature whereby developers can modify source code while an application is running, apply the changes, and see the results in the running application. It speeds the development process because it is quicker than rebuilding the code, stopping the application, applying the changes, and then firing it up again.
When Hot Reload was introduced Lyalin said developers could use it through "the .NET Hot Reload experience in Visual Studio 2019 version 16.11 (Preview 1) and through the dotnet watch command-line tooling in .NET 6 (Preview 4)." The feature is in .NET 6 RC2, which has a go-live license, and which was released on October 12 ahead of the launch of .NET 6 planned for November 9 at the online .NET Conf 2021.
The removal of Hot Reload is surprising at this late stage and was greeted with dismay by .NET developers – so much so that a pull request to prevent the change was submitted and rapidly attracted support. "This is the PR that is truly going to decide .NET is really an OSS [open source software project] or not," said one developer.
Why this matters to us all
Why so important? Although Hot Reload is a tooling feature, the implication of the change is that the open-source .NET SDK is being deliberately crippled to seemingly make Visual Studio – which is a commercial product with a cut-down free version – more attractive than rivals, including the Microsoft-sponsored Visual Studio Code. The change was also done without consultation with the community, which seems tone-deaf following the crisis concerning the .NET Foundation which has at its heart the same question: is Microsoft serious about .NET being an open-source platform?
The decision to curb the availability of Hot Reload also seems curious to outsiders. Developer tooling is strategically important to a platform company like Microsoft: simply put, it attracts programmers to the platform. Who can forget Steve Ballmer, former Microsoft CEO, and his cry of "developers, developers, developers"? Laugh we may; yet analyst firm Redmonk founded its business on the "thesis that developers are the new kingmakers."
One business-critical application can drive a large spend on Azure, and Microsoft's cloud is a natural destination for .NET just as Google Cloud benefits from the ad company's status as the inventor of Kubernetes. Visual Studio Code is free but also Microsoft's most successful product ever in the developer community, and strong .NET support in VS Code is of far more potential benefit to Redmond than any slight impact on sales of Visual Studio.
- Amid drama at .NET Foundation, Microsoft's De Icaza reveals it was meant to be like GNOME Foundation
- Microsoft .NET updates include C and C++ code in Blazor WebAssembly, release date for Visual Studio 2022
- Windows terminates here. Please remember to finish setting it up on arrival
- .NET Foundation admits it 'violated the trust of project maintainers'
"Am I understanding this correctly as meaning that the Hot Reload functionality that already works with dotnet watch in .NET 6 previews is being taken away? Right now I can create a .NET console app, run it with dotnet watch, change files and have them be reloaded automatically without an application restart. If that’s going away... oof," said another developer, while a further comment asked: "How can you expect .NET to be a valid solution for cross-platform development if you actively gimp developer experience on platforms other than Windows?"
Another problem with making a key tooling feature exclusive to Visual Studio is that it removes the option from macOS and Linux developers, since Visual Studio is Windows only. Microsoft said the feature is also planned for Visual Studio Mac; but that has tiny usage compared to VS Code.
Microsoft's stated reason, insofar as it has been stated, is that with .NET "the backlog continues to grow," hinting that the problem is lack of resources. Nobody believes this, bearing in mind that Lyalin spends most of his post emphasizing how the team has made excellent progress improving the feature.
On Twitter it was noted that the removal "happened after RC1 and RC2 had been made public ... and after they officially announced that features available in RC1 would be available and supported in final product." Discussion on the notorious .NET SDK pull request was "locked and limited to collaborators," another sign that this is something the IT giant does not want to discuss.
What does the .NET team at Microsoft think about it? The normal evangelists have been quiet on the issue, though Microsoft's well-known and normally ebullient developer advocate Scott Hanselman did post a teardrop last night without stating the reason: who knows, there could be a connection.
Lyalin added and then removed a section headed "Update Oct 21, 2021" to his post, which stated: "To clarify, we are not releasing Hot Reload as a feature of the dotnet watch tool. We are investing all our energy into Visual Studio 2022." We are not sure what to make of the removal of this update, and have also asked Microsoft for further comment. ®
Around about or shortly after this article went live, Lyalin's blog post was updated again to restore the above clarification. And so it stands.
Updated to add
It appears Microsoft has changed its mind in light of the uproar from developers, and Hot Reload isn't being removed from open-source .NET. On Saturday, .NET's director of program management Scott Hunter said:
"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."