Microsoft, Azure Functions’ta uzun yılların varsayılan çalışma modelini emekliye ayırıyor: in-process model ve bu modeldeki .NET 8 desteği 10 Kasım 2026’da bitiyor. Tarihi, resmi migration rehberi sayfanın en üstünde uyarı olarak veriyor. Bu günden sonra desteklenen tek C# çalışma modeli isolated worker model olacak; güvenlik yaması, resmi destek ve yeni .NET sürümü in-process uygulamalara artık gelmeyecek.
Sahada en sık karşılaştığım tablo, yıllar önce kurulmuş, o günden beri sorunsuz çalışan, kimsenin dokunmak istemediği bir Function App. Bugün istek alıyor, cevap dönüyor, kimse sormuyor. Tam da bu yüzden tam destek biterken fark ediliyor.
Bu yazıda önce in-process ve isolated ayrımının neden bir sürüm değil model değişikliği olduğunu, sonra 10 Kasım tarihinin tam olarak neyi kapsadığını, en sonunda da ben sahada hangi sırayla ilerlediğimi anlatacağım.
In-process ve isolated: aynı odada mı, ayrı odada mı?
In-process modelde Function kodunuz Azure Functions host’uyla aynı process içinde çalışır. Isolated worker model’de ise kodunuz ayrı bir worker process’te döner. Benzetmek gerekirse in-process, host ile kodun aynı odada çalışması; isolated, ayrı odalarda çalışması. Aynı odada oturduğunuzda masadaki kütüphane sürümünü paylaşırsınız ve biri diğerinin sürümüyle çakışabilir. Ayrı odada her birinin kendi rafı olur; isolated model’in en bilinen faydası da bu: assembly çakışmaları azalıyor, process üzerinde tam kontrolünüz oluyor, dependency injection de standart .NET’teki gibi, yani bağımlılık enjeksiyonu alışık olduğunuz şekilde çalışıyor.
Isolated’a geçiş, uygulamanın çalışma modelini baştan kurmak demek. Proje dosyası, SDK ve binding paketleri, HTTP tetikleyici tipleri ve başlangıç kodu hepsi değişiyor.
Somutlaştırayım. In-process’te projeniz Microsoft.NET.Sdk.Functions paketini kullanır; isolated’da Microsoft.Azure.Functions.Worker ailesine geçersiniz. Binding extension paketleri değişir, HTTP tetikleyicinin imzası değişir, startup tarafında kurduğunuz servisler standart bir program başlangıcına taşınır. Microsoft Learn’un migration rehberi bu değişiklikleri madde madde gösteriyor; aynı sayfada abonelikteki in-process app’leri bulan bir PowerShell scripti de var.
Bu yüzden işi ev taşıma gibi düşünmeyin, aynı evde elektrik tesisatını yenileme gibi düşünün. Bina aynı kalıyor, uygulama aynı işi yapıyor, ama duvarın içindeki her kablo değişiyor.
10 Kasım 2026 tam olarak neyi kapsıyor?
Burada bir karıştırma noktası var, netleştireyim. 10 Kasım 2026 iki ayrı şeyi aynı güne denk getiriyor: hem in-process modelin destek sonu, hem de .NET 8’in bu modeldeki beklenen destek sonu. Bu “.NET 8’in genel desteği bitiyor” demek değil; .NET 8 LTS sürümünün kendi yaşam döngüsü ayrı bir takvimde yürüyor. Burada biten şey, in-process modelin kendisi.
Desteğin bitmesi uygulamanın o gün aniden durması demek değil; 10 Kasım’dan sonra da istek alıp cevap dönmeye devam eder. Değişen şey arkasındaki destek: in-process model için yeni güvenlik yaması çıkmaz, bir sorun üzerine açtığınız resmi destek talebi geçiş önerisiyle kapanır, modelde ortaya çıkan breaking-change’ler için düzeltme gelmez. Yani uygulama çalışır ama desteklenmez, aradaki riski siz taşırsınız.
Runtime sürüm karşılaştırmasına bakınca tablo net, in-process v4.x artık yalnızca .NET 8’i destekliyor. Isolated tarafı ise .NET 10’u (destek sonu 14 Kasım 2028), .NET 9’u ve .NET 8’i listeliyor. Yani in-process’te .NET 10 seçeneği zaten yok. Çoğu ekip bunu “.NET 8’den .NET 10’a geç” diye okuyor, oysa .NET 9 ya da .NET 10’a çıkmanın tek yolu isolated worker model’e geçmek. Bu ayrımı bir kez net koyun, planı onun üzerine kurun. Tablonun kaynağı Microsoft Learn’un runtime sürüm sayfası.
Azure tarafında duyurulan planlı bir değişikliği önceden okuyup aksiyona çevirmek yeni bir şey değil; daha önce Azure fiyatlarındaki artış için de aynı yaklaşımı yazmıştım. Takvim belliyse erken davranan rahat eder.
Sahada hangi sırayla ilerliyorum
Projelerde aynı sırayı izliyorum, çünkü adım atlayınca iş son haftaya yığılıyor.
Önce envanter çıkıyorum. Bir Function App’in hangi modelde olduğunu bilmeden plan yapılamıyor, o yüzden bütün abonelikte tarama yapıyorum: Azure PowerShell ile Runtime’ı dotnet olan app’leri listeliyorum. Tek bir in-process app var sanıp taramada ikinci, üçüncü bir tane bulan ekip az değil; bu yüzden his yerine listeye bakıyorum. Bu adım, Azure Developer tarafında iş yapan herkesin ilk refleksi olmalı.
Envanteri çıkardıktan sonra runtime sürümüne bakıyorum. Uygulama v4.x üzerinde mi, onu kontrol edin; elinizde eski 1.x, 2.x ya da 3.x varsa önce host sürümünü yükseltmek gerekiyor, isolated geçişi ondan sonra geliyor.
Sıra hedef .NET seçimine geldiğinde herkes otomatik .NET 10 diyemez. Uygulama ve bağımlılıkları .NET üzerinde çalışabiliyorsa hedef .NET 10; yalnızca .NET Framework’te bulunan API’lere bağımlıysanız hedef .NET Framework 4.8. Bu ikili seçimi atlamayın, çünkü yanlış hedef bütün testi boşa çıkarır.
Ardından yerel dönüştürme ve test. Projeyi isolated’a çevirip Core Tools v4.x ile yerelde çalıştırın; HTTP ve dependency injection tarafındaki değişiklikleri burada görürsünüz. Isolated modelde HTTP tetikleyici eski HttpRequest ve IActionResult yerine HttpRequestData ve HttpResponseData tipleriyle çalışır; metot imzalarınız ve cevabı kurma şekliniz değişiyor. Core Tools ile lokalde ayağa kaldırmak, bu imza değişikliklerini ve binding’lerin doğru bağlanıp bağlanmadığını uygulamayı Azure’a taşımadan önünüze getirir. .NET Upgrade Assistant bir usta değil, otomatik bir yardımcı; işin çoğunu alır ama HTTP imzaları ve DI kurulumu gibi el işini yine siz kontrol edersiniz.
En sona Azure’daki app’i isolated’a almayı bırakıyorum. Yerelde temiz çalışan uygulamayı en son taşıyın; önceki adımlar tamamsa bu kısım en az sürpriz üretir.
10 Kasım’dan önce yapılacaklar
Kısa bir özet, panik yapmadan:
- Abonelikteki in-process .NET Function App’leri bugün envantere çıkarın.
- Runtime eski sürümdeyse önce v4.x’e taşıyın.
- Hedef .NET’i uygulamanın bağımlılıklarına göre seçin: .NET 10 ya da .NET Framework 4.8.
- Yerel projeyi isolated’a çevirip Core Tools ile test edin, HTTP ve DI tarafını elle doğrulayın.
- Azure uygulamasını en son, yerelde temiz çalıştığından emin olunca geçirin.
Takvim aylarla ölçülüyor, haftalarla değil; bu işi bir sürüm güncellemesi sanıp son haftaya bırakan ekip, o hafta kod değişikliğiyle boğuşur. Siz hangi aşamadasınız, in-process app’lerin envanterini çıkardınız mı? Sorularınız olursa yorumlarda buluşalım.
