Proje Bitti mi Sandınız? IIS ile Tanışmaya Hazır Olun! 🚀

Sertifika Yönetimi ve Hayat Kurtaran Çözümler

Yazılım geliştirme süreci genelde o pembe rüyayla başlar: Local ortamda her şey kusursuzdur, F5 tuşu en yakın dostunuz, terminaldeki o yeşil yazılar ise huzur kaynağınızdır. Ancak ne zaman ki o muhteşem projeyi Windows Server’a, yani IIS (Internet Information Services) dünyasına taşımaya karar verirsiniz, işte o an gerçeklerle yüzleşme vaktidir.

O meşhur cümleyi hepimiz kurduk: “Ama benim bilgisayarımda çalışıyordu!”

Maalesef IIS tarafında bu cümlenin hiçbir hükmü yok. Bu yazı; bir deployment savaşçısının günlüğünden süzülen teknik tecrübeler, sık yapılan hatalar ve canlıya çıkmadan önce hayatınızı kurtaracak o kritik checklist’ten oluşuyor.

1. Temel Kural: Ortamı Hazırlamadan “Publish” Demeyin

Çoğu geliştiricinin yaptığı ilk hata, yalnızca publish alıp dosyaları sunucuya fırlatmaktır. ASP.NET Core uygulamaları özünde "self-host" çalışır; ancak IIS üzerinde sağlıklı çalışabilmesi için arada sağlam bir köprü katmanına ihtiyaç duyar.

• ASP.NET Core Hosting Bundle: Sunucunuza mutlaka projenizin hedeflediği sürümle uyumlu paketi kurmalısınız. Örneğin .NET 8 ile derlenen bir uygulama, içinde sadece .NET 6 runtime bulunan bir sunucuda daha "merhaba" bile diyemeden çökecektir.

• Application Pool Ayarı: Yeni bir pool oluştururken yapmanız gereken en kritik hamle şudur:

  .NET CLR Version: No Managed Code

  Sebebi basit: Runtime artık IIS’in içinde değil, Kestrel üzerinden dışarıda çalışıyor. IIS burada sadece bir "kapı görevlisi" (Reverse Proxy) rolünde. İçerideki işe karışmamasını ona bu şekilde söylüyoruz.

2. Kritik Teknik Silah: Doğru web.config Yapılandırması

Modern .NET dünyasında web.config, eski projelerdeki o korkunç karmaşıklığından kurtuldu. Artık temel görevi; IIS ile Kestrel arasındaki telsiz bağlantısını kurmak. Uygulama hiç başlamıyorsa, karanlıkta ok atmak yerine önce burayı kontrol edin.

⚠️ Çok Önemli Not: Logların yazılabilmesi için proje dizini altında logs klasörünü manuel olarak oluşturmalı ve IIS kullanıcılarına (IIS_IUSRS) yazma yetkisi vermelisiniz. IIS bu klasörü sizin yerinize oluşturmaz; oluşturamadığı için de hata verse bile hiçbir log göremezsiniz.

3. Korkulu Rüya: Yaygın IIS Hataları ve Net Çözümleri

Deployment sırasında karşınıza çıkacak o meşhur gri ekranların tercümesi aslında şudur:

• HTTP Error 500.19: Genelde web.config dosyasında bozuk bir XML yapısı var demektir. Ya da daha yaygın bir sebep: Sunucuda URL Rewrite modülü eksiktir.

• HTTP Error 500.30 (In-Process Startup Failure): Uygulama koda bile girmeden çöküyor. Sebebi genelde eksik bir DLL, yanlış runtime sürümü veya uyumsuz NuGet bağımlılıklarıdır. Tek çare; stdout loglarını incelemektir.

• HTTP Error 403.14: IIS dosyaları görüyor ama neyi çalıştıracağını bilmiyor. Site dizininde bir giriş noktası (exe/dll) olduğundan ve yetkilerin tam olduğundan emin olun.

4. Arka Plan Servisleri (Background Jobs) Çıkmazı

Birçok senior geliştiricinin bile gözden kaçırdığı o kritik soru: “UI çalışıyor ama arka plan işlerim (mail gönderimi, scheduler) neden duruyor?”

Sebep basit: IIS, verimlilik sever ve istek gelmediğinde uygulamayı "uyutur". Eğer bir Background Worker veya Queue Listener kullanıyorsanız şu ayarları mutlaka yapmalısınız:

• Application Pool Ayarları:

  • Start Mode: AlwaysRunning

  • Idle Time-out (minutes): 0

• Site Ayarları:

  • Preload Enabled: True

Bu ayarlar olmadan IIS, uygulamanızı arka planda aktif tutmaz; ta ki birisi siteye girene kadar.

5. Sertifika (SSL) ve Güvenlik

Production ortamında HTTPS bir lüks değil, zorunluluktur. Ücretli sertifikalara ciddi bedeller ödemek yerine win-acme gibi araçlarla Let’s Encrypt sertifikasını dakikalar içinde kurup otomatize edebilirsiniz.

Ayrıca kod tarafında app.UseHttpsRedirection(); kullanmak yetmez; IIS tarafında da HSTS ayarlarını aktif ederek güvenliği sağlama almalısınız.

✅ Canlıya Çıkmadan Önce Son Checklist

Yayına girmeden önce kendinize şu soruları sorun:

1. Sunucuda doğru Hosting Bundle sürümü kurulu mu?

2. Application Pool "No Managed Code" olarak ayarlı mı?

3. logs klasörü açıldı ve yazma yetkisi verildi mi?

4. AlwaysRunning & Preload ayarları yapıldı mı?

5. Sertifika ve HTTPS yönlendirmesi aktif mi?

Sonuç

IIS, yanlış yapılandırıldığında bir kâbus; doğru konfigüre edildiğinde ise son derece güçlü bir müttefiktir. Unutmayın; iyi bir developer sadece kod yazan değil, yazdığı kodun canlı ortamda nasıl nefes aldığını bilen kişidir.

Bu rehber deployment sürecinizi biraz olsun kolaylaştırdı mı? Ya da şu an boğuştuğunuz spesifik bir IIS hatası mı var? Yorumlarda buluşalım, takıldığınız yerler için çekinmeden mesaj atabilirsiniz. 💬