.NET 10 in 2026: Nieuwe Functies, Native AOT en Sollicitatievragen

.NET 10 is in november 2025 uitgebracht als de nieuwste Long-Term Support (LTS) release van het Microsoft .NET-platform. Met drie jaar gegarandeerde ondersteuning tot november 2028 biedt deze versie een stabiele basis voor enterprise-applicaties, cloud-native ontwikkeling en nieuwe projecten. De release combineert diepgaande runtime-verbeteringen, de introductie van C# 14 als taalversie en aanzienlijke stappen vooruit op het gebied van Native AOT-compilatie. Dit artikel behandelt de belangrijkste nieuwe functies en sluit af met praktische kennispunten voor technische sollicitatiegesprekken.

Runtime-verbeteringen: JIT, hardwareversnelling en benchmarks

De .NET 10-runtime bevat substantiele verbeteringen in de Just-In-Time (JIT) compiler. Geavanceerde optimalisaties voor method inlining, devirtualisatie en stack-allocaties zorgen voor meetbaar betere prestaties in real-world scenario's. Benchmarks tonen 8 tot 12 procent lagere geheugenallocaties in typische ASP.NET Core request-pipelines.

Op het gebied van hardwareversnelling ondersteunt .NET 10 nu Intel AVX10.2 en Arm64 SVE-instructies. Verbeterde loop inversion en stack allocation verminderen de druk op de garbage collector, wat resulteert in consistentere responstijden onder belasting. De combinatie van deze optimalisaties maakt .NET 10 tot de snelste .NET-release tot nu toe voor server-workloads.

De codegeneratie voor struct-typeargumenten produceert compactere en snellere methodeaanroepen. Voor bestaande applicaties betekent dit dat een upgrade naar .NET 10 direct meetbare prestatiewinst kan opleveren, zelfs zonder codewijzigingen. De runtime past de nieuwe optimalisaties automatisch toe op bestaande IL-code.

Native AOT-compilatie bereikt productiegereedheid

Native Ahead-of-Time (AOT) compilatie heeft in .NET 10 een nieuw niveau van volwassenheid bereikt. De technologie compileert .NET-applicaties naar native machinecode, waardoor de JIT-compiler en het volledige .NET runtime-framework niet meer nodig zijn bij uitvoering. Dit levert ingrijpende verbeteringen op in opstarttijd, geheugengebruik en executable-grootte.

De cijfers spreken voor zich: een standaard console-applicatie compileert naar een binary van ongeveer 1 MB. Voor serverless en container-workloads rapporteren AWS Lambda-benchmarks een verbetering van 86 procent in cold start-tijden door het elimineren van JIT-compilatie. Server-workloads tonen 30 tot 40 procent betere runtime-prestaties.

Een minimale API met Native AOT ziet er als volgt uit:

var builder = WebApplication.CreateSlimBuilder(args);

builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.TypeInfoResolverChain.Insert(
        0, AppJsonSerializerContext.Default);
});

var app = builder.Build();

app.MapGet("/health", () => Results.Ok(new HealthResponse("ok", DateTime.UtcNow)));

app.Run();

record HealthResponse(string Status, DateTime Timestamp);

[JsonSerializable(typeof(HealthResponse))]
internal partial class AppJsonSerializerContext : JsonSerializerContext { }

Het inschakelen van Native AOT vereist slechts twee eigenschappen in het projectbestand:

<!-- app.csproj -->
<PropertyGroup>
    <PublishAot>true</PublishAot>
    <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

De WebApplication.CreateSlimBuilder is specifiek ontworpen voor AOT-scenario's en laadt alleen de minimaal benodigde services. De JsonSerializerContext is noodzakelijk omdat reflection niet beschikbaar is in een AOT-gecompileerde applicatie -- source generators nemen de rol van runtime-reflectie over voor JSON-serialisatie. De assembly-metadata IsAotCompatible, geintroduceerd in .NET 10, stelt bibliotheekauteurs in staat hun packages expliciet als AOT-compatibel te markeren.

C# 14: Extension Members

Extension members vormen het meest in het oog springende nieuwe taalfeature van C# 14. Waar extension methods sinds C# 3.0 bestaan, waren ontwikkelaars beperkt tot het toevoegen van methoden aan bestaande typen. Properties, operators en statische members waren niet mogelijk als extensions. C# 14 heft deze beperking op met een nieuwe syntaxis op basis van het extension-keyword.

De nieuwe syntax groepeert gerelateerde extension members in een blok en maakt het mogelijk om naast methoden ook properties en statische leden te definieren:

public static class StringExtensions
{
    extension(string source)
    {
        // Extension property — called as source.IsNullOrEmpty
        public bool IsNullOrEmpty => string.IsNullOrEmpty(source);

        // Extension property — called as source.WordCount
        public int WordCount =>
            source.IsNullOrEmpty ? 0 : source.Split(' ',
                StringSplitOptions.RemoveEmptyEntries).Length;
    }

    extension(string)
    {
        // Static extension method — called as string.Join(",", items)
        public static string Repeat(string value, int count) =>
            string.Concat(Enumerable.Repeat(value, count));
    }
}

Het eerste extension(string source)-blok definieert instance members die worden aangeroepen op een specifieke string-instantie. Het tweede blok extension(string) zonder parameternaam definieert statische members die worden aangeroepen op het type zelf. Deze scheiding maakt het helder of een extension member op een instantie of op het type werkt.

Bestaande extension methods blijven volledig functioneren. De nieuwe syntaxis is achterwaarts compatibel en additief. Een belangrijke kanttekening: fields, events, indexers, geneste typen en constructors worden nog niet ondersteund in extension blocks. Bij conflicten tussen een extension member en een lid van het onderliggende type heeft het type altijd voorrang.

Het field-keyword: minder boilerplate voor properties

Het field-keyword in C# 14 lost een veelvoorkomende ergonomische ergernis op. Tot nu toe moest een ontwikkelaar bij elke property met validatielogica in de setter een apart privaat veld declareren. Het nieuwe field-keyword verwijst naar een door de compiler gegenereerd backing field, wat de noodzaak voor handmatige velddeclaraties elimineert.

public class UserProfile
{
    // Before C# 14: required a private string _email field
    public string Email
    {
        get;
        set => field = value ?? throw new ArgumentNullException(nameof(value));
    }

    public int Age
    {
        get;
        set => field = value >= 0 && value <= 150
            ? value
            : throw new ArgumentOutOfRangeException(nameof(value));
    }
}

De Email-property gebruikt field in de setter om null-waarden af te wijzen, terwijl de getter de standaard auto-property blijft. De Age-property combineert bereikvalidatie met het field-keyword. In beide gevallen genereert de compiler het backing field automatisch, waardoor de klasse compacter en leesbaarder wordt.

Let op: als een klasse al een lid heeft met de naam field, heeft het nieuwe keyword voorrang en schaduwt het bestaande lid. In dat geval kan @field of this.field worden gebruikt voor disambiguatie.

File-based apps: C# zonder projectbestanden

Een opvallende toevoeging in .NET 10 is de mogelijkheid om een enkel .cs-bestand direct uit te voeren zonder project- of solution-bestanden. Dit plaatst C# op gelijke voet met scripttalen zoals Python en JavaScript voor snelle prototypes, CLI-hulpprogramma's en automatiseringsscripts.

NuGet-packages worden via speciale #:-directives bovenaan het bestand gerefereerd:

#:package System.Text.Json@9.*

using System.Text.Json;

var data = new { Name = "SharpSkill", Year = 2026 };
Console.WriteLine(JsonSerializer.Serialize(data));

Het bestand wordt uitgevoerd met dotnet run hello.cs, zonder dat een csproj of sln nodig is. File-based apps compileren standaard naar Native AOT en ondersteunen publicatie naar native executables via dotnet publish. Voor CI/CD-pipelines en developer tooling verlaagt dit de drempel om C# in te zetten waar voorheen een shellscript of Python-script werd gebruikt.

Null-conditional assignment

De null-conditional operators ?. en ?[] kunnen in C# 14 nu ook aan de linkerkant van een toewijzing worden gebruikt. Dit elimineert veelvoorkomende null-checks die voorheen meerdere regels code in beslag namen.

public class OrderService
{
    public void ProcessOrder(Customer? customer, Order order)
    {
        // Before C# 14
        if (customer is not null)
        {
            customer.LastOrder = order;
            customer.OrderCount += 1;
        }

        // C# 14 — null-conditional assignment
        customer?.LastOrder = order;
        customer?.OrderCount += 1;
    }
}

Belangrijk detail: de rechterzijde van de toewijzing wordt alleen geevalueerd wanneer de linkerzijde niet null is. Dit voorkomt onnodige berekeningen en mogelijke side-effects. Compound assignment operators zoals += en -= worden ondersteund, maar increment (++) en decrement (--) zijn bewust uitgesloten.

De formele semantiek van P?.A = B is equivalent aan if (P is not null) P.A = B;, met de garantie dat P slechts eenmaal wordt geevalueerd. Dit maakt de constructie veilig voor gebruik met properties die side-effects hebben bij evaluatie.

ASP.NET Core 10 en Blazor

ASP.NET Core 10 levert de breedste set verbeteringen in de Blazor-stack tot nu toe, naast significante updates voor API-ontwikkeling en beveiliging.

Passkey-authenticatie is nu ingebouwd in ASP.NET Core Identity. Op basis van de WebAuthn/FIDO2-standaard kunnen gebruikers inloggen zonder wachtwoord, met behulp van biometrische sensoren of hardware-sleutels. Het Blazor Web App-projecttemplate biedt kant-en-klare UI-componenten voor passkey-beheer. Configuratie verloopt via de IdentityPasskeyOptions-klasse met instellingen voor ServerDomain, AuthenticatorTimeout en ChallengeSize.

OpenAPI 3.1 wordt nu native ondersteund, inclusief YAML-export. De ingebouwde OpenAPI-generator vervangt de afhankelijkheid van Swashbuckle. Minimal APIs ondersteunen nu ingebouwde validatie met Data Annotations, waardoor externe bibliotheken zoals FluentValidation niet langer noodzakelijk zijn voor basisvalidatie.

Blazor-prestatieverbeteringen omvatten WebAssembly prefetching voor snellere waargenomen laadtijden, circuit state persistence voor het behouden van sessiestate bij verbindingsverlies, en een verbeterd reconnection-UI via het nieuwe ReconnectModal-component. Het Blazor-script wordt nu als static web asset geserveerd met automatische compressie en fingerprinting.

Automatisch geheugenpool-beheer in de Kestrel-webserver geeft ongebruikte buffers uit de geheugenpool automatisch vrij, wat de geheugenvoetafdruk voor langlopende services verkleint. Daarnaast retourneren API-endpoints die beschermd zijn met cookie-authenticatie nu correct 401- en 403-statuscodes in plaats van een redirect naar de loginpagina, beter afgestemd op REST-conventies.

Entity Framework Core 10: Named Query Filters

Een van de meest gewilde features voor EF Core is eindelijk gerealiseerd: named query filters. In eerdere versies kon per entiteitstype slechts een enkele global query filter worden gedefinieerd. Meerdere filtercondities moesten in een enkele expressie met &&-operators worden gecombineerd, en IgnoreQueryFilters() schakelde altijd alle filters tegelijk uit -- met het risico dat beveiligingsfilters onbedoeld werden omzeild.

EF Core 10 maakt het mogelijk om meerdere benoemde filters per entiteit te definieren en deze selectief uit te schakelen:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<BlogPost>(entity =>
    {
        entity.HasQueryFilter("SoftDelete", p => !p.IsDeleted);
        entity.HasQueryFilter("Published", p => p.Status == PostStatus.Published);
        entity.HasQueryFilter("CurrentTenant", p => p.TenantId == _tenantId);
    });
}

// Selectively disable filters
var drafts = await context.BlogPosts
    .IgnoreQueryFilter("Published")
    .ToListAsync();

Dit patroon is bijzonder waardevol voor applicaties die soft delete, multi-tenancy en publicatiestatus combineren. De IgnoreQueryFilter-methode accepteert de naam van het specifieke filter dat moet worden uitgeschakeld, terwijl de overige filters actief blijven. Zonder parameternaam schakelt IgnoreQueryFilters() alle filters uit, wat achterwaarts compatibel is met het bestaande gedrag.

Een aanbeveling vanuit de community is om filternamen als constanten of enums te definieren in plaats van hardcoded strings, om typefouten en onbedoeld gedrag te voorkomen. Gefilterde kolommen zoals IsDeleted en TenantId moeten geindexeerd zijn voor optimale queryprestaties.

Interview-Ready Takeaways

Voor ontwikkelaars die zich voorbereiden op technische sollicitatiegesprekken voor .NET-posities zijn de volgende kennispunten essentieel:

Native AOT -- Interviewers vragen regelmatig naar de trade-offs van AOT versus JIT-compilatie. Belangrijke punten: AOT elimineert opstarttijd door vooraf te compileren, maar ondersteunt geen runtime code-generatie of onbeperkte reflectie. De JsonSerializerContext met source generators is het standaardpatroon voor JSON-serialisatie in AOT-scenario's. Hybride AOT/JIT-compilatie biedt een middenweg voor applicaties die zowel snelle opstart als dynamische codegeneratie nodig hebben.

C# 14 Extension Members -- Het verschil met klassieke extension methods is dat de nieuwe syntax ook properties, operators en statische members ondersteunt. Extension blocks groeperen gerelateerde extensions. Bij conflicten tussen een extension member en een lid van het onderliggende type heeft het type altijd voorrang.

Het field-keyword -- Dit is een ergonomische verbetering, geen fundamentele taalverandering. Het elimineert de noodzaak voor handmatige backing fields bij properties met validatielogica. De compiler genereert het veld automatisch. Het onderscheid weten tussen situaties waarin field volstaat en wanneer een volledige handmatige implementatie noodzakelijk blijft, toont diepgaande taalkennis.

EF Core 10 Named Query Filters -- Het belangrijkste conceptuele punt is dat filters nu onafhankelijk van elkaar kunnen worden beheerd. Dit voorkomt het per ongeluk uitzetten van beveiligingsfilters (zoals tenant-isolatie) wanneer alleen een soft-delete filter moet worden omzeild.

File-based apps -- Deze functie demonstreert de verschuiving van C# naar een breder toepassingsgebied, inclusief scripting en CLI-tooling. File-based apps compileren standaard naar Native AOT.

Conclusie

.NET 10 LTS levert een breed scala aan verbeteringen die de gehele ontwikkelstack raken:

• Runtime: 8-12% lagere geheugenallocaties, AVX10.2 en Arm64 SVE-ondersteuning, verbeterde JIT-optimalisaties voor method inlining en devirtualisatie
• Native AOT: binaries van circa 1 MB, 86% snellere cold starts op serverless platforms, productiegereed voor web-API's en CLI-tooling
• C# 14: extension members met properties en statische leden, het field-keyword voor compactere property-definities, null-conditional assignment, en file-based apps zonder projectbestanden
• ASP.NET Core 10: passkey-authenticatie, native OpenAPI 3.1 met YAML-export, Blazor WebAssembly prefetching en automatisch geheugenpool-beheer
• EF Core 10: named query filters voor fijnmazige controle over global filters bij soft delete, multi-tenancy en publicatiestatus

De combinatie van LTS-stabiliteit, prestatieverbeteringen en moderne taalfeatures maakt .NET 10 een aantrekkelijke upgrade voor zowel greenfield-projecten als bestaande applicaties. Ontwikkelaars die deze concepten beheersen, zijn goed voorbereid op technische gesprekken en productieontwikkeling met het .NET-ecosysteem.