10 Kasım 2026 öncesi .NET 8 ve 9'dan yükseltme tek dosyayla sınırlı kalmıyor

Aynı gün destekten çıkan iki runtime

10 Kasım 2026'da hem .NET 8 hem .NET 9 destek dışı kalıyor ve Azure Functions'ın in-process barındırma modeli de aynı gün sona eriyor. Geç Ekim'de yayımlanan bir dev.to yazısına göre ertesi gün çalışan hiçbir şey durmuyor — ama o tarihten itibaren bu runtime'larda bulunan her güvenlik açığı yamasız kalıyor.

Doğal hedef, Kasım 2028'e kadar desteklenen güncel LTS sürümü .NET 10. Basit bir proje için yükseltme tek bir değişiklik olabilir: proje dosyasında TargetFramework değerini net8.0'dan net10.0'a çevirmek. Yazının altını çizdiği pürüz şurada: bir uygulamanın derlendiği ve çalıştığı runtime nadiren o satırla belirleniyor. Tipik bir repoda sürüm altı ya da yedi dosyaya yayılmış durumda ve bunlardan herhangi biri, geliştirici taşınma işini bitirdiğine inandıktan sonra bile projeyi .NET 8'de tutabiliyor.

Sürümün gerçekte nerede yaşadığı

En açık konum her .csproj, .fsproj veya .vbproj içindeki TargetFramework. Yazıda daha az belirgin olanlar da sıralanıyor:

• Çoklu hedefli kütüphaneler için TargetFrameworks, çoğul: örneğin net8.0;netstandard2.0.
• Özellikler (properties): birçok çözümde TargetFramework, bir-iki klasör yukarıdaki Directory.Build.props dosyasında tanımlı $(AppTfm) gibi bir değişkene bağlıdır; bu yüzden proje dosyalarında net8.0 araması hiçbir şey bulamaz.
• TargetFrameworkVersion kullanan (v4.6.1 gibi) eski tarz projeler .NET Framework'tür — daha büyük ve farklı bir göç. net48 ya da net462 hedefleyen SDK tarzı projeler de .NET Framework'tür; 4.6.2'nin desteği 12 Ocak 2027'de sona eriyor.

TFM paylaşılan bir özellikten geliyorsa, yazı bunu her projede değil Directory.Build.props içinde tek seferde değiştirmeyi öneriyor.

SDK, container ve pipeline sabitlemeleri

Sık olarak sürüm tutan üç yer daha var.

global.json build SDK'sını sabitler: 8.0.404 belirten bir dosya, yalnızca .NET 10 SDK'sı kurulu bir makinede build işlemini reddettirir. Yeni değer 10.0.100 gibi tam bir sürüm numarası olmalı ve rollForward değeri latestFeature yapılırsa dosya her yama sürümünde düzenlenmek zorunda kalmaz.

Dockerfile'lar hem SDK hem runtime aşamalarında sürümlü temel imajlara başvurur ve ikisi de 10.0'a geçmelidir. Yazı birkaç zincirleme etkiye dikkat çekiyor: .NET 10'un varsayılan etiketleri Debian yerine Ubuntu 24.04, dolayısıyla apt-get adımlarında farklı paket adları gerekebilir; .NET 8'den beri varsayılan container portu 80 değil 8080, bu da EXPOSE, compose dosyaları, Kubernetes manifestleri ve App Service'teki port eşlemelerini etkiler; ayrıca .NET 9 imajlarında artık zlib bulunmuyor. Compose dosyaları da kendi imaj referanslarını taşıyabilir; bazen bunlar bir değişken etiketin arkasındadır.

CI pipeline'ları istedikleri SDK'yı kurar — GitHub Actions'taki setup-dotnet'te dotnet-version, Azure Pipelines'taki UseDotNet@2'de ise version — ve matrix build'leri gözden kaçması kolaydır. Paketler konusunda yazar, Microsoft.AspNetCore., EntityFrameworkCore. ve Extensions.* ailelerini 10.0.x'e taşımayı, üçüncü taraf paketleri ise yalnızca gerekli olduğunda yükseltmeyi öneriyor; .NET 10 SDK'sının restore sırasında geçişli (transitive) paketleri denetlediğini, uyarıların hata sayıldığı durumlarda daha önce yeşil olan build'leri kırmızıya çevirebileceğini not ediyor.

Asıl ağır yük Azure Functions'ta

Yazıya göre yükseltmeyi gerçek işe çeviren öğe Azure Functions: in-process model aynı tarihte destekten çıkıyor ve .NET 10 fonksiyonları yalnızca isolated worker modelinde çalışıyor. Göç, Microsoft.NET.Sdk.Functions'ı worker paketleriyle değiştirmek, her WebJobs uzantısını Functions.Worker karşılığıyla takas etmek, yapılandırmayı FunctionsStartup'tan bir Program.cs'e taşımak ve [FunctionName]'i [Function] olarak değiştirmek anlamına geliyor. Serileştirme System.Text.Json'a geçiyor ve Newtonsoft'un [JsonProperty] öznitelikleri hatasız olarak yok sayılıyor — bir fonksiyon çalışmaya devam ederken farklı özellik adları okuyup yazıyor. FUNCTIONS_WORKER_RUNTIME ayarı ile yeni kod birlikte, ideali bir staging slot üzerinden dağıtılmalı; biri öbürü olmadan değiştirilirse AZFD0013 hataları oluşur.

Derlenen ama farklı davranan değişiklikler

8'den 10'a geçiş iki sürümün kırıcı değişikliğini içeriyor ve asıl riskli olanlar build hatası olarak hiç ortaya çıkmayanlar. Yazının kısa listesi: BinaryFormatter 9'dan beri her zaman exception fırlatıyor; BackgroundService.ExecuteAsync'ın başındaki eşzamanlı iş artık başlatmayı geciktirmiyor; yapılandırma null değerleri koruyor; cookie kimlik doğrulaması API uç noktaları için oturum açma sayfasına yönlendirmek yerine 401 döndürüyor; ve Development ortamında host, DI kapsamlarını build sırasında doğruluyor, gizli hataları yerelde ortaya çıkarıyor. EF Core 9, modelde bekleyen değişiklikler varken migration uygulanırsa exception fırlatıyor; Azure SQL'de EF Core 10 ise JSON sütunlarını yeni json türüne dönüştüren bir migration üretebiliyor — yazar, yükseltmeden sonra dotnet ef migrations add çalıştırıp sonucu her şeyi dağıtmadan önce okumayı öneriyor. Yazı, yazarın bu dosyaları okuyup bulduğu her .NET sürümünü destek sonu tarihiyle listeleyen açık kaynak tarayıcısı dotnet-eol-scan ile kapanıyor.

Neden önemli

Desteklenen iki runtime aynı anda sona erdiği için .NET ekosisteminin büyük bir dilimi aynı tarihte güvenlik düzeltmelerini almayı bırakıyor. Yazının ana fikri şu: bu göç başlaması kolay ama yarım bırakılması da kolay bir iş — bir reponun proje dosyaları güncellenmişken CI'da eski bir SDK ile build alması ya da eski bir container imajıyla çıkması mümkün ve bu boşluk, yama almayan bir runtime'a bir güvenlik açığı denk gelene kadar görünmez kalıyor. Taşınmayı TFM'ler, SDK sabitlemeleri, container imajları, pipeline'lar ve Functions barındırma kapsayan bir repo geneli denetimi olarak ele almak, tamamlanmış bir yükseltmeyi kozmetik olandan ayıran şeydir.