Fi del suport de .NET 8 i .NET 9 el 10 de novembre: què passa i com passar a .NET 10

El 10 de novembre del 2026, .NET 8 i .NET 9 deixen de rebre pedaços. Si tens una API o una aplicació web en qualsevol de les dues, el dia 11 continuarà arrencant com si res. I precisament per això és fàcil deixar-ho per més endavant.

L’últim any he passat a .NET 10 dues aplicacions en producció: E3M, l’ERP d’EPMTIC, des de .NET 8, i Power Time, des de .NET 9. Aquí t’explico què vol dir el final del suport, què va canviar en aquestes migracions i quins passos seguiria si ho hagués de fer aquesta setmana.

Què vol dir “fi del suport” (i què no)

Segons l’anunci de Microsoft, a partir del 10 de novembre no hi haurà més actualitzacions de manteniment, correccions de seguretat ni suport tècnic per a .NET 8 ni per a .NET 9. És possible que totes dues rebin una última actualització aquell mateix dia si hi ha un problema crític conegut. Després, s’ha acabat.

La teva aplicació no s’apaga. El que passa és més silenciós: quan es publiqui la propera vulnerabilitat del runtime o d’ASP.NET Core, el pedaç sortirà per a les versions amb suport i no per a la teva. Si l’aplicació està exposada a internet, aquest forat queda obert.

Dos aclariments:

• .NET 9 s’acaba alhora que .NET 8 perquè Microsoft va ampliar el suport de les versions STS de 18 a 24 mesos. Havia d’acabar al maig i es va moure al novembre.
• .NET Framework 4.8 no és en aquesta llista. Té suport com a part de Windows. Si la teva aplicació és de Web Forms o WinForms sobre .NET Framework, el teu problema és diferent (en parlo al final), però no té data el 10 de novembre.

I si encara ets a .NET 6, fa des del novembre del 2024 que no tens pedaços.

El destí és .NET 10, que és LTS i té suport fins al 14 de novembre del 2028.

Com van anar dues migracions reals

Power Time, de .NET 9 a .NET 10. El canvi va cabre en un commit de 18 fitxers. La major part va ser de projecte: pujar la versió, actualitzar paquets i canviar les imatges de Docker. Vaig aprofitar per centralitzar les versions dels paquets en un Directory.Packages.props, que és el que va tocar més fitxers. En codi hi va haver tres ajustos petits: el transformador de l’esquema de seguretat d’OpenAPI, el nom d’una propietat de les capçaleres reenviades (KnownNetworks passa a KnownIPNetworks) i la creació de credencials al servei de notificacions push, per l’actualització del seu paquet.

E3M, de .NET 8 a .NET 10. Aquí hi ha dues coses que val la pena explicar.

La primera té a veure amb la configuració. A .NET 10, el proveïdor de configuració JSON ja no converteix els null en cadenes buides: ara arriben com a null i s’enllacen com a tals. Una clau que estigui a null en un appsettings.json i que el codi tracti com a “buida, fes servir el valor per defecte” passa a ser null. A E3M no hi havia cap null a la configuració, però el codi donava per fet que aquelles claus existien. Abans de desplegar vaig afegir una validació en arrencar de les claus obligatòries, amb un missatge que diu exactament quina falta.

La segona: en actualitzar va sortir deute que ja hi era. Tres camps eren NOT NULL a la base de dades, però el model d’Entity Framework els veia com a opcionals. No era un problema de .NET 10; feia temps que era així i ningú no se n’havia adonat. Ho va detectar dotnet ef migrations has-pending-model-changes, que vaig executar abans i després de pujar de versió. Millor que surti a la teva màquina que en producció.

També va canviar l’API de seguretat de Swashbuckle 10: si declares el requisit de seguretat amb AddSecurityRequirement, cal adaptar-lo a OpenApiSecuritySchemeReference i al nou espai de noms Microsoft.OpenApi.

Els passos, en ordre

Així ho faria avui amb una aplicació ASP.NET Core en .NET 8 o 9.

1. Fixa l’SDK. Un global.json a l’arrel evita que cada màquina o cada pipeline compili amb un SDK diferent:

{
  "sdk": {
    "version": "10.0.100",
    "rollForward": "latestFeature"
  }
}

2. Canvia el framework de destí a cada projecte (o una sola vegada a Directory.Build.props si el tens):

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

3. Actualitza els paquets de Microsoft (Microsoft.AspNetCore.*, Microsoft.EntityFrameworkCore.*, Microsoft.Extensions.*) a la versió 10 i revisa els de tercers. Swashbuckle, per exemple, té canvis propis a la versió 10.

4. Canvia les imatges de Docker:

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
# ...
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime

5. Valida la configuració en arrencar. És la defensa contra el canvi dels null, i val la pena encara que no migris:

using System.ComponentModel.DataAnnotations;

public sealed class JwtOptions
{
    [Required] public string Key { get; set; } = "";
    [Required] public string Issuer { get; set; } = "";
    [Required] public string Audience { get; set; } = "";
}

builder.Services.AddOptions<JwtOptions>()
    .Bind(builder.Configuration.GetSection("Jwt"))
    .ValidateDataAnnotations()
    .ValidateOnStart();

Si alguna clau falta, o arriba com a null o buida, l’aplicació falla en arrencar amb un error que anomena la propietat, en lloc de fallar a la primera petició que la faci servir.

6. Comprova el model de dades. Si fas servir Entity Framework Core (amb l’eina dotnet-ef i el paquet Microsoft.EntityFrameworkCore.Design), aquesta ordre et diu si el model i les migracions estan desalineats, que és justament el que em vaig trobar a E3M. Executa-la una vegada per cada DbContext:

dotnet ef migrations has-pending-model-changes --context ElMeuDbContext

7. Llegeix les llistes de canvis incompatibles de .NET 9 (si véns de .NET 8) i de .NET 10, filtrant pel que fas servir. Després, passa els tests i desplega primer en un entorn de proves.

Una nota sobre eines: Microsoft ha marcat com a obsolet el .NET Upgrade Assistant i recomana en el seu lloc l’agent de modernització de GitHub Copilot. Per a un salt de .NET 8 a .NET 10 amb una bona bateria de tests, segons la meva experiència no cal un assistent de migració específic: el canvi és assequible i entendre cada ajust compensa.

Si el teu és .NET Framework

Si la teva aplicació és a .NET Framework 4.8 (o a 4.6.2 o posterior; les anteriors ja no tenen suport), no tens la urgència del 10 de novembre, però el salt és un altre. Web Forms no existeix a .NET modern, així que no és canviar una versió: cal refer la capa web conservant la lògica de negoci. És el que faig a la modernització d’aplicacions .NET, i l’estratègia (de cop o per parts) l’explico a modernitzar un ERP legacy.

El que faria aquesta setmana

Obre un terminal a la carpeta on tinguis els teus repositoris i busca quina versió fa servir cada projecte:

grep -r --include='*.csproj' --include='Directory.Build.props' "<TargetFramework" .

Si hi veus net8.0, net9.0 o, pitjor, net6.0 en alguna cosa que és en producció, ja saps què cal planificar. Si són moltes aplicacions, o no tens tests que et donin confiança, comença per una auditoria tècnica: en una setmana et diu què hi ha, què es trenca en pujar de versió i en quin ordre fer-ho.

Recursos

• Anunci de Microsoft: fi del suport de .NET 8 i .NET 9
• Política de suport de .NET
• Canvis incompatibles a .NET 9
• Canvis incompatibles a .NET 10
• Serveis de modernització de VisibleSoft