.NET 10.0.5 ile macOS Debugger Çökmesine Son: Saha Notları ve Pratik Tüyolar
Bir Sabah Her Şey Bozuldu: macOS ve.NET Debugger Krizi
Bazı günler vardır, terminale “dotnet run” yazarsın ve her şey mış gibi akar sanırsın. Sonra… hop, mevzu çat diye biter. Geçenlerde sabah ofiste tam böyle bir an yaşadım: Visual Studio Code üzerinden.NET uygulamasını debug’lamaya kalktım (2024 Mayıs, M1 MacBook Air elimde), debugger zınk diye kapandı (kendi tecrübem). Kendime ilk sorduğum soru şu öldü: “Yahu ben neyi beceremedim acaba?” Ama kazın ayağı öyle değilmiş; biraz internette turlayınca olay bana özel bir fiyasko değilmiş – millet forumlarda dökülmüş.
Yalnız olmadığım kesinleşti. Hatta iş arkadaşlarım bile aynı hafta içinde sırayla gelmeye başladı; Logosoft ekibinde iki ayrı insan – biri ARM64 Maç Mini’de diğeri Intel tabanlı MacBook Pro’da – aynı derdi yaşadı. Panik yok ama can sıkıyor! Yanı kimse paçayı sıyıramamış.
Aslında Ne Öldü? Sorunun Kökeni ve Etkiledikleri
.NET 10.0.4 sürümünde yayımlanan bir yama güvenlik adına birkaç düzeltme getiriyor getirmesine. Yanında hiç hoşuma gitmeyen ters köşe de yapmış: VSCode ile macOS üzerinde.NET debug ederken debugger pat küt kapanıyor — özellikle Apple Silicon makinelerde işler daha da karışıklaşıyor (M1/M2/M3, hepsi dahil). Yanı tablo şöyle:
- macOS kullanıyorsun (Apple Silicon ya da Intel ayırt etmiyor gerçi, sadece ARM64 olanlarda kriz daha çabuk patlıyor)
- Visual Studio Code ile debug’a dalıyorsun
- .NET SDK 10.0.104 veya 10.0.200 kuruluysa
- veya runtime olarak.NET 10.0.4’e denk geldiysen
Bu üçleme sende varsa geçmiş olsun — debug işi çöpe dönmüştü! Neyse ki Microsoft bu sefer gazladı ve hızlı reaksiyon verdi.
Neden Sadece VSCode?
Peki bu dert niye hep VSCode’da çıkıyor? Geçen hafta Logosoft’ta müşteri toplantısında aynen bunu sordular bana — başta ben de kısa devre yaptım çünkü klasik Visual Studio veya Rider gibi araçlarla çalışan ekiplerde hayat normal akıp gidiyordu.
VSCode’un debugger mimarisi extension bağımlılığı çok yüksek olduğu için düşük seviyedeki hatalar önce burada yüzeye çıkıyor.
Zaten eski tecrübelerden biliyorum (
dotnet --list-sdksdiyerek sistemde hangi versiyonların olduğuna bakmadan başlamayın.- .NET 10.0.5’i resmî siteden indirin veya Homebrew üzerinden
brew upgrade --cask dotnet-sdk‘yu yürütün. - Muhakkak VSCode’u komple yeniden başlatın (“cmd+w” yeter sanmayın – iyice kapatıp tekrar açmanız şart!).
- Tüm C# eklentilerini kontrol edin; kimi zaman güncel olmayan extension hâlâ saçmalayabiliyor.
Sorunun Perde Arkası ve Neler Öğrendik?
Bence teknik boyutundan ziyade topluluk refleksi en ilginciydi… Dakikalar içinde GitHub Issues’a bildirım yağdı resmen; insanlar Discord kanallarında birbirine geçici çözüm yollarını paylaştılar (“önce dene sonra sor” mottosu gene galip geldi!). Bununla Almanya’dan Brezilya’ya kadar yazılımcıyla canlı canlı tartışmak nasip öldü — en azından moral desteği kuvvetleniyor böyle anlarda!
Müşteride Gerçek Hayat Deneyimi – Haziran/İstanbul Ofisinden Kestirmeler
Eylül Telekom projesinde karşılaştığımız hadise şuydu;
pipeline otomasyonunda test runner aniden kitleniverdi – meğer herkes yeni SDK’yı yüklemiş. Hiçbiri VSCode’u restart etmemiş! Sonuç? Üç kişi peşi sıra birbirinin hatasını takip etmiş:) Nihayet beş dakikalık minik bir update tüm günü kurtardı – inanmazsınız ama gerçek öldü valla.
Kritik notum şu:
“Küçücük bir patch’in büyük stresleri nasıl erittiğini anlamak istiyorsanız.NET’in son vakasına bakmanız yeter!”
Peki Ya Diğer Platformlar? Kaos Yok mu?
Birkaç kişi doğrudan “Linux/Windows tarafında niye bunlar olmuyor?” diye lafa girdiğinde cevabımı net vereyim — o platformlarda yıllardır runtime/dll işleri çok daha stabil ilerlediği için native debugging katmanı fazla kaosa izin vermiyor; Apple Silicon işe henüz olgunlaşamadı diyelim.
- Eğer Windows veya Linux’taysanız mevcut.NET 10.04 ile devam edebilirsiniz.
En son patch’sız de gayet yolunuza bakarsınız yanı.
“Ben ille yenisini isterim!” diyenlere laf yok tabiî… - Kaldı ki out-of-band fix yeni fonksiyonellik sunmuyor – hemen yükseltmeniz gerekmez yanı.
Version locking sistemi olan kurumlar için rahatlık seviyesi fena değil!
Birkaç Pratik İpuçu & Kapanış Yorumum
- Küçük sandığınız platform update’leri bazen kurtarıcı olur!
Eskiden “of yine mi patch?” deyip geçerdim şimdi tövbe… - Kodunuzu production’a atmadan önce local makinede test edin – özellikle macOS üstünde çalışıyorsanız küçük sapmalar kabak gibi ortaya çıkıyor!
- Ekipte herkesin aynı SDK versionunu kullandığından emin olun
Bir keresinde Azure DevOps agent image upgrade’i sonrası üç takım paralel çalışma yaparken neredeyse gene benzer bela yaşayacaktık… - C# extension cache bazen inatçı olabiliyor;
ilk restart çare olmazsa cache’i temizlemeyi deneyin. - Derdinizi Microsoft’un release feedback issue sayfasına yazmaktan çekinmeyin;
iki kez yazdım biri cevaplandı vallahi!
“.NET Modernizasyonunda Yepyeni Bir Dönem.
Ya da OpenAI entegrasyonu örneklerini merak edenler için şurayı bırakıyorum:
“.NET ve OpenAI ile Gerçek Zamanlı Ses Temelli Çoklu Ajan.
Nihai Değerlendirme — Azıcık Eleştiri Şart!
Açık konuşacağım… Microsoft hızlı davrandı evet ama asıl şaşırtıcı olan böyle temel regresyonun prod ortamına kadar ulaşmasıydı açıkçası… Daha iyi test döngüsü görmek isterdim hele ki Apple Silicon bu kadar popüler olmuşken! Güzel taraf işe topluluk kenetlendi, çözümü hemen buldu ve dokümantasyon kısa sürede toparlandı.
Sen de benim gibi “her şeyi bleeding edge takip ederim!” kafasındaysan şunu unutma — prod öncesi her patch’i sorgula kardeşim! Kağıt üstünde kolay gözüken detay pratikte arapsaçı çıkarabiliyor… Ama ucuz atlattık yine şansımıza!
Kaynak:
[. NET 10. 05 Out-of-Band Release – macOS Debugger Fix](https://devblogs.microsoft.com/dotnet/dotnet-10-0-5-oob-release-macos-debugger-fix/)
Sıkça Sorulan Sorular
macOS’ta.NET 10.0.4 ile VSCode debug ederken debugger neden “pat diye” kapanıyor?
Bu durum,.NET 10.0.4’teki bazı düzeltmelerin macOS’ta VSCode debugger ile etkileşime girmesinden kaynaklanıyor. Özellikle Apple Silicon (M1/M2/M3) tarafında daha hızlı tetiklenebiliyor. Sonuç olarak debug başlar başlamaz debugger çöküp kapanabiliyor.
Bu hata sadece VSCode mu, Visual Studio veya Rider’da da olur mu?
Genel olarak bu sorun sadece macOS’ta VSCode kullananları etkiliyor. Windows ya da Linux tarafında, ya da farklı IDE’lerde aynı çökme beklenmiyor. Ben de aynı ekipte farklı makinelerde denendiğini görünce “tam olarak VSCode kaynaklı” hissi netleşti.
Hangi sürümleri kontrol etmeliyim:.NET SDK 10.0.104 mü, 10.0.200 mü yoksa runtime 10.0.4 mü?
En kritik nokta, macOS’ta VSCode debug sırasında.NET SDK veya runtime’ın 10.0.4’e denk gelip gelmediği. Yazıda bahsedilen senaryolarda özellikle SDK olarak 10.0.104 veya 10.0.200 kurulu olanlar ve runtime olarak 10.0.4’e takılanlar sorun yaşayabiliyor. “dotnet –version” çıktını kontrol ederek hangi sürümde takıldığını hızlıca görebilirsin.
.NET 10.0.5 Out-of-Band güncellemesi gerçekten debugger çökmesini düzeltir mi?
Evet,.NET 10.0.5 out-of-band güncellemesindeki fix doğrudan debugger çökmesini hedefliyor. Güvenlik yamaları aynı kaldığı için “ekstra bir şey geldi” diye düşünmek gerekmiyor; ana amaç bu spesifik problemi kapatmak. Ben yükledikten sonra VSCode’u kapatıp açtım, ayrıca ekstra ayar yapmadan düzelmişti.
Güncellemeyi yaptıktan sonra ne yapmam gerekiyor, sadece kurmak yeterli mi?
Genelde sadece.NET 10.0.5’i yüklemek yetiyor. Benim senaryomda VSCode’u tamamen kapatıp tekrar açınca debugger sorunsuz çalışmaya başladı. Eğer hâlâ çöküyorsa, terminalde doğru sürümün aktif olduğundan emin olmak için tekrar “dotnet –version” kontrolü yapmanı öneririm.
Kaynaklar ve İleri Okuma
.NET 10.0 Sürüm Notları – Microsoft Docs
GitHub -.NET Runtime macOS Debugger Crash Issue
.NET 10.0.5 Out-of-Band Güncellemesi Duyurusu – Microsoft Dev Blog
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
