Last month, I watched a senior developer spend three days debugging a build failure that worked perfectly on his machine. The CI pipeline? Failed every single time. Different error messages. Inconsistent behavior. Pure chaos.

The root cause? A single line in a .csproj file:

<PropertyGroup Condition="'$(TargetFramework)' == 'net8.0'">

That’s it. One innocent-looking string comparison brought a multi-targeting .NET project to its knees.

Here’s what nobody tells you about TargetFramework conditions: string comparisons are a trap. They work on your machine because you’re building net8.0 exactly. They fail in CI because your pipeline builds net8.0-windows. They explode in production when someone adds net8.0-android six months later. And the worst part? The failures are silent. No exceptions. No obvious errors. Just conditions that stop matching and features that mysteriously vanish.

I’ve seen this pattern destroy three separate projects. Multi-targeting nightmares. Build configs that work by accident. Hours of debugging that could have been avoided with one single property function.

Microsoft documented TargetFramework property functions years ago, yet developers keep writing fragile string comparisons. So let me be brutally clear: if you’re using $(TargetFramework)' == 'something' conditions, you’re sitting on a time bomb.

As .NET evolves, developers face an ever-growing tension between modern language features and the need to maintain compatibility across multiple frameworks. Applications no longer run in isolated environments; they live within ecosystems that combine .NET Framework, .NET Core, and .NET 6 or later. In such an environment, reliability and maintainability become the cornerstones of sustainable development. Defensive programming — the art of protecting your software against invalid inputs and unintended states — plays a crucial role in achieving this stability.

It begins like many stories in software: a well-intentioned developer joining a project, determined to do things properly. You arrive at a codebase that has grown organically, perhaps even chaotically. You decide you will bring order. You set up unit testing, you configure continuous integration, you measure code coverage. You write dozens or hundreds of tests. Every public method is touched, every branch is at least executed. The dashboard lights up green. You feel, quite frankly, on top of things.

Then one day, production breaks under your watch

Let’s be honest: health checks are the broccoli of .NET projects. Everyone says they have them, but nobody’s excited to eat their greens. What starts as a humble SELECT 1 in a try/catch quickly explodes into a wild jungle of scripts, copy-pasted connection strings, and endpoints that only half the team remembers. Sure, it works—until it doesn’t. And when it breaks, it’s never at a good time.