.NET Development and Framework
Modern .NET is a platform on a release rhythm — not the static framework that some teams still imagine when they hear the name. Once you accept the LTS-and-STS cadence, almost every architectural conversation inside a .NET shop changes. Lifecycle planning becomes a quarterly topic. Major version migrations become routine rather than projects. And the question stops being “which version are we on” and becomes “what is our story for the next two.”
A recurring theme in this collection is evolution over time. The runtime, the BCL, and the SDK each move on their own track, and the interesting work happens at the seams. Dynamic PGO, tiered compilation, and the steady improvements to the JIT have changed what performance-sensitive code looks like — patterns that were defensible in .NET Framework era are now actively slower than the idiomatic version. Articles trace these shifts release by release rather than treating any single version as the canonical reference.
The BCL has been quietly transformed by additions like SearchValues<T>, FrozenDictionary, Span<T>, Memory<T>, and the surrounding ecosystem of ref struct types. These are not niche features — they are the new defaults for anyone writing hot-path code. Articles cover when reaching for them pays back, when the older API is still the right answer, and the surprising corners where they interact badly with closures, async, or older library boundaries.
SDK ergonomics deserve their own attention. Central Package Management, project-level PackageReference graphs, source generators, AOT, and the slow but real maturing of the workload model all shape what a maintainable solution looks like. Articles cover the project-system trade-offs that compound silently across a multi-year codebase.
The LTS/STS rhythm itself is treated as a planning concern. Articles cover how to schedule upgrades against a real release window, when to skip an STS release, and how to keep the upgrade muscle exercised so that the next migration is not the one that breaks things.
Managing Errors, Warnings, and Configurations in C# and .NET
When we activated static code analysis for the first time in one of my last projects, the overwhelming number of warnings exceeded expectations and highlighted gaps in the code. Without making any changes, the project already had a significant number of warnings. After activating additional analyzers and updating some configurations, this number temporarily increased dramatically.
The high number of warnings was initially daunting, but we saw it as an opportunity to significantly improve our code quality. At first glance, it seemed easier to suppress or ignore these warnings. But as I often remind my team, “The code you create is a valuable legacy, so it’s important to build it carefully.” Ignoring warnings today creates obstacles for future developers—and that could very well include you six months down the line.
This experience reinforced the importance of managing warnings and errors systematically. Let me share some of the lessons we learned, the strategies we used to tame those 60,000 warnings, and how you can apply these techniques to your own projects.
Nullability in Legacy Code
As developers, we’re often tasked with maintaining and modernizing legacy codebases that were written long before some of the best practices of today—such as nullability annotations—were available. While modern C# now supports nullable reference types, enabling us to avoid the dreaded NullReferenceException, introducing this feature to existing, large codebases can be a challenge.
In this article, I’ll share my step-by-step approach for introducing nullability into a legacy .NET and C# project. You’ll learn how to apply nullability in a controlled, incremental manner using project-level settings, scoped annotations, and file/method-level directives, all while maintaining the integrity of your legacy codebase. After all, modernizing your code doesn’t have to be an all-or-nothing endeavor—gradual change is key to a successful transition. Let’s get started!
BuildingInsideVisualStudio
In the ever-evolving world of .NET development, managing project configurations effectively is crucial for maintaining a clean and efficient build process. One of the less frequently discussed but highly useful properties is BuildingInsideVisualStudio. This property, when correctly utilized, can streamline your build process and ensure that your project is configured properly depending on the build environment. In this article, we’ll explore the BuildingInsideVisualStudio property with concrete examples and discuss best practices for using it effectively.
Manage NuGet Packages Centrally
For over 12 years, NuGet package management has been part of the .NET ecosystem with direct integrations to various IDEs, CLIs and build systems. But a feature took 12 years before it appeared and certainly needs some more maintenance until it is mature!