My Problem With .NET

Posted on: November 20, 2025

.NET: My 15-Year Itch

During university, I experimented with some languages such as C, Prolog, and Clean, but .NET and C# were my first real experience with professional software engineering. It was with C# that I learned most of the things I know.

And it was great! Before C#, building a graphical application felt really complicated. When 20-year-old me tried Visual Studio for the first time and built a functioning GUI in five minutes, I was sold.

Of course, .NET in 2010 was much different. It was a walled garden: you needed Windows, IIS, MSSQL, and Visual Studio. I was never a Windows fan, but I didn't mind. I was thrilled to be building useful software that real people were using.

The Golden Age of .NET

Fast forward to 2025. With the launch of .NET Core (now just ".NET"), the ecosystem is open-source and multi-platform. A scenario that was unthinkable in 2010 is now the norm. I can develop, debug, and deploy from a MacBook or a FreeBSD server. Microsoft's own Azure infrastructure heavily relies on Linux to run its servers, a testament to this incredible shift.

C# has also evolved beautifully. C# 14 is a different language, allowing for more concise, readable, and functional-oriented code with features like records and minimal APIs.

The performance gains from the old .NET Framework to the latest .NET 10 are staggering. The core team and open-source contributors have done a phenomenal job. The Kestrel web server consistently tops the TechEmpower benchmarks, and the performance gap with low-level languages like C++, and Rust isn't as huge as it used to be.

From a business perspective, the benefits are clear. There's a massive global pool of .NET developers, and powerful tools like Entity Framework (EF) Core dramatically accelerate development. With EF Core, teams get powerful features out-of-the-box, such as object-relational mapping via LINQ, automatic change tracking, and streamlined database migrations.

The Problems

But it's not all rosy. Despite the technical achievements, parts of the .NET ecosystem feel stuck in the past.

Third-Party Library Controversies

The .NET community has been rocked by several controversies around popular open-source libraries.

I don't believe open-source work must be free, but when well-established libraries in the community suddenly pull the rug, it's kinda annoying.

I shouldn't have to be chronically online to know what is going on to every open-source library I decided to use at some point in my life.

In hindsight, these events were a blessing in disguise; I replaced most of them with my own, simpler code and realized they weren't strictly necessary.

Tooling

The tooling, once .NET's greatest strength, now feels outdated. I don't have a comprehensive list of issues, but there are some that I face constantly, like a harmless dotnet build spawning numerous child processes. While done for performance (parallel builds), in reality they don't get reused in my machine (MacBook pro with Neovim) and their only purpose is to turn on the fan and drain my battery.

15 years ago, Visual Studio was light-years ahead of the competition. Today, it struggles to keep up with JetBrains Rider, VSCode and even Neovim.

Microsoft's over-reliance on graphical interfaces has led to clunky and slow experiences. Why does everything need a wizard? Other ecosystems like Go, Rust, and Node.js have a strong CLI-first that is straight-forward, effective and scriptable.

Worse, many organizations are stuck on legacy, Windows-only .NET Framework stacks. They can't access the performance or cross-platform benefits of modern .NET.

Culture

In my experience, the .NET ecosystem often prioritizes rapid, feature-complete development over deep craftsmanship and performance. The prevalence of complex, "enterprisey" patterns often leads to over-engineered solutions for simple problems.

Now, with AI's prevalence, this is getting worse. Microsoft's heavy promotion of AI tools like GitHub Copilot can lead to developers understanding less about the code they're writing. It encourages a copy-paste mentality that papers over a lack of fundamental knowledge. While Microsoft can rightly argue that .NET itself keeps getting faster, the quality of the code being written by the average developer is what worries me.

A Complicated Relationship

After 15 years, I'm conflicted. I have immense respect for the engineers building modern .NET. It's great and has kept me employed for many years. Yet, I'm constantly frustrated by the ecosystem's tooling and culture. My hope is that the community embraces the CLI-first, performance-oriented mindset of modern software development, but for now, it feels like a platform at odds with itself.