When you build .NET applications with strongly typed configuration, IOptions<T> and its variants give you a clean way to bind appsettings.json sections to C# classes. But binding isn't the same as validating - a missing required value or an out-of-range number will happily bind to a default and silently break your app at runtime. IValidateOptions<T> is the hook .NET provides to fix that. The problem: silent misconfiguration Consider a typical options class: If Host is missing from appsettings.json , your app starts fine. The failure surfaces only when the first email is sent — in production, at 2 AM. Data Annotations ( [Required] , [Range] ) combined with ValidateDataAnnotations() help, but they fall short when you need: Cross-property validation (e.g., Port must be 465 when UseSsl is true ) Async or database-backed checks Conditional logic depending on environment Reusable validators shared across multiple options types This is where I...
If you've ever been mid-session with Copilot and thought "I want to try a completely different approach, but I don't want to lose everything I've built up here" — the new /fork command is exactly what you've been waiting for. Shipped in the February 2026 release of VS Code, /fork lets you branch a chat session into a new, fully independent thread — complete with the full conversation history — so you can explore an alternative direction without touching the original. The problem it solves Until now, exploring multiple design options or implementation strategies with Copilot meant one of two things: Start a new session — losing all the context you've already established. Stay in the same session — making your conversation messy and hard to track. Neither is great. Especially for larger tasks where the agent has already built up a useful mental model of your codebase, intent, and constraints. How to use /fork There are two ways to ...