.NET 8 ve 9 Destek Bitişi: Deployment Odaklı Geçiş Kontrol Listesi
Microsoft, 10 Kasım 2026'da .NET 8 ve .NET 9 desteğini bitiriyor; .NET 10'a geçmeyen uygulamalar security fix almıyor olacak. Yeni bir deployment odaklı kontrol listesi, gerçekte neyin çalıştığını envanterleme, minimum riskle retarget ve artifact seviyesinde test ile rollback provasıyla geçişi kanıtlama yolunu anlatıyor.
Kilit noktalar
- Hem .NET 8 hem .NET 9 için destek 10 Kasım 2026'da bitiyor; LTS olan .NET 10 Kasım 2028'e kadar destekli.
- Sadece csproj dosyaları değil, dağıtılmış artifact'lar envantere girmeli: container, job, slot, recovery ortamı ve tedarikçi uygulamaları.
- Framework-dependent ve self-contained uygulamalar runtime'ı farklı taşır; host'taki runtime listesi tek başına kanıt değildir.
- Önce aynı deployment modeliyle net10.0'a geçin; Native AOT veya şema değişikliğini ayrı release'lere bırakın.
- Dev server'da source yerine publish edilmiş release candidate'ı test edin; auth, serialization, persistence ve diagnostics senaryolarını tekrarlayın.
- Trafiği artırmadan rollback provası yapın; artifact, runtime, test sonuçları ve patch sorumlusunu kanıt kaydına yazın.
Microsoft, 10 Kasım 2026'da hem .NET 8 hem de .NET 9 desteğini sonlandırıyor; bu tarihten sonra security fix ve servicing gelmeyecek, uygulamalar çalışmaya devam etse de desteklenmeyecek. Yazıya göre gerçek kapsam proje dosyaları değil, dağıtılmış her artifact: repo net10.0 hedeflese bile container, scheduled job, deployment slot veya tedarikçi uygulaması eski runtime ile çalışıyor olabilir.
Önerilen yol deployment odaklı: her servis için owner, target framework, hosting modeli ve artifact kimliği kaydedilir; deployment modeli değiştirilmeden net10.0'a geçilir; ardından dev server yerine publish pipeline'ından çıkan release candidate test edilir. .NET 10 breaking change kataloğu üzerinden uyumluluk kontrol edilir, schema uyumluluğu dahil rollback prova edilir ve runtime patch sorumlusunu belirten bir kanıt kaydıyla iş kapatılır.
Gerçek dünyada kullanımı
- Repo'su net10.0 hedefleyen ama production container image'ı hâlâ eski runtime stage'ini çalıştıran bir ekip.
- Kendi web API'lerinin yanında Windows servisleri, cron job'ları ve tedarikçi uygulamalarını da izlemek zorunda olan bir platform grubu.
- Yeni sürümün yıkıcı bir şema değişikliği yapması yüzünden rollback'i kırılan bir migration.
- Test edilen artifact'ların ve gelecekteki runtime patch sorumlusunun kayıtlı olduğu denetlenebilir bir kayıt isteyen release yöneticisi.
Neden önemli
O tarihten sonra security fix gelmeyecek; build'in başarılı olması dağıtılmış servisin hâlâ desteklendiğini göstermez. Bu yüzden artifact envanteri ve paketlenmiş çıktının test edilmesi gerçek farkı yaratır.