.NET 9 Feature Switches: Trimming the Fat (Like Your Code, Not You)

.NET 9 is here, and it's got some seriously nice coding upgrades. Have you heard about feature switches? They’re a way to toggle parts of your application on and off like a freaking light switch. But here's the kicker: it can actually make your code smaller. You heard that right. Smaller. Like, "still fits in your pants after a month of coding and pizza" smaller.

Feature Switches: Because Sometimes You Need a Kill Switch (for Code)

Think of feature switches as "if" statements on steroids. They let you enable or disable features in your app, which is awesome for testing out experimental stuff or deploying different versions without rewriting half your codebase. .NET 9's new attribute model makes this whole process really smooth and also plays nicely with .NET's built-in code trimming.

Meet the Attribute All Stars: FeatureSwitchDefinitionAttribute and FeatureGuardAttribute

.NET 9 introduces two new attributes that are about to become your new best friends:

• FeatureSwitchDefinitionAttribute: This bad boy marks a feature switch property as a constant during trimming. Basically, if a feature is turned off, this attribute tells the trimmer to go full Marie Kondo on your code and chuck out anything related to it. Less code, smaller app, you get the idea.

public class Feature
{    
    [FeatureSwitchDefinition("Feature.IsSupported")]    
    internal static bool IsSupported => AppContext.TryGetSwitch("Feature.IsSupported", out bool isEnabled) ? isEnabled : true;    
    internal static void Implementation()     
    {        
        // Feature-specific implementation    
    }
}
if (Feature.IsSupported)    
    Feature.Implementation();

• FeatureGuardAttribute: This attribute is like a bouncer for your code. It works with other attributes like RequiresDynamicCodeAttribute to make sure certain code only runs if the runtime environment supports it. Think of it as a safety net for when you're doing some wild stuff with dynamic code.

public class Feature
{    
    [FeatureGuard(typeof(RequiresDynamicCodeAttribute))]    
    internal static bool IsSupported => RuntimeFeature.IsDynamicCodeSupported;    
    [RequiresDynamicCode("Feature requires dynamic code support.")]    
    internal static void Implementation()    
    {        
        // Uses dynamic code    
    }
}
if (Feature.IsSupported)    
    Feature.Implementation();

Why Feature Switches Are the Bee's Knees (and Other Body Parts

• Smaller Apps: Trimming unused code means your app will be leaner than a greyhound on a diet.
• Faster Performance: Less code means faster loading times and less memory usage. Your users will thank you (maybe).
• Flexibility: Turn features on and off like a boss, without messing with your core code. It's like having your own personal "easy button" for development.
• Code Management: Keep your experimental code separate from your stable code. No more accidentally releasing the kraken* on your users.

Wrap Up

.NET 9's new attribute model for feature switches is a sweet feature. With FeatureSwitchDefinitionAttribute and FeatureGuardAttribute, you can create apps that are smaller, faster, and more flexible than ever before. So go forth and trim that fat! (But seriously, keep eating pizza. We need fuel.)

*This is the first time I’ve been able to insert a Kraken reference so sue me. #seakraken