Happy ... Tuesday? It's been quite an interesting week. We have one thing to discuss, and then straight to the links.

• .NET Open Source: Who does Microsoft want to be?
• Last week in the .NET world

.NET Open Source: Who does Microsoft want to be?

To put it lightly, last week was a very eventful week for the .NET community. I'd like to talk about what happened, what we learned, and what it means for .NET open source.

Before diving in, I want to say that I am voicing my opinions only and my intent is not to "create more drama" or keep harping on about past events. While Microsoft resolved the current issue a few days ago, I often find that I can view events with better clarity after spending a few days stepping back and thinking about it. You might agree with what I have to say, think I'm blowing it out of proportion, or somewhere in between. I expect that.

What happened? If you've been subscribed here for the last few months, you know that one of the core objectives of .NET 6 is to improve the "inner development loop" for the .NET platform. The core feature is the "Hot Reload" functionality, which allows developers to see changes applied instantly while running their application. Already viewed as table stakes for modern web application development—front-end developers have enjoyed this capability for many years—it's finally making its way to the .NET platform. As the .NET team is trying to embrace new developers or developers from other platforms, it's a key selling point. If you try to get React or Angular developers to consider something like Blazor, and they learn it isn't available out of the box, you'll likely get a "Seriously?" Once you have it, you can't live without it.

Anyway, Hot Reload was announced and then rolled out in .NET 6 Preview 3, and I wrote about it in detail all the way back in April. At the time, it was rolled out in the .NET CLI via dotnet watch as a lot of new features are. Eventually, Microsoft said, it would make its way to Visual Studio or whatever tool you enjoy—but since it resides in the core SDK, you could use it across a wide variety of environments and platforms. It worked well and as a whole, the community was thrilled. Right around the time .NET 6 RC 2 was released last week—the last "preview" release that ships with a go-live production license—Microsoft decided to scrap it from dotnet watch and only make it available for Visual Studio 2022 "so we can focus on providing the best experiences to the most users" so long as you enjoy Visual Studio on Windows. As if it wasn't abundantly clear, .NET engineers leaked to The Verge that this was a business decision made at the CVP level.

After a ton of almost universal backlash, the capability was restored to dotnet watch, in a blog post whose only strength was providing political cover and delivered on none of what we all wanted: being honest, authentic, or transparent with the community.

I don't think anyone is confusing a trillion-dollar corporation for being a charitable organization. And it is true that a majority of .NET developers are on Visual Studio. If Microsoft decided to make this a Visual Studio feature from the beginning, the pushback would be minimal.

The deserved furor comes from Microsoft ripping out a core feature right before completing a release and done with a PR that was closed to community feedback. This all feels like we got transported to Ballmer-esque Microsoft, and not the "new Microsoft" that appears to be less concerned with sticking you to specific tooling but doing all it can to meet you where you are, so long as you deploy your workloads to Azure.

With the popularity of Visual Studio Code and the emergence of wonderful competitive tools like JetBrains Rider, Microsoft is at odds with being open in the name of that fat Azure cash or being protective of pricey enterprise licensing with Visual Studio. This week highlighted their conflict of interest and desire to have their cake and eat it, too.

We've been slowly reaching a breaking point. Over the last few years, Microsoft restricted debugger licensing, the abandonment of MonoDevelop, and now we have the hot reload controversy. Include the .NET Foundation issues, and Microsoft's "open-source friendly" reputation has taken its hits. The common logic is that while Visual Studio is a moneymaker, for sure, it's a rounding error compared to Azure, so it's good business sense for Microsoft to shed its protectionism in favor of inclusiveness and community goodwill.

Of course, none of this criticism should take away from the amazing work the .NET team has done for both their platform and open source. As a matter of fact, that team is likely the most upset here as a decision out of control has hurt their reputation with the community. But where does .NET fit? For me, it begs the question about how Microsoft views .NET: is it an open, innovative platform that drives Azure investment, or a piggy bank that Microsoft executives can shake until every last penny comes out?

To Microsoft's credit, they should be commended for writing their wrongs so quickly. They listened and reacted, and pushed out an apology in just a few days—an amazing feat at a trillion-dollar company with many layers of top-down management. All in all, I think last week was a wonderful testament to the true value of community, where a group of devoted people can help drive change (or undo unfortunate decisions).

However, the apology post is littered with inconsistencies and seems to be protecting senior management's decisions and not their reputation with the community.

The post explains that: "In our effort to scope, we inadvertently ended up deleting the source code instead of just not invoking that code path." In my opinion, this wasn't an engineer running the wrong command, but trying to make a last-minute change at the demands of their management and closing the PR for comments. While reading the post, I couldn't help but feel how it contradicted this new open Microsoft—build what you want, on any platform you want, so long as you use Azure—and reeked of the political cover and protectionism that defined its past.

Where do we go from here? Is this a team hitting some bumps with a recent reorg, or a sign of things to come? Have the higher-ups at Microsoft learned their lessons, or is this the beginning of protecting the most coveted SDK features to their exclusive tooling? And most importantly, how will Microsoft balance conflicts of interest with all their tooling choices? As Visual Studio Code is an amazing editor, as Dustin Gorski and others have wondered aloud, isn't it strange that Microsoft's own .NET platform is one of the worst supported platforms on Code?

If Microsoft wants to be honest with its community, it needs to answer: What do you want .NET to be? To keep it an open, open-source friendly platform, or to make it a piggy bank? It appears to be that Microsoft wants it both ways and risks harming its reputation with the community while promising openness.

We know Microsoft will never have a perfect relationship with its developer community. At the end of the day, their responsibilities are to their shareholders. With that said, I have all the faith in the world in the .NET team. I admire them and all the work they have done on the .NET platform. I hope the team aligns with their management and can eventually be transparent with the community about what they truly want .NET to be—no BS, no corporate-speak.

🌎 Last week in the .NET world

📢 Announcements

• Emily Stoll writes about Visual Studio 2022 UI updates.
• Dmitry Lyalin provides an update on .NET Hot Reload.
• Microsoft introduces vscode.dev.
• Paul Thurrott writes about Microsoft deprecating UWP.
• Kathleen Dollard writes about what's new in F# 6.
• Microsoft releases Windows Terminal Preview 1.12.
• Rachel Appel writes about various updates in Rider 2021.3.

📅 Community and events

• Help decide what questions to answer at the .NET Foundation's next meeting.
• The Uno Blog writes about recent UWP & .NET 5, .NET 6 news and Uno Platform plans.
• Matthew MacDonald writes about lessons learned from dying frameworks.
• Sergey Tihon announces the 2021 F# advent calendar.

🌎 Web development

• Richard MacManus writes about the growth of PWAs.
• The Microsoft Edge Blog writes about the improved authoring and debugging experiences in Microsoft Edge DevTools and Visual Studio Code.
• Davide Bellone writes about pinging endpoints.
• Imar Spaanjars writes about improving your ASP.NET Core site's file handling capabilities.
• David Ramel writes about native dependencies with Blazor WebAssembly.
• Chris Coyier writes about the supports() CSS selector.

🥅 The .NET platform

• Matthew Jones uses LINQ OrDefault() overloads in .NET 6.
• Andrew Lock supports integration tests with WebApplicationFactory in .NET 6.

📔 Languages

• Dave Brock writes about using global declarations in C# 10.
• Khalid Abuhakmeh uses C# to bulk insert records into SQLLite.
• Jorge Levy writes about using Azure Functions with .NET 5.
• Thomas Claudius Huber talks about extended property patterns in C# 10.
• Muhammed Saleem uses IAsyncEnumerable with yield in C#.
• David McCarter writes about collection type performance in C#.

🔧 Tools

• Thomas Scott talks about JetBrains Git plugins.
• Andrea Chiarelli explores the Auth0 ASP.NET Core Authentication SDK.

🏗 Design, testing, and best practices

• Zaher Talab provides API testing tips.
• Derek Comartin writes about leaking value objects from your domain.
• Sam Milbrath writes about managing your energy.
• The Overflow Blog writes about code quality.
• The Stackify Blog discusses top .NET developer skills.
• Oren Eini tracks down a sticky bug.
• Joana Carvalho writes about full-stack observability essentials.
• Peter Vogel unit tests Azure Functions.
• Dennis Doomen writes about his 17 laws of TDD.

🎤 Podcasts

• The .NET Podcast talks about clean code in C#.
• Merge Conflict writes about .NET 6 and C# 10.
• Adventures in .NET talks to Dennis Doomen about Fluent Assertions.
• The Overflow talks about code quality.
• The 6-Figure Developer Podcast talks to Mads Kristensen about Visual Studio 2022.

🎥 Videos

• The ASP.NET Monsters talk about improved .NET 6 LINQ methods.
• Cecil Phillip walks through Dapr.