Visual Studio IDE and Extensions
Visual Studio is not just an editor with debugging attached. It is a tightly coupled stack of MSBuild, the project system, the debugger, and a stream of analyzers — and the moments where that coupling leaks through are exactly where most real productivity lives. The articles in this collection focus on those moments rather than on tip-of-the-iceberg features that demo well but rarely change how a team ships.
A recurring entry point is MSBuild integration. The BuildingInsideVisualStudio property, the difference between an IDE build and a CLI build, conditional package references that fire only inside the IDE, and the surprises that surface when CI builds behave differently from local builds — these belong to Visual Studio specifically, not to .NET generically. Knowing which property the IDE sets, and when, is the difference between a clean build matrix and a folder full of bin directories nobody can explain.
The debugger is another area where the depth matters. Time-travel debugging, the immediate window, conditional and tracepoint breakpoints, .NET source stepping, and the diagnostic tools window are all useful — but only if you know which one to reach for. Articles cover the debugger as an investigation surface for production-shaped problems: async deadlocks, GC pressure, native interop, and the kind of bug that only reproduces when the profiler is detached.
The project system itself gets attention because SDK-style projects, multi-targeting, central package management, and solution filters all interact in ways the documentation rarely covers in one place. Articles examine what Visual Studio actually does with a .csproj, how the IDE caches design-time builds, and why a dotnet restore from the CLI sometimes disagrees with the IDE’s package graph.
Expect opinionated takes on which extensions earn their place in a long-running install, which analyzers belong in .editorconfig rather than in a settings dialog, and where Visual Studio’s defaults stop being helpful for teams that ship .NET professionally.
Code Metrics and Configuration: Beyond the Numbers Game
Code metrics have become a standard feature in modern development environments, yet their implementation and interpretation often leave much to be desired. While Visual Studio and .NET provide comprehensive code metrics analysis, the way these metrics are configured, presented, and (more critically) acted upon reveals a fundamental disconnect between measurement and meaningful improvement.
What code metrics actually measure, how to configure them properly, and (more importantly) why blindly following thresholds without understanding context is, frankly, a recipe for misguided refactoring efforts that waste your team’s time and actively damage your codebase.
Still Waiting for C# 14
Visual Studio 2026 - Why AI-Native Tooling Will Matter
Let’s skip the typical release-cycle enthusiasm for a second: Most IDE updates come and go. New features, some refactoring helpers, a bit of polish, then back to business as usual. Visual Studio 2026 is different. For once, the promise of “AI-native” isn’t just marketing. If Microsoft lands even half of what they’re previewing, it’s going to matter—a lot.
How to Use Copilot Without Becoming Its Puppet
In a previous article, we laid it out – unfiltered: Copilot turns junior devs into syntax secretaries.
Not because it’s evil. But because it removes friction before understanding.
It gives you working code before you know what working even means. It creates the illusion of progress, while slowly eroding the very skills that define a software engineer: reasoning, decision-making, and technical ownership.
Copilot Turns Junior Devs Into Syntax Secretaries
The hype around GitHub Copilot (or any other AI code assistant) is deafening. AI-assisted coding. Effortless automation. 10x productivity.
But here’s the harsh truth: Copilot isn’t empowering junior developers – it’s deskilling them.