Giorgi Kobaidze

Posted on Dec 14

.NET 10: The Performance Beast That's Redefining Modern Application Development

#csharp #microsoft #dotnet #programming

Table of Contents
Introduction
C# 14: Language Features
.NET 10 New Features
Other Changes
- Visual Studio 2026
- Github Copilot App Modernization
Summary

Introduction

Microsoft's Boldest .NET Release Yet

After years of relentless innovation Microsoft drops .NET 10 in November 2025 with a clear message: performance, developer productivity, AI, and cloud-native excellence are no longer competing priorities they're table stakes.

.NET 10 isn't just an incremental update. It represents a fundamental shift in how we think about building applications in an AI-first, cloud-native world. With major performance improvements in critical paths, C# 14's game-changing language features, and ASP.NET Core's radical simplification of web development, this release challenges everything we thought we knew about the limits of managed runtime performance.

What This Article Covers and Who Should Read It?

This article is for:

.NET developers who are unsure about upgrading to the latest version
Non-.NET developers who are hesitant about adopting .NET

Whether you're a:

Backend developer drowning in latency requirements and looking for legitimate performance gains
Frontend developer who's fed up with endless JavaScript churn and tangled toolchains, Blazor and MAUI offer a cleaner, unified, C#-powered alternative that actually lets you focus on building, not babysitting frameworks
Architect evaluating whether .NET 10's LTS stability combined with cutting-edge features makes it the right choice for new projects
Engineering manager / Tech Lead making platform decisions that will impact the next 3-5 years while balancing delivery pressure, team productivity, and long-term maintainability
Full-stack engineer tired of maintaining separate frontend and backend codebases
DevOps engineer optimizing container costs and deployment pipelines

You'll find concrete, actionable insights backed by benchmarks, code examples, and real-world migration experiences.

Disclaimer: This is a large article with a lot of information and reasonable depth. However it still doesn't cover everything introduced recently, doing that would require a 900-page book (or more).

The goal here is to highlight the most interesting and useful additions from my perspective, share my opinions and trade-offs, and provide demo examples that make each topic easier to understand.

As a principal software engineer myself, I'll need to work with this framework at some point, so this article also serves as structured notes for my future self - a way to quickly regain context and insights without relearning everything from scratch.

.NET Support Policy

Here's the best part: .NET 10 is a Long Term Support (LTS) release, supported for three full years until November 2028. Unlike .NET 9 (STS) which only receives 18 months of support, .NET 10 combines cutting-edge features with enterprise-grade stability.

Check out the .NET lifecycle table for the currently supported versions:

Version	Original Release Date	Release Type	End of Support
.NET 10	November 11, 2025	LTS	November 14, 2028
.NET 9	November 12, 2024	STS	November 10, 2026
.NET 8	November 14, 2023	LTS	November 10, 2026

.NET follows a predictable release cadence where even-numbered versions receive Long Term Support (LTS). This makes .NET 10 the perfect storm for adoption: you get bleeding-edge features wrapped in enterprise-grade support commitments. Unlike .NET 9 which forces you to choose between cutting-edge capabilities and long-term stability, .NET 10 delivers both. This is the sweet spot: groundbreaking performance improvements with the long-term commitment that production systems demand. Sounds like a great deal doesn't it?

Playground Repository

Some of the code examples in this article comes from real, runnable code in my repository. Rather than trust code snippets and demos, you can clone the repository, run the code on your own hardware, and see how it all plays out for yourself.

Also, feel free to fork the repository add your own code and create pull requests to contribute.

georgekobaidze / dotnet10-playground

If you'd like to follow along, start by downloading and installing .NET 10 from the following link: https://dotnet.microsoft.com/en-us/download/dotnet/10.0

To generate a repository with a structure similar to mine, it's much easier to use the CLI than to manually create files and folders through a GUI. You can follow the instructions I outlined in one of my previous articles:

Kickstarting a .NET Solution from Scratch with the CLI

Giorgi Kobaidze ・ May 15

#dotnet #cli #softwareengineering #terminal

Now that the groundwork is laid, let's dive in.

C# 14: Language Features

Extension Members

This is an interesting new feature that could reshape how we write extension methods. And on top of that, we now also have things like:

Extension properties
Extension operators

The best way to describe the purpose of extension methods is that they "enable you to "add" methods to existing types without creating a derived type, recompiling, or modifying the original type." This definition comes straight from Microsoft's official documentation.

The most interesting part is that this feature isn't just more syntactic sugar, it's something new to C#, with real potential to simplify code and make it more elegant and readable. And, of course, it's completely optional, whether you choose to use it is entirely up to you.

Syntax

Instead of the traditional way (static class + this keyword in method parameter), C# 14 allows a cleaner extension(...) { ... } block inside a static class.

Inside this block, you define extension methods, properties, or even operators, and the "receiver" type (the type you're extending) is declared just once.

Example

Let's implement examples for each type of extension member so we can explore their full potential and see exactly how they behave.

I'm going to use the ConsolePlayground project for this task from my repository.

The "Point"

Let's make our example about a Point, because, well, what's the point without a point, right? Get it?😏 OK, I see myself out.

Ever taken a math class? Then you probably remember that a point has two coordinates: X and Y. (Sure, it can have more, but we're just trying to make up an example alright? We're not trying to launch a Mars rover here. Not yet, anyway.)

This definition opens the door pretty wide for modeling a point mathematically and turning all that into code. Don't worry, we're not going full "mad scientist" here. We'll just add a few properties, methods, and operators for demo purposes.

Let's define the following members:

Extension properties: Magnitude and IsAtOrigin

Static extension properties: Origin and UnitX

Instance Extension Methods: Translate and DistanceTo

Static Extension Method: FromPolar

Extension Operators (Binary): + and *

Extension operator (Unary): -

Let's create the Point.cs file, which will contain a record for Point.

public record Point(double X, double Y);

And a separate file for the extensions: PointExtensions.cs

public static class PointExtensions
{
    extension (Point point)
    {
        // Instance Extension Properties
        public double Magnitude => Math.Sqrt(point.X * point.X + point.Y * point.Y);
        public bool IsAtOrigin => point.X == 0 && point.Y == 0;

        // Static Extension Properties
        public static Point Origin => new(0, 0);
        public static Point UnitX => new(1, 0);

        // Instance Extension Methods
        public Point Translate(double dx, double dy) => new(point.X + dx, point.Y + dy);
        public double DistanceTo(Point other)
        {
            double dx = point.X - other.X;
            double dy = point.Y - other.Y;
            return Math.Sqrt(dx * dx + dy * dy);
        }

        // Static Extension Method
        public static Point FromPolar(double radius, double angleRadians)
        {
            return new Point(
                radius * Math.Cos(angleRadians),
                radius * Math.Sin(angleRadians)
            );
        }

        // Extension Operators (Binary)
        public static Point operator +(Point left, Point right) =>
            new(left.X + right.X, left.Y + right.Y);

        public static Point operator *(Point p, double scalar) =>
            new(p.X * scalar, p.Y * scalar);

        // Extension Operator (Unary)
        public static Point operator -(Point p) =>
            new(-p.X, -p.Y);
    }
}

This shows how each extension member works. It's all very straightforward. The only truly new piece of syntax here is extension(...) { ... }, and even that feels pretty intuitive.

Now, to make things even clearer, let's open Program.cs and see how we can actually use these extension members.

Console.WriteLine("=== C# 14 Extension Members Demo ===\n");

// Static Extension Properties
Console.WriteLine("1. Static Extension Properties:");
Console.WriteLine($"   Point.Origin = {Point.Origin}");
Console.WriteLine($"   Point.UnitX = {Point.UnitX}");

// Static Extension Method
Console.WriteLine("\n2. Static Extension Method:");
var polar = Point.FromPolar(5, Math.PI / 4);
Console.WriteLine($"   Point.FromPolar(5, π/4) = {polar}");

// Instance Extension Properties
Console.WriteLine("\n3. Instance Extension Properties:");
var point1 = new Point(3, 4);
Console.WriteLine($"   point1 = {point1}");
Console.WriteLine($"   point1.Magnitude = {point1.Magnitude}");
Console.WriteLine($"   point1.IsAtOrigin = {point1.IsAtOrigin}");

// Instance Extension Methods
Console.WriteLine("\n4. Instance Extension Methods:");
var point2 = new Point(-2, 3);
var translated = point1.Translate(1, 1);
Console.WriteLine($"   point1.Translate(1, 1) = {translated}");

var distance = point1.DistanceTo(point2);
Console.WriteLine($"   point1.DistanceTo(point2) = {distance:F2}");

// Extension Operators
Console.WriteLine("\n5. Extension Operators:");
var sum = point1 + point2;
Console.WriteLine($"   {point1} + {point2} = {sum}");

var product = point1 * 2;
Console.WriteLine($"   {point1} * 2 = {product}");

var negated = -point1;
Console.WriteLine($"   -{point1} = {negated}");

// Combined Usage
Console.WriteLine("\n6. Combined Usage:");
var complexExpression = Point.Origin + Point.UnitX * 2;
Console.WriteLine($"   Origin + UnitX*2 = {complexExpression}");

Console.WriteLine("\n=== Demo Complete ===");

It'll output the following result:

I'm sold!

Null Conditional Assignment

If you've been writing C# for a while, you're probably familiar with the null-conditional operator (?.) and the null-coalescing operator (??). These have been lifesavers for avoiding NullReferenceException and writing cleaner null-handling code. But there's always been one annoying gap: you couldn't use ?. on the left side of an assignment.

Consider this common scenario: you have a nested object, and you only want to assign a value to a property if the parent object isn't null. Before C# 14, you had to write something like this:

if (person?.Address != null)
{
    person.Address.City = "Seattle";
}

Or the slightly more verbose version:

if (person is not null && person.Address is not null)
{
    person.Address.City = "Seattle";
}

It works, but it's clunky. You're essentially checking for null twice, once in your condition and once implicitly when you access the property.

C# 14 fixes this with null-conditional assignment. You can now write:

person?.Address?.City = "Seattle";

That's it. One line. If person is null, nothing happens. If person.Address is null, nothing happens. Only if both are non-null does the assignment occur. No exception, no ceremony, just clean, readable code.

Why Is This Important?

Reduced boilerplate: You no longer need verbose null checks scattered throughout your code just to safely assign values.
Consistency: The ?. operator already works for method calls and property access. Now it works for assignments too, making the language more consistent and predictable.
Fewer bugs: Every time you write an if statement, there's a chance you'll get it wrong. Maybe you forget to check one level of nesting, or you accidentally use || instead of &&. Null-conditional assignment eliminates these opportunities for mistakes.
Better readability: Code intent is immediately clear. When someone reads person?.Address?.City = "Seattle", they instantly understand: "assign this value only if the path is valid."

Demo Example

Let's see this in action. I'll use the ConsolePlayground project to demonstrate a practical scenario.

Imagine we're building a user profile system where users can optionally have address information:

public record Address
{
    public string? Street { get; set; }
    public string? City { get; set; }
    public string? Country { get; set; }
}

public record Person
{
    public string Name { get; set; } = string.Empty;
    public Address? Address { get; set; }
}

Now let's write some code that updates the address information using null-conditional assignment:

Console.WriteLine("=== C# 14 Null Conditional Assignment Demo ===\n");

// Scenario 1: Person with an address
var personWithAddress = new Person
{
    Name = "Alice",
    Address = new Address { Street = "123 Main St", City = "Portland" }
};

Console.WriteLine("Before update:");
Console.WriteLine($"  {personWithAddress.Name}'s city: {personWithAddress.Address?.City}");

// Using null-conditional assignment
personWithAddress?.Address?.City = "Seattle";

Console.WriteLine("After update:");
Console.WriteLine($"  {personWithAddress.Name}'s city: {personWithAddress.Address?.City}");

// Scenario 2: Person without an address
var personWithoutAddress = new Person { Name = "Bob" };

Console.WriteLine($"\n{personWithoutAddress.Name} has no address.");
Console.WriteLine("Attempting to set city using null-conditional assignment...");

// This safely does nothing because Address is null
personWithoutAddress?.Address?.City = "New York";

Console.WriteLine($"  City after attempted assignment: {personWithoutAddress.Address?.City ?? "(no address)"}");

// Scenario 3: Null person reference
Person? nullPerson = null;

Console.WriteLine("\nAttempting to set city on a null person reference...");

// This safely does nothing because nullPerson is null
nullPerson?.Address?.City = "Chicago";

Console.WriteLine("  No exception thrown! Assignment was safely skipped.");

Console.WriteLine("\n=== Demo Complete ===");

Running this code produces the following output:

=== C# 14 Null Conditional Assignment Demo ===

Before update:
  Alice's city: Portland
After update:
  Alice's city: Seattle

Bob has no address.
Attempting to set city using null-conditional assignment...
  City after attempted assignment: (no address)

Attempting to set city on a null person reference...
  No exception thrown! Assignment was safely skipped.

=== Demo Complete ===

As you can see, the null-conditional assignment gracefully handles all three scenarios:

When the full path exists, the assignment works as expected
When part of the path is null, the assignment is simply skipped
When the root object is null, no exception is thrown

The Old Way vs. The New Way

Here's a side-by-side comparison to really drive home how much cleaner this is:

Before C# 14:

if (order != null && order.Customer != null && order.Customer.Preferences != null)
{
    order.Customer.Preferences.NotificationsEnabled = true;
}

C# 14:

order?.Customer?.Preferences?.NotificationsEnabled = true;

The improvement speaks for itself. Less code, fewer chances for bugs, and the intent is crystal clear.

This might seem like a small change, but it's exactly the kind of quality-of-life improvement that makes a language more enjoyable to use day-to-day. It's one less thing to think about, one less pattern to remember, and one less source of potential bugs.

Field Access in Auto Properties

Auto-properties have been one of C#'s most beloved features since their introduction. They let you write public string Name { get; set; } instead of manually declaring a backing field and wiring up the getter and setter. Clean, simple, elegant.

But here's the problem: the moment you need to add any logic to your property, like validation, transformation, or lazy initialization, you lose the auto-property syntax entirely. You have to fall back to the old-school approach:

private string _name = string.Empty;

public string Name
{
    get => _name;
    set
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException("Name cannot be empty");

        _name = value;
    }
}

Suddenly you're back to declaring backing fields, picking naming conventions (_name, m_name, name), and dealing with extra boilerplate. For a single property it's fine, but when you have a dozen properties (or hundreds of properties) that all need validation, your class becomes a wall of repetitive code.

C# 14 introduces the field keyword, which gives you direct access to the compiler-generated backing field within your property accessors. Now you can write:

public string Name
{
    get;
    set
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException("Name cannot be empty");

        field = value;
    }
}

No explicit backing field declaration needed. The compiler creates one for you, and you access it using the contextual keyword field. You get the best of both worlds: the conciseness of auto-properties with the flexibility of custom logic.

Why Is This Important?

Less boilerplate: You don't need to declare backing fields manually anymore. The compiler handles it, and you just reference field when you need it.
Cleaner code: Your classes stay focused on what matters, the logic, rather than being cluttered with field declarations and naming conventions.
Consistency: No more debates about _name vs m_name vs name. The backing field is anonymous and accessed uniformly via field.
Gradual enhancement: You can start with a simple auto-property and add logic later without restructuring your code. Just add the accessor body and use field.
Works with both get and set: You can use field in either accessor, or both, depending on your needs.

Demo Example

Let's build a practical example. Imagine we're creating a Product class for an e-commerce system with properties that need validation and transformation:

public class Product
{
    // Simple validation: price must be non-negative
    public decimal Price
    {
        get;
        set
        {
            if (value < 0)
                throw new ArgumentOutOfRangeException(nameof(value), "Price cannot be negative");

            field = value;
        }
    }

    // Transformation: automatically trim and capitalize the name
    public string Name
    {
        get;
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Product name cannot be empty", nameof(value));

            field = value.Trim();
        }
    }

    // Lazy initialization with field access in getter
    public string Slug
    {
        get => field ??= GenerateSlug(Name);
        set;
    }

    // Stock quantity with change tracking
    public int StockQuantity
    {
        get;
        set
        {
            if (value < 0)
                throw new ArgumentOutOfRangeException(nameof(value), "Stock cannot be negative");

            int oldValue = field;
            field = value;

            if (oldValue != value)
                Console.WriteLine($"Stock changed from {oldValue} to {value}");
        }
    }

    private static string GenerateSlug(string name) =>
        name.ToLowerInvariant().Replace(" ", "-");
}

Now let's test this class:

Console.WriteLine("=== C# 14 Field Keyword Demo ===\n");

var productItem = new Product();

// Test Name with trimming
Console.WriteLine("1. Setting product name with extra whitespace:");
productItem.Name = "   Wireless Headphones   ";
Console.WriteLine($"   Stored name: \"{productItem.Name}\"");

// Test Price validation
Console.WriteLine("\n2. Setting valid price:");
productItem.Price = 99.99m;
Console.WriteLine($"   Price: {productItem.Price:C}");

Console.WriteLine("\n3. Attempting to set negative price:");
try
{
    productItem.Price = -10m;
}
catch (ArgumentOutOfRangeException ex)
{
    Console.WriteLine($"   Caught exception: {ex.Message}");
}

// Test lazy slug generation
Console.WriteLine("\n4. Accessing slug (lazy initialization):");
Console.WriteLine($"   Slug: {productItem.Slug}");

// Test stock quantity with change tracking
Console.WriteLine("\n5. Updating stock quantity:");
productItem.StockQuantity = 100;
productItem.StockQuantity = 95;
productItem.StockQuantity = 95;  // No change, no message

Console.WriteLine("\n=== Demo Complete ===");

Running this produces:

=== C# 14 Field Keyword Demo ===

1. Setting product name with extra whitespace:
   Stored name: "Wireless Headphones"

2. Setting valid price:
   Price: $99.99

3. Attempting to set negative price:
   Caught exception: Price cannot be negative (Parameter 'value')

4. Accessing slug (lazy initialization):
   Slug: wireless-headphones

5. Updating stock quantity:
Stock changed from 0 to 100
Stock changed from 100 to 95

=== Demo Complete ===

The Old Way vs. The New Way

Let's compare a class with multiple validated properties:

Before C# 14:

public class User
{
    private string _email = string.Empty;
    private int _age;
    private string _username = string.Empty;

    public string Email
    {
        get => _email;
        set
        {
            if (!value.Contains('@'))
                throw new ArgumentException("Invalid email");

            _email = value.ToLowerInvariant();
        }
    }

    public int Age
    {
        get => _age;
        set
        {
            if (value < 0 || value > 150)
                throw new ArgumentOutOfRangeException(nameof(value));

            _age = value;
        }
    }

    public string Username
    {
        get => _username;
        set
        {
            if (value.Length < 3)
                throw new ArgumentException("Username too short");

            _username = value.Trim();
        }
    }
}

C# 14:

public class User
{
    public string Email
    {
        get;
        set
        {
            if (!value.Contains('@'))
                throw new ArgumentException("Invalid email");

            field = value.ToLowerInvariant();
        }
    }

    public int Age
    {
        get;
        set
        {
            if (value < 0 || value > 150)
                throw new ArgumentOutOfRangeException(nameof(value));

            field = value;
        }
    }

    public string Username
    {
        get;
        set
        {
            if (value.Length < 3)
                throw new ArgumentException("Username too short");

            field = value.Trim();
        }
    }
}

The C# 14 version eliminates all the backing field declarations at the top of the class. It's cleaner, more focused, and the relationship between each property and its validation logic is immediately clear.

Why Did This Take So Long?

If you've been following C# development, you might know that this feature has been on the wishlist for years. Developers have been asking for it since auto-properties were first introduced. So why did it take until C# 14?

The answer is simple but important: BREAKING CHANGES.

The word field is not a reserved keyword in C#. It's a perfectly valid identifier. That means there's existing code out there that looks like this:

public class SomeClass
{
    private int field;  // A variable literally named "field"

    public int Value
    {
        get => field;
        set => field = value;
    }
}

If Microsoft had simply made field a full keyword, this code would break. Every project using field as a variable name would suddenly fail to compile. That's millions of lines of code across the ecosystem potentially affected.

The .NET team had to be extremely careful here. They needed to introduce the feature without breaking existing codebases. The solution? Make field a contextual keyword, meaning it only has special meaning in a specific context, inside property accessors where there's no local variable or parameter named field.

What if you have an existing member named field? If your class already has a field literally named field and you want to access it inside a property accessor (where the keyword takes precedence), you have two options:

Use the this keyword: this.field
Use the @ escape: @field

Both of these explicitly tell the compiler "I mean my variable, not the backing field keyword."

public class Example
{
    private int field = 42;  // Your own field named 'field'

    public int Value
    {
        get;
        set
        {
            Console.WriteLine(this.field);  // Refers to the class member (42)
            Console.WriteLine(@field);      // Also refers to the class member (42)
            field = value;                  // Refers to the backing field keyword
        }
    }
}

This careful approach means your existing code continues to work exactly as before. The new feature is purely additive, and when naming conflicts arise, you have clear escape hatches to disambiguate.

This is a great example of how language design isn't just about adding cool features. It's about doing so responsibly, respecting the vast ecosystem of existing code, and maintaining the trust that developers have placed in backward compatibility.

Important Notes

The field keyword is contextual, it only has special meaning inside property accessors. If you have an existing field named field in your code, it will still work, but you might want to rename it for clarity to avoid confusion.
You can use field with property initializers: public string Name { get; set => field = value.Trim(); } = "Default";
This feature works with init accessors too, not just set.

This is one of those features that might seem minor at first glance, but once you start using it, you'll wonder how you ever lived without it. It removes friction from a very common pattern and makes C# properties even more powerful.

Simple Lambda Parameters With Modifiers

Lambda expressions in C# support type inference, so you can write x => x * 2 instead of (int x) => x * 2. But there's been one annoying exception: the moment you add a parameter modifier, you lose the concise syntax.

Before C# 14, if you wanted to use ref, out, in, or params in a lambda, you had to explicitly specify the type:

// Without modifier - type is inferred
Func<int, int> square = x => x * x;

// With modifier - forced to specify type
RefAction<int> doubleIt = (ref int x) => x *= 2;

C# 14 removes this limitation. You can now use modifiers without specifying the type:

RefAction<int> doubleIt = (ref x) => x *= 2;

Supported Modifiers

All parameter modifiers work with implicit typing: ref, out, in, ref readonly, scoped, and params.

The Old Way vs. The New Way

Before C# 14:

ProcessData((ref int x, ref int y) => (x, y) = (y, x));

TryParseAll(items, (string s, out int result) => int.TryParse(s, out result));

Calculate((in Vector3 v) => v.Length());

C# 14:

ProcessData((ref x, ref y) => (x, y) = (y, x));

TryParseAll(items, (s, out result) => int.TryParse(s, out result));

Calculate((in v) => v.Length());

The improvement is especially valuable in high-performance code where ref, in, and Span<T> are common. Instead of cluttering your lambdas with type annotations that the compiler can already infer, you just add the modifier you need and move on.

User-Defined Compound Assignment Operators

In C#, when you write x += 5, the compiler translates it to x = x + 5. This works fine for most cases, but there's a problem: what if you want += to behave differently than +?

This matters for performance-sensitive types. Consider a StringBuilder-like type or a collection. When you write list = list + item, you're creating a new object and reassigning. But list += item could modify the existing object in place, which is far more efficient.

Before C# 14, you couldn't express this distinction. Compound assignment always expanded to the binary operator plus assignment.

C# 14 lets you define compound assignment operators separately. The += operator can now:

Return void instead of the type
Take the first parameter by ref, allowing in-place modification

Demo Example

Let's create a custom 2D vector type to demonstrate this feature:

Console.WriteLine("=== C# 14 User-Defined Compound Assignment Operators Demo ===\n");

var v1 = new Vec2D(3, 4);
var v2 = new Vec2D(1, 2);

Console.WriteLine($"v1 = {v1}");
Console.WriteLine($"v2 = {v2}");

// Using + operator (creates new instance)
Console.WriteLine("\nUsing + operator (creates new instance):");
var v3 = v1 + v2;
Console.WriteLine($"v3 = v1 + v2 = {v3}");
Console.WriteLine($"v1 is still: {v1} (unchanged)");

// Using += operator (modifies in place)
Console.WriteLine("\nUsing += operator (modifies in place):");
Console.WriteLine($"Before: v1 = {v1}");
v1 += v2;
Console.WriteLine($"After v1 += v2: v1 = {v1} (modified!)");

Console.WriteLine("\n=== Demo Complete ===");

// Custom 2D vector struct
public struct Vec2D
{
    public double X { get; set; }
    public double Y { get; set; }

    public Vec2D(double x, double y)
    {
        X = x;
        Y = y;
    }

    // Regular + operator - creates new instance
    public static Vec2D operator +(Vec2D a, Vec2D b)
        => new Vec2D(a.X + b.X, a.Y + b.Y);

    // C# 14: Compound assignment operator - modifies in place
    public static void operator +=(ref Vec2D a, Vec2D b)
    {
        a.X += b.X;
        a.Y += b.Y;
    }

    public override string ToString() => $"({X}, {Y})";
}

Output:

=== C# 14 User-Defined Compound Assignment Operators Demo ===

v1 = (3, 4)
v2 = (1, 2)

Using + operator (creates new instance):
v3 = v1 + v2 = (4, 6)
v1 is still: (3, 4) (unchanged)

Using += operator (modifies in place):
Before: v1 = (3, 4)
After v1 += v2: v1 = (4, 6) (modified!)

=== Demo Complete ===

Why Is This Important?

Performance: Avoid unnecessary allocations by modifying objects in place instead of creating new ones.
Semantic clarity: + means "combine and create new", while += means "append to existing". Now your code can reflect that distinction.
Mutable collections: Types like List<T> or custom buffers can now have += mean "add to this collection" rather than "create a new collection with this item added".

The Old Way vs. The New Way

Before C# 14:

// Both operations did the same thing - create new instance
var result = v1 + v2;     // Creates new instance
v1 = v1 + v2;             // What += expanded to - also creates new instance

C# 14:

var result = v1 + v2;  // Creates new instance
v1 += v2;              // Modifies v1 in place (if custom += is defined)

This feature is particularly useful for numeric types, buffers, builders, and any scenario where in-place mutation is more efficient than creating new instances. It's a niche but powerful addition for library authors and performance-critical code.

Partial Events and Constructors

The partial keyword has been in C# for a long time, allowing you to split a class across multiple files. More recently, C# added partial methods and partial properties. C# 14 completes the picture by adding partial events and partial constructors.

This is especially useful for source generators. A generator can declare a partial constructor or event, and you provide the implementation in your own code. It keeps generated code separate from hand-written code while allowing them to work together seamlessly.

Partial Constructors

// File: MyClass.Generated.cs (from source generator)
public partial class MyClass
{
    public partial MyClass(string name);  // Declaration
}

// File: MyClass.cs (your code)
public partial class MyClass
{
    public partial MyClass(string name)  // Implementation
    {
        Name = name;
        Initialize();
    }
}

Partial Events

// File: MyComponent.Generated.cs
public partial class MyComponent
{
    public partial event EventHandler? StatusChanged;  // Declaration
}

// File: MyComponent.cs
public partial class MyComponent
{
    public partial event EventHandler? StatusChanged
    {
        add => _statusChanged += value;
        remove => _statusChanged -= value;
    }

    private EventHandler? _statusChanged;
}

Why Is This Important?

Source generator friendly: Generators can declare the shape of constructors and events, while you control the implementation details.
Clean separation: Keep auto-generated code in separate files without merge conflicts or manual edits to generated files.
Consistency: The partial keyword now works uniformly across all member types: methods, properties, events, and constructors.

This feature is primarily aimed at source generator authors and scenarios where code is split across generated and hand-written files. If you're not using source generators, you might not need this often, but it's a welcome addition that rounds out the partial member story in C#.

Unbound Generic Types in nameof

The nameof operator returns the name of a type or member as a string. When used with generic types, it only returns the base name, ignoring type arguments:

nameof(List<int>)    // Returns "List", not "List<int>"
nameof(List<string>) // Also returns "List"

The problem? Before C# 14, you had to provide type arguments even though they're completely ignored. This forces you to make an arbitrary choice that has no effect on the result.

C# 14 lets you skip the unnecessary type arguments:

// Before C# 14 - must provide type arguments (even though they're ignored)
var name = nameof(List<int>);              // "List"
var name2 = nameof(Dictionary<int, int>);  // "Dictionary"

// C# 14 - use unbound generic types directly
var name = nameof(List<>);        // "List"
var name2 = nameof(Dictionary<,>); // "Dictionary"

Use empty angle brackets, with commas separating multiple type parameters (just like typeof(Dictionary<,>)).

This is a minor improvement, but it makes your intent clearer: "I want the name of this generic type, and the type arguments don't matter."

.NET 10 New Features

File-Based Apps

This is one of the most significant changes Microsoft has introduced. Despite being one of the most popular languages, C# has always had one major drawback: adoptability. For a new developer trying out C#, even the simplest "Hello World" console app requires a surprising amount of ceremony. You need a solution (an .sln file), a project (a .csproj file), a Program.cs file with usings, namespaces, a Program class, all before you even write your first line of code. Nobody enjoys that, even us, .NET developers who are relatively more used to that.

Compare this to languages like Python, where you can create a single .py file and immediately run print("Hello World!"). Microsoft is now pushing C# in that same direction, making it more approachable for beginners. And to be honest, this change isn't just for newcomers. I've been writing .NET for almost eight years now, and I've always missed this simplicity. Sometimes all you want to do is just test a quick snippet without spinning up an entire solution. This update finally makes that possible.

I've actually written a dedicated article about this change and why it's such a big leap forward. Check out the link below for more details.

Why I Believe 'dotnet run app.cs' Is a Huge Leap Forward

Giorgi Kobaidze ・ May 27

#dotnet #cli #softwareengineering #csharp

Alright, let's give it a try and create our own file-based app. In my repository, I've set up a folder called SingleFileApp, which contains just one file: HeyThere.cs. That's literally all you need, no additional files or setup required to run C# code.

Let's start with a simple line of code that prints a greeting message. Open your command prompt, navigate to the folder containing your file, and run the following:

Quick note: I'm using PowerShell as my CLI. The commands will be similar in other CLIs, but there may be a few subtle differences if you're using Bash or another shell.

echo 'Console.WriteLine($"Hey there {args[0]}!");' > HeyThere.cs

dotnet run .\HeyThere.cs "Folks"

Or simply:

dotnet .\HeyThere.cs "Folks"

Yes! You can actually run the file without explicitly using run. Notice that "Folks" is passed as an argument, this is used by the code to display a customized greeting message.

Now, what if your app needs external dependencies or packages?

Let's make things a bit more interesting: suppose we want to display a calendar below our greeting message. To do this, we'll use the Spectre.Console library.

If you're familiar with C#, you know that dependencies are typically defined in a .csproj file. For example, to add a dependency on this library, you would write something like this:

<ItemGroup>
  <PackageReference Include="Spectre.Console.Cli" Version="0.53.0" />
</ItemGroup>

And the .csproj file would look like the following:

Except now there's no .csproj file, because that's the whole point of the file-based app approach. So how do we handle dependencies?

Well, handling dependencies is quite easy, you just specify the required packages right in the file using the following syntax:

#:package Spectre.Console.Cli@0.53.0

The #: directive is officially called an Ignored Directive

You can even specify an SDK the similar way you specify the package, if you need to, for example, in case you need to include the Aspire AppHost SDK:

#:sdk Aspire.AppHost.Sdk@13.0.0

But we don't need the SDK at this moment so let's just focus on the package. Add the following code to the file:

#:package Spectre.Console.Cli@0.53.0

using Spectre.Console;

var calendar = new Calendar(2025, 11);
calendar.AddCalendarEvent(2025, 11, 16);
calendar.HighlightStyle(Style.Parse("blue bold"));
AnsiConsole.Write(calendar);

Since we don't have to pass any arguments, we can simply run the following command:

dotnet .\HeyThere.cs

The first time you run it, fetching all dependencies and setting everything up may take a little time. Subsequent runs will be much faster.

It will display a neat little calendar right in the console.

You can use the ignore directive for more than just packages. .csproj files contain lots of properties, and the directive can be applied there too.

#:property TargetFramework=net8.0

But what if your app also needs to reference other projects?

You can reference other projects in classic .csproj setups. If you're hoping for the same capability in file-based apps, you're in luck, it's already supported.

Imagine this: you have a class library project in your solution and want to reference it from your file-based app. Let's see how we can make that work using our example.

Let's add a class library containing a single method: string TellMeAJoke();. It will return a random, perfectly awful "knock, knock" joke.

dotnet new classlib -o KnockKnock
cd ..
dotnet sln add .\src\KnockKnock\KnockKnock.csproj

And let's add a new static class where our method will be implemented.

public static class Joke
{
    readonly static string[] jokes =
    {
        "Knock, knock.\nWho’s there?\nLettuce.\nLettuce who?\nLettuce in, it's cold out here!",
        "Knock, knock.\nWho’s there?\nCow says.\nCow says who?\nNo, silly—cow says mooooo!",
        "Knock, knock.\nWho’s there?\nTank.\nTank who?\nYou're welcome!",
        "Knock, knock.\nWho’s there?\nBoo.\nBoo who?\nAw, don’t cry!",
        "Knock, knock.\nWho’s there?\nEtch.\nEtch who?\nBless you!",
        "Knock, knock.\nWho’s there?\nNana.\nNana who?\nNana your business!",
        "Knock, knock.\nWho’s there?\nIce cream.\nIce cream who?\nICE CREAM every time I see a scary movie!",
        "Knock, knock.\nWho’s there?\nHarry.\nHarry who?\nHarry up and answer the door!",
        "Knock, knock.\nWho’s there?\nInterrupting cow.\nInterrupting cow wh—\nMOOOO!",
        "Knock, knock.\nWho’s there?\nWooden shoe.\nWooden shoe who?\nWooden shoe like to hear another joke?"
    };

    public static string TellMeAJoke()
    {
        var rnd = new Random();
        int index = rnd.Next(jokes.Length);

        return jokes[index];
    }
}

Now, we need to reference that project in our file-based app. Take a look at the screenshot:

And now let's run the application to see the output:

You can even build entire web APIs as file-based apps. To do this, you'll need a web SDK, this is exactly where the #:sdk comes into play.

You need to add the following to enable your file-based app to act like a web API:

#:sdk Microsoft.NET.Sdk.Web

Once that's set up, you can start exposing your endpoints and handling requests.

But wait, there's more!

Imagine this scenario: you wrote your code in a single file, and now you want to turn it into a full project. You don't have to do anything manually, there's a handy CLI command that converts it for you. Let's try it:

dotnet project convert .\HeyThere.cs

It will likely ask you to specify an output folder. Once you do, it will generate a new project there. If you take a look inside, you'll see that it also includes a freshly created .csproj file.

Let's open it in Visual Studio Code and take a closer look:

.cs file:

.csproj file:

.sln file

As you can see, it's now a regular .NET project with both .csproj and .sln files. The dependencies are no longer listed inside HeyThere.cs, instead they've been moved into the .csproj file, just like in a traditional setup.

Keep in mind:

If you're a beginner and just want to experiment or see how things work, the file-based app approach is a great starting point. However, for medium to large projects, I wouldn't really recommend it, it simply isn't suited for complex scenarios. Trying to manage a full enterprise application in a single .cs file quickly becomes counterproductive. .sln and .csproj files exist for a good reason, so use them to your advantage.

Validation in Minimal APIs

.NET has introduced built-in, attribute-based validation for Minimal APIs, addressing one of their biggest pain points. Previously, validation had to be handled manually. While this is not a complete disaster, it was far from ideal and often led to cluttered, harder-to-maintain code.

Let's try it out ourselves.

First things first, let's create a new minimal API.

 dotnet new webapi -o TheMostMinimalisticApiOnEarth

Now open the project in Visual Studio 2026. You'll notice quite a bit of code generated by the default template. I'll remove anything unnecessary to keep the solution clean and focused, but feel free to keep everything as is if you prefer.

Once we've removed the unnecessary pieces, add the following endpoint

This is just a dummy endpoint for testing validations, so nothing fancy is needed. It accepts a username, email, and password in the request and registers the user. Next, we'll add validation to the model. But how do we do that?

First, let's enable validations by adding the required service:

builder.Services.AddValidation();

Now, let's apply validation attributes directly to the record. Yes, you can do that! Let me show you how:

Now, let's test these properties using Postman:

It works!

When registering anywhere, you usually need to confirm your password to ensure it matches the original. You could compare passwords manually without validation attributes, but that's not particularly the best practice, this check is part of proper validation.

Let's add a ConfirmPassword property and use attributes to make sure it matches the original:

Uh-oh, looks like we have a red underline situation. Time to investigate and see what's causing the issue:

Okay, now it makes sense. Let's fix it by using the property: keyword:

The error is gone! Let's test it now. This time, we'll provide both correct values and mismatched passwords to see the validation in action.

Finally, let's enter all the correct values and see the demo end with a successful response:

Important! To ensure validations work, your classes or records must be public. If you make them internal, the request will still go through, but the validation won't run.

To be honest, I'm not entirely sure why this is the case, it's a bit counter-intuitive, but it's a quirk you need to keep in mind when using attribute-based validation in Minimal APIs.

MCP for .NET Developers

What Exactly Is MCP?

If you're not familiar with it, MCP is an open-source standard created by Anthropic for connecting AI applications to external systems. Think of it like this: you're building an app that uses an AI model, and you need that model to interact with external tools or data sources, databases, APIs, services, whatever. You can't just tell an AI model to "go get 'em" because models don’t have native access to external systems, they run in isolated environments for security and safety reasons.

Instead, you'd have to build your own API layer or integration for each external system. And if you need to connect to several of them, you end up writing a bunch of custom integrations, which quickly becomes tedious and hard to maintain.

MCP solves this by acting as a universal hub, a standardized protocol for hooking AI systems into external tools. With MCP, developers can build context-aware applications without writing custom integrations for every AI-to-system combination.

MCP in .NET

Microsoft is partnering with Anthropic to develop the official MCP SDK for .NET, with the goal of bringing first-class MCP server support to Microsoft products.

Check out the Repository and docs

There's already a project template you can use to create an MCP server yourself. To install the template, run the following command:

dotnet new install Microsoft.Extensions.AI.Templates

Once you run this script, the following templates will be installed:

And now let's create a new MCP server:

dotnet new mcpserver -n AwesomeMcpServer

Let's open Visual Studio 2026 and take a look at what the template has generated for us:

In this screenshot, you can also see the contents of the Program.cs file for the MCP server project. I won't walk through every file and folder in this template, that's a topic for a separate article, but let's open Tools/RandomNumberTools.cs to see what's inside:

As you can see, the default file includes a simple random number generator. It's not something you'd typically use in a real-world scenario, but it serves as a basic demonstration of how MCP works. At this point, you could just as easily connect to an external source, like a database, and feed real contextual data to your agent.

You know what? Let's use an in-memory storage and save all the unfunny jokes we came up with earlier in this article.

First let's add a new tool in the Tools folder containing our code:

And change the Program.cs file to include this tool instead of the random number generator:

Now let's add it to Copilot. Click the Tools button in the bottom-right corner of the Copilot chat, then click the green plus icon:

And add the new tool:

Once you do that, you'll see your tool listed in the window:

And now, I'm all set to ask my Copilot to generate either all the jokes or just a random one:

Click 'Confirm':

As you can see, it outputted all the jokes, well, you can spot three here, but the full list is much longer, and this is just a part of it.

Now, let's ask Copilot to use the second method and fetch a random joke:

Awesome isn't it?

This example is just scratching the surface, is a bit silly and simple. MCP can do much more, but as I mentioned, that deserves a separate article.

Security Improvements

WebAuthN & Passkey support have been added. Passkeys are essentially cryptographic credentials that replace traditional passwords. They're resistant to phishing, easy to use, and secure by design. Passkeys are built in into the identity framework, though this is actually inspired by an open-source technology: fido2-net-lib, which is widely adopted and reliable.

.NET project templates include passkey support by default. If you have an existing project that uses asp.net identity, you can actually add a passkey support to it, but keep in mind that you'll need a database schema migration.

Aspire 13

Support for JavaScript and Python scripts have been added. It's not .NET Aspire anymore, it's Aspire, but it still runs on .NET.

Observability & Diagnostics

Now that we've touched Aspire 13 and it's new upgrades, let's not skip one cool feature that can come in handy in quite a few cases. Let's see it by example. I'm going to generate a new Aspire Starter App from the template, check out the screenshot:

It'll generate a project with a few different projects like AppHost, ApiService, Web, and ServiceDefaults. I won't go that deep to explain what each does in details, because that'll take a whole another artile, but in short, you have a whole stack ready to go with Aspire, which can be deployed directly to Azure for example. Let's run the application and see what's in there for us:

Let's run the web application and execute a few requests. You can run the application directly from the aspire. Go to the Resources tab and click the URL in the webfrontend column. Now, let's check out the "Metrics" tab:

Go to the "Weather" tab and also the "Counter" tab and click the "Click Me" button several times.

Now let's get back to Aspire and see what has changed in the metrics:

There are a bunch of different metrics right out of the box available for us to observe the performance of the application.

OK let me show you where all this comes from:

This actually comes from OpenTelemetry, which is an observability framework. This is a a cross-platform, open standard for collecting and emitting telemetry data.

Performance

Microsoft have been doing deep refinements in Jitter, garbage collection.

.NET 10 executes high level C# with the efficiency of hand-tuned native code.

.NET 10 uses 93% less memory than .NET 8, which was already very powerful and well-performing LTS version.

Even if you don't change anything in your code and just update the version, you'll get huge performance gains.

Improved Kestrel memory pool management. Previously the memory was retained in the pool. In .NET 10, this memory can be returned to the system to use it for other purposes.

JSON deserialization performance has also improved by utilizing streaming deserialization technique, so JSON can be deserialized in stream instead of doing it all at once.

There are tons of other performance improvements that definitely deserve their own article. However, a comprehensive article already covers pretty much everything, so there's not much to add here. I'll just link it for you, definitely check out that amazing work!

Performance Improvements in .NET 10 - .NET Blog

devblogs.microsoft.com

Other Changes

Visual Studio 2026

Visual Studio 2026 now uses your system resources more efficiently. The more CPU cores you have, the more tasks it can parallelize.

Previously, the UI could hang during loading because the UI thread was blocked by ongoing tasks. In this version, those tasks are moved to background threads, keeping the interface responsive and preventing freezes.

If you're still working with good old WinForms, or have never used it but need to, Visual Studio 2026 has your back! The WinForms Expert Agent helps make the process much less painful. Building or maintaining a WinForms UI can be confusing, especially if you're dealing with a legacy, complex codebase. Think of it like having someone pair-programming with you, handling the tedious stuff so you can focus on the fun parts.

That's pretty cool, but still, please don't use WinForms for new projects, there are many modern, far superior alternatives, such as .NET MAUI.

Github Copilot App Modernization

This feature can be a real lifesaver when upgrading to .NET 10. Not only does it help with the upgrade itself, but it can also deploy your updated application to Azure. Essentially, this assistant will handle the following tasks:

Upgrade your application to .NET 10
Fix existing issues and apply best practices
Take all dependencies into account
Deploy your application to Azure

Keep in mind, this is a brand-new feature, so if you decide to fully delegate the upgrade and deployment to it, make sure to review the code and test your application thoroughly. This is especially important if you have many dependencies, a complex codebase, or an application that hasn't been touched in years.

How to use the feature?

Easy. You can right-click your solution in Visual Studio and you'll see a new menu item. Check out the screenshot below:

Alternatively, you can open the GitHub Copilot Chat window, type @modernize, and provide instructions on how you want to upgrade your code.

Keep in mind:

There are a few requirements to use this feature:

Your codebase must be written on C#.
You need to have Visual Studio 2026 or Visual Studio 2022 version 17.14.17 or newer.
GitHub copilot and GitHub Copilot app modernization for .NET enabled
Either of these Copilot subscription plans:
- Copilot Pro
- Copilot Pro+
- Copilot Business
- Copilot Enterprise

Summary

.NET 10 represents an important moment in the platform's evolution. This isn't just another incremental update, it's a comprehensive reimagining of what a modern application development framework should deliver. With C# 14's powerful language enhancements, dramatic performance improvements, simplified development workflows, and enterprise-grade LTS support, .NET 10 checks every box that matters.

At the end of the day, .NET gives you the freedom to build just about anything, making this an especially great time to be a .NET developer.

The ecosystem and community is continuously growing, check out the stats:

What We Covered

This article explored the most impactful and interesting features from my perspective.

While this article dives deep into the features I find most compelling, .NET 10 includes many other significant improvements that deserve attention:

Runtime & Performance:

Native AOT compilation enhancements with better size and startup time
Garbage collector improvements for specific workload patterns
JIT compilation optimizations for ARM64 and other architectures

Library Improvements:

LINQ performance optimizations and new methods
System.Text.Json serialization enhancements
Collections improvements and new collection types
Span and Memory improvements for zero-allocation scenarios
Regex source generators and performance improvements
Cryptography API updates

ASP.NET Core:

Blazor improvements (rendering modes, streaming rendering, enhanced navigation)
SignalR performance and reliability improvements
Middleware pipeline optimizations
Output caching enhancements
Rate limiting improvements
HTTP/3 and QUIC support enhancements
Minimal API improvements beyond validation

Data Access:

Entity Framework Core 10 features (complex types, primitive collections, JSON columns enhancements)
Database provider updates
Query performance improvements
Better database migration tooling

.NET MAUI:

Cross-platform UI improvements
Performance optimizations for mobile
New controls and gestures
Better tooling support

Cloud & Containers:

Container image size optimizations
Better Kubernetes integration
Azure-specific optimizations
Improved health checks and metrics

Developer Tools:

SDK improvements
MSBuild performance enhancements
NuGet package management improvements
Testing framework updates
Debugging experience improvements

Covering all of these in detail would require a book (or several). The features I chose to highlight are the ones I believe will have the most immediate impact on day-to-day development work and demonstrate the direction Microsoft is taking the platform.

Migration Recommendations

For New Greenfield Projects:

.NET 10 is the obvious choice: You get LTS stability (3 years of support) combined with all the latest features, performance improvements, and language enhancements. There's no reason to start a new project on an older version.

For Existing .NET 8 Applications:

Plan migration before November 2026: .NET 8 support ends in November 2026, giving you about a year to plan and execute your migration
Low-risk upgrade path: Moving from one LTS to another LTS is the safest migration strategy
Test thoroughly: While .NET typically maintains excellent backward compatibility, always run comprehensive tests, especially if you use advanced features or third-party libraries
Migration strategy: Start with non-critical services or applications to gain confidence, then progressively migrate your core systems
Performance gains: Even without code changes, you'll likely see performance improvements just from the runtime enhancements

For Existing .NET 9 Applications:

Strongly consider upgrading to .NET 10: .NET 9 support ends in May 2026 (only 18 months from release), while .NET 10 extends support until November 2028
Extend support window: Upgrading from .NET 9 to .NET 10 gives you 2.5 additional years of support
Early adopter advantage: If you adopted .NET 9 early, you're already comfortable with recent changes, making the .NET 10 migration straightforward
Minimal breaking changes: The jump from .NET 9 to .NET 10 is smaller than jumping major versions

For .NET 6 and Older Applications:

.NET 6 support already ended: If you're still on .NET 6 (support ended November 2024), migration is urgent
Multi-version jump considerations: Migrating from .NET 6 or older requires careful planning due to accumulated breaking changes
Use GitHub Copilot App Modernization: This tool can help automate much of the upgrade process and identify potential issues
Incremental migration: You can also consider migrating to .NET 8 first if .NET 10 seems too large a jump, then plan for .NET 10 before .NET 8 support ends, but I wouldn't suggest that, you don't want to do it twice.
Dependencies audit: Check all your NuGet packages and third-party libraries for .NET 10 compatibility

For Enterprise Systems:

This is your LTS release—no need to wait: .NET 10 combines cutting-edge features with the stability and long-term support enterprises require
ROI considerations: Performance improvements alone can justify the migration through reduced infrastructure costs
Risk mitigation: Establish a comprehensive testing strategy including unit tests, integration tests, and performance benchmarks
Training investment: Ensure your team is familiar with new C# 14 features and .NET 10 capabilities to maximize the benefits

General Migration Best Practices:

Audit Dependencies: Check all NuGet packages for .NET 10 compatibility. Most popular packages already support .NET 10
Run Compatibility Analyzer: Use .NET Upgrade Assistant and compatibility analyzers to identify potential issues
Monitor Performance: Establish performance baselines before migration to measure improvements
Review Breaking Changes: Check the official breaking changes documentation for your current version → .NET 10
Plan for C# 14: If your team is using new C# 14 features, ensure everyone understands them through code reviews and documentation
Update CI/CD Pipelines: Update build agents and deployment scripts to use .NET 10 SDK
Container Image Updates: Update base images to .NET 10 runtime images

Final Thoughts

The timing couldn't be better for .NET 10. Organizations currently on .NET 8 LTS have a clear upgrade path to another LTS release with significant improvements. .NET 9 adopters can extend their support window by 2.5 years and gain substantial performance benefits. And teams starting new projects get the best of both worlds: cutting-edge capabilities wrapped in enterprise-grade support commitments.

.NET 10 isn't just about adding features, it's about refining the entire development experience. From simplifying the getting-started experience with file-based apps to providing enterprise-grade observability and performance, every change feels intentional and well-considered.

Microsoft has consistently demonstrated their commitment to making .NET the best platform for building modern applications, whether you're creating cloud-native microservices, AI-powered applications, cross-platform mobile apps, or high-performance backend systems. .NET 10 continues this tradition while pushing the boundaries of what's possible with a managed runtime.

If you've been on the fence about upgrading or adopting .NET, this is your release. The combination of LTS stability, dramatic performance improvements, developer productivity enhancements, and future-forward features like AI integration makes .NET 10 an easy choice for serious application development.

The .NET platform has never been in a better position. With .NET 10, Microsoft isn't just keeping pace with modern development needs, they're setting the standard for what a world-class application framework should deliver. This is the release that proves .NET isn't just relevant in 2025, it's essential.

If you found this article helpful, consider checking out the playground repository to run these examples yourself. Feel free to share your .NET 10 migration experiences or questions in the comments below. Happy coding!

Thank you for reading, and happy holidays!❄️☃️🎄🎉

Table of Contents

Introduction

Microsoft's Boldest .NET Release Yet

What This Article Covers and Who Should Read It?

.NET Support Policy

Playground Repository

georgekobaidze / dotnet10-playground

Kickstarting a .NET Solution from Scratch with the CLI

Giorgi Kobaidze ・ May 15

C# 14: Language Features

Extension Members

Syntax

Example

Null Conditional Assignment

Why Is This Important?

Demo Example

The Old Way vs. The New Way

Field Access in Auto Properties

Why Is This Important?

Demo Example

The Old Way vs. The New Way

Why Did This Take So Long?

Important Notes

Simple Lambda Parameters With Modifiers

Supported Modifiers

The Old Way vs. The New Way

User-Defined Compound Assignment Operators

Demo Example

Why Is This Important?

The Old Way vs. The New Way

Partial Events and Constructors

Partial Constructors

Partial Events

Why Is This Important?

Unbound Generic Types in nameof

.NET 10 New Features

File-Based Apps

Why I Believe 'dotnet run app.cs' Is a Huge Leap Forward

Giorgi Kobaidze ・ May 27

Validation in Minimal APIs

MCP for .NET Developers

What Exactly Is MCP?

MCP in .NET

Security Improvements

Aspire 13

Observability & Diagnostics

Performance

Other Changes

Visual Studio 2026

Github Copilot App Modernization

Summary

What We Covered

Migration Recommendations

Final Thoughts