.NET 11 est là : ce qui change vraiment (runtime, perf, ASP.NET Core, C# 15)

.NET 11 arrive avec un nouveau cycle (préviews) et la version de langage associée (C# 15). L’objectif de cet article : t’aider à décider quand l’adopter, comment le tester, et surtout comment upgrader sans casser (perf, CI, Docker, libs, breaking changes).

---

Sommaire

• 1) Installer .NET 11 (SDK) + vérifier ta config
• 2) Quoi de neuf : runtime, libs, SDK — comment l’évaluer
• 3) Focus C# 15 : activation, usage, migration progressive
• 4) Focus ASP.NET Core 11 : pipeline “clean”, endpoints, perf et sécurité
• 5) Upgrade guide : étapes réelles (CI, NuGet, Docker, tests, breaking changes)
• 6) Checklist production : ce que je coche avant de livrer

---

1) Installer .NET 11 (SDK) + vérifier ta config

Avant de parler “nouveautés”, le plus important : contrôler ton environnement. En preview, tu veux éviter les surprises “ça marche sur ma machine”.

1.1 Vérifier les SDK installés

# Liste tous les SDK installés
dotnet --list-sdks

# Version active
dotnet --version

# Infos runtime
dotnet --info

1.2 Pinner le SDK avec global.json

Si tu bosses en équipe, c’est obligatoire. Tu peux pin une preview pour tester, sans impacter les autres repos.

{
  "sdk": {
    "version": "11.0.100-preview.1",
    "rollForward": "latestFeature"
  }
}

1.3 Créer un projet “sandbox” (conseillé)

Astuce : crée un mini projet pour valider tooling / build / publish / docker.

dotnet new webapi -n Net11Sandbox
cd Net11Sandbox
dotnet run

---

2) Quoi de neuf : runtime, libs, SDK — comment l’évaluer

À chaque version .NET, il y a 2 questions simples :

• Est-ce que ça améliore mon cas réel ? (p95/p99, allocations, cold start, throughput)
• Est-ce que ça casse quelque chose ? (breaking changes, packages, Docker, CI)

2.1 Le bon test : bench p95/p99 + allocations (pas “feeling”)

La meilleure façon d’évaluer une nouvelle version, c’est de mesurer : latence (p95/p99), allocations et CPU.

2.2 Un exemple concret : mesurer allocations dans un handler

Voici une version “API style” : on veut éviter la création inutile d’objets/strings.

// Exemple : endpoint qui formate une réponse
// Objectif : réduire allocations inutiles et string concat

app.MapGet("/v1/search", (string q) =>
{
    if (string.IsNullOrWhiteSpace(q))
        return Results.BadRequest(new { error = "Missing query" });

    // Exemple simple : prépare une réponse sans allocations inutiles
    var normalized = q.Trim(); // ok
    var result = new
    {
        query = normalized,
        count = 0,
        items = Array.Empty<object>()
    };

    return Results.Ok(result);
});

Ce n’est pas “.NET 11 feature”, c’est une manière de travailler : tu testes la nouvelle version en gardant ton code clean, puis tu compares les métriques.

2.3 SDK / Tooling : ce que tu veux valider

• Build + publish (local)
• Build + tests (CI)
• Publish Linux container (si tu déploies en Docker)
• NuGet restore (versions et compat)

---

3) Focus C# 15 : activation, usage, migration progressive

La bonne approche : tu testes C# 15 sans “forcer” l’équipe à migrer tout le code. Tu actives preview sur un repo sandbox ou une branche, et tu utilises les features uniquement dans les parties “safe”.

3.1 Activer C# preview (propre)

<PropertyGroup>
  <LangVersion>preview</LangVersion>
</PropertyGroup>

3.2 Une stratégie que j’aime : “feature gate” par projet

Si tu as une solution multi-projets, tu peux activer preview uniquement sur :

• un projet “sandbox”
• un projet “tooling” interne
• ou un microservice isolé

3.3 Exemples de style moderne (valables dès maintenant)

Même sans C# 15, tu peux adopter un style “modern C#” :

// 1) Null-coalescing assignment
items ??= new List<string>();

// 2) Switch expressions pour business rules
var status = code switch
{
    200 => "OK",
    401 => "Unauthorized",
    404 => "NotFound",
    _   => "Other"
};

// 3) Pattern matching simple
if (payload is { Length: > 0 })
{
    // ...
}

Résultat : ton code est déjà “upgrade-friendly” et tu réduis le risque lors d’un passage à une nouvelle version.

---

4) Focus ASP.NET Core 11 : pipeline clean, endpoints, perf et sécurité

Quand tu upgrades ASP.NET Core, les problèmes arrivent souvent dans : middleware order, auth, CORS, proxy, headers, et la config “prod”.

4.1 Starter API propre (base solide)

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Exemple : CORS (si front React)
builder.Services.AddCors(opt =>
{
    opt.AddPolicy("web", p =>
        p.WithOrigins("https://ton-front.fr", "http://localhost:3000")
         .AllowAnyHeader()
         .AllowAnyMethod()
         .AllowCredentials());
});

var app = builder.Build();

app.UseHttpsRedirection();

app.UseCors("web");

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.MapGet("/health", () => Results.Ok(new { status = "ok" }));

app.Run();

4.2 Sécurité : 6 protections “cheap but strong”

• HTTPS only + redirect
• CORS strict (origins exactes)
• Headers (X-Content-Type-Options, X-Frame-Options, etc.)
• Rate limiting sur endpoints sensibles (login, otp, search)
• Validation input (length, regex, null)
• Logging sans PII (surtout en auth)

4.3 Exemple : rate limiting simple (pattern)

Si tu ne veux pas dépendre d’un framework, tu peux déjà limiter certaines actions côté infra (reverse proxy), ou côté app (middleware). Exemple “pattern” :

// Pattern: limiter un endpoint "login" (pseudo logique)
app.MapPost("/auth/login", async (HttpContext ctx) =>
{
    // Ici : check IP / user agent / counters (redis/ mémoire)
    // Puis valider les creds
    await Task.CompletedTask;
    return Results.Ok(new { ok = true });
});

L’idée : même si tu changes de version .NET, ta posture sécurité reste stable.

---

5) Upgrade guide : étapes réelles (CI, NuGet, Docker, tests, breaking changes)

Voici le workflow “pro” que j’applique sur les upgrades (simple mais robuste).

5.1 Étape 0 : branche dédiée + pipeline CI séparé

git checkout -b upgrade/net11

5.2 Étape 1 : pin du SDK (global.json)

(Tu l’as déjà) → ça évite 90% des “bugs fantômes”.

5.3 Étape 2 : upgrade du TargetFramework

Dans tes .csproj :

<TargetFramework>net11.0</TargetFramework>

5.4 Étape 3 : NuGet + compat

Sur une upgrade, ce qui casse le plus souvent : packages vieux / transitive dependencies. Une routine simple :

# Liste les packages (top-level)
dotnet list package

# Restore propre
dotnet restore

# Build
dotnet build -c Release

5.5 Étape 4 : tests (unit + integration + smoke)

dotnet test -c Release

5.6 Étape 5 : Docker (si prod en container)

Exemple Dockerfile minimal (à adapter) :

# ---- Build
FROM mcr.microsoft.com/dotnet/sdk:11.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

# ---- Run
FROM mcr.microsoft.com/dotnet/aspnet:11.0
WORKDIR /app
COPY --from=build /app/publish .
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "YourApp.dll"]

5.7 Étape 6 : Breaking changes — check ciblé

Ne lis pas tout. Fais un scan “pratique” :

• Auth/JWT
• Serialization (System.Text.Json options)
• HTTP pipeline / middlewares
• Hosting / environment variables
• Packages critiques (EF Core, Identity, OpenTelemetry, etc.)

---

6) Checklist production : ce que je coche avant de livrer

---

Conclusion

.NET 11, ce n’est pas juste “une nouvelle version”. C’est surtout une opportunité de : re-mesurer ton système, solidifier ton upgrade process, et améliorer ton delivery.

Si tu veux, je peux aussi te préparer :

• ✅ une version “API production” plus avancée (auth, health checks, OpenAPI clean, middlewares)
• ✅ un template CI (GitHub Actions / Azure DevOps) dédié upgrade
• ✅ un mini “perf harness” (p95/p99 + allocations) prêt à lancer en 1 commande