.NET 5 arrived in November 2020, uniting .NET Framework and .NET Core into one platform. This merger's impact is clear in the early 2021 ecosystem.
The .NET 5 adoption rate surpassed .NET Core's initial uptake. Clear messaging that .NET 5 is the future of .NET, with .NET Framework 4.x in maintenance mode, eased migration concerns. NuGet package authors quickly updated to support .NET 5. Visual Studio 2019 tooling was top-notch from launch. The ecosystem appears healthy, with active framework development and growing community contributions.
In my last migration of a 300‑project monolith to .NET 5, the biggest surprise was the churn in transitive dependencies. About 18 % of packages that claimed .NET Standard 2.0 support threw runtime errors because they still referenced native binaries compiled for .NET Framework. I ended up scripting a dotnet‑list‑reference audit and forced a rebuild of the offending libraries on Linux with the new RID. The CI pipeline went from a 12‑minute build to 18 minutes once the new SDK was added, but the runtime latency dropped 15 % on average after the upgrade. The lesson was to lock down the NuGet versions early and treat the upgrade as a separate release branch rather than a quick flip.
Blazor WebAssembly, which runs .NET code in browsers via WebAssembly, reached production use in 2020-2021 for internal enterprise apps where SEO isn't crucial and .NET developer reuse is valuable. However, load times and payload size are challenges, as a Blazor WASM app downloads the .NET runtime and app assemblies on first load. Ahead-of-time compilation, added in .NET 6, reduces payload size but increases build time. For internal tools, Blazor WASM is viable; for public-facing apps, the load time cost is significant.
C# source generators, which became generally available in .NET 5, allow code generation at compile time based on user-written code. Use cases include generating serialization code, regular expression code, and INotifyPropertyChanged implementations. Source generators replace reflection-heavy runtime code generation with compile-time code generation, improving startup time and enabling ahead-of-time compilation scenarios.
Source generators are a double‑edged sword. When we introduced a generator to emit System.Text.Json serializers for our DTOs, the cold start of a 10 second Azure Function fell to under 3 seconds, which was a win. The downside was that the incremental build time jumped from 5 seconds to roughly 20 seconds because the Roslyn analyzer re‑ran on every change. Debugging also became less straightforward; stepping into generated code required attaching the debugger to the generated .g.cs file, and the stack traces were noisy. We mitigated this by gating the generator behind a MSBuild property and only enabling it in Release builds, which kept our developer experience sane.
The F# community remains dedicated and vocal, with Ionide, the VS Code F# extension, actively maintained. F# 5 shipped with .NET 5, introducing nameof expressions, open type declarations, and Jupyter notebook support. For data science and analytical workloads on .NET, F# is the natural choice. Although mainstream adoption hasn't occurred, the language continues to influence C# feature design.
.NET 5's ecosystem adoption curve was faster than .NET Core's initial releases, likely due to clear messaging and quick updates from NuGet package authors.
The .NET ecosystem is healthy, with active framework development and growing community contributions, making it an exciting time for .NET developers.
As .NET 5 continues to evolve, it will be interesting to see how the ecosystem adapts and grows, especially with the upcoming releases of .NET 6 and beyond.