Binlog MCP Server: Build Sorunlarını Copilot’a Çözdürmek
Şunu söyleyeyim, Açık konuşayım: MSBuild binlog dosyalarıyla saatlerce boğuşmuş biri olarak, bu haberi ilk gördüğümde bayağı şüphe ettim. “Yine bir MCP server, yine biraz hype” dedim kendi kendime. Sonra kurdum, denedim. Ee, fikrim değişti. Neden önemli bu? Hem de az buz değil.
Microsoft geçtiğimiz günlerde Microsoft Binlog MCP Server‘ı duyurdu. Adı kulağa kuru geliyor, — en azından ben öyle düşünüyorum — evet, ama işin aslı şu: GitHub Copilot ya da başka bir AI asistanı artık .binlog dosyanızın içine bakıp “kardeşim build neden patladı?” sorusuna daha düzgün cevap verebiliyor. Structured Log Viewer’da saatlerce ağaç dallarını açıp kapatmaya gerek kalmadan oluyor bu iş, ki açık söyleyeyim, bazen o ekranın içinde kaybolmak insanı yoruyor.
Bu yazıda hem aracın ne işe yaradığını anlatacağım hem de — daha önemlisi — Türkiye’deki.NET ekipleri bunu nasıl konumlandırmalı, ona dair kendi fikrimi paylaşacağım. Çünkü her parlak yeni oyuncak her ekibe aynı şekilde yaramıyor; biri için hayat kurtarıyor, öteki için gereksiz kalıyor (şey, sahada böyle görüyoruz). Bakın, peki neden?
Evet. Bu konuyla ilgili RDBMS’ten Cosmos DB’ye Geçiş: AI Asistanı Ne Kadar İşe Yarar? yazımıza da göz atmanızı tavsiye ederim.
Binlog Nedir, Neden Bu Kadar Önemli?
Hani, Önce temele inelim. MSBuild binary log, yanı .binlog dosyası, build sürecinin bayağı detaylı bir kaydı; hangi property nereden gelmiş, hangi target kaç saniye sürmüş, hangi task hangi argümanlarla çağrılmış, hepsi tek dosyada dürüyor (inanın bana). Kısacası işin röntgeni bu.
Bence, Güzel tarafı da burada, ama dur bir saniye — bu dosya binary olduğu için düz metin gibi açıp bakamıyorsunuz. MSBuild Structured Log Viewer diye fena olmayan bir araç var, Kirill Osenkov da bunu yıllardır geliştiriyor; yine de 80-100 projeli bir solution’da sorunlu yeri bulmak bazen insanın kafasını şişiriyor, açık konuşayım.
Hmm, bunu nasıl anlatsamdı…
Sahada çok gördüm bunu. Junior biri “build hata veriyor” diyor, binlog’u alıyor ama içinden ne çıkacağını tam bilmiyor; sonra top senior’a geliyor ve o kişi de “şu property nereden besleniyor acaba” diye dakikalarca, bazen saatlerce kurcalıyor. İşte MCP server tam bu boşluğa oturuyor.
Şunu fark ettim: Evet.
Model Context Protocol Kısaca: Neden Önemli?
MCP, Anthropic’in başlatıp sonra yavaş yavaş herkesin konuşmaya başladığı açık bir protokol. Mantık basit, hatta ilk bakışta biraz fazla basit geliyor: AI asistanlarına araç vermenin ortak bir yolu var artık. Yanı Copilot’a “binlog dosyasını oku” demek için her seferinde ayrı entegrasyon yazmıyorsunuz; MCP konuşan bir server kuruyorsunuz, asistan da önü kendi kendine keşfediyor. Güzel tarafı bu. Ama dur bir saniye — asıl mesele sadece kolaylık değil, standartlaşma da işin içine girince oyun değişiyor.
İnanın, Bunu Türkiye’deki şirketler açısından düşününce tablo daha netleşiyor. Kurumsal ekiplerin kendi iç araçlarını AI’a bağlaması baya kolaylaşıyor, mesela bir bankanın iç deployment sisteminin loglarını okuyan bir MCP server yazmak, geçen yılki iş yüküne göre belki üçte bir efor istiyor; emin değilim ama sahada hissettiğim şey bu yönde. Bu büyük mesele. Microsoft Agent Framework: Katmanlı SDK Tasarımının İç Yüzü yazımda da bu konunun mimarı tarafına biraz eğilmişim, ilgilenen bakabilir. Neyse, çok dağıtmadan söyleyeyim: doğru kurgulanırsa MCP, ekiplerin AI’ı deneme aşamasından çıkarıp günlük işe sokmasını hızlandırıyor (bu konuda ikircikliyim)
15 Araç, 4 Kategori: Ne Yapabiliyor?
Binlog MCP server toplam 15 farklı “tool” sunuyor AI asistana. Bunları dört ana grupta toplamış ekip. Hepsini tek tek didiklemeye gerek yok, ama işin can alıcı yerlerine bakalım; çünkü asıl fayda orada çıkıyor, gerisi biraz süs gibi kalıyor.
Hmm, bunu nasıl anlatsamdı…
Build Inceleme Araçları
Buradaki en kıymetli iki tane bence binlog_explain_property ve binlog_imports. Property’nın nereden değer aldığını izlemek MSBuild tarafında klasik bir baş ağrısıdır. Bir TargetFramework beklediğinizden farklı çıkıyor mesela — kim set etti önü? Hangi .props dosyası, hangi target, hangi import zinciri? Bazen cevap 5 dakika sürüyor, bazen 2 saat; açık konuşayım, insanın sınırını bozuyor. Artık Copilot’a soruyorsunuz, o da iz sürüp gösteriyor.
Diğer araçlar da boş değil:
binlog_overview— build’in özet röntgenibinlog_errors— sadece hatalar, ama tam context’lebinlog_warnings— warning code’a göre filtrelibinlog_search— Structured Log Viewer’ın DSL’iyle tam metin aramabinlog_projects— tüm projeler, durumları ve süreleri — ciddi fark yaratıyor
Evet.
Performance Analizi: Bence En Değerli Kısım
Burada üç araç var: binlog_expensive_projects, binlog_expensive_targets. binlog_expensive_tasks (ben de ilk duyduğumda şaşırmıştım). Yavaş çalışan projeleri, target’ları ve task’ları sıraya koyup önünüze getiriyor. Niye burayı daha değerli buluyorum? Çünkü FinOps danışmanlığı yaparken önüme sürekli aynı mesele düşüyor: CI/CD süreleri. Şey yanı, kimse build süresine bakmıyor; sonra faturayı görünce herkes bir anda meraklanıyor.
Azure DevOps veya GitHub Actions üzerinde her dakika para. Build süresini %30 düşürmek, runner maliyetlerinde aynı oranda doğrudan tasarruf demek. Ve çoğu ekip nereye bakacağını bilmediği için bu fırsatı kaçırıyor.
Lafı gevelemeden söyleyeyim: Binlog MCP ile Copilot’a “şu binlog’da en pahalı 5 target’ı bul, bunlardan hangileri paralel çalıştırılabilir öneri yap” diyebiliyorsunuz. Bu kadar basit görünüyor ama işin aslı baya iş görüyor; çünkü elinizde tahmin değil, ölçü var.
Bunlar karşılaştırma da yapıyor mu?
Evet, tek bir araç var burada: binlog_compare. İki binlog’u karşılaştırıyor. Mantık şu — “dün build çalışıyordu, bugün patladı, ne değişti?” sorusuna yanıt veriyor. Property’ler mi değişmiş, paket sürümü mü kaymış, yoksa bir import zinciri mi farklı davranmış; hepsini ortaya döküyor (manuel yapmak gerçekten yorucu bir işti). Az önce dedim ya ölçü önemli diye, işte burada fark daha net çıkıyor.
Bir dakika — bununla bitmedi.
Peki neden önemli? Çünkü bazen sorun kodda değil; küçük bir sürüm farkı ya da sessizce değişen bir property bütün tabloyu bozuyor (ben de ilk duyduğumda şaşırmıştım). Neyse uzatmayalım, böyle durumlarda compare aracı baya hayat kurtarıyor. Agents League Hackathon 2026: Enterprise Agents Kategorisi Rehberi yazımızda bu konuya da değinmiştik.
Nasıl Kuruluyor? Pratik Tarafı
En kolay yol, .NET Agent Skills reposundan ilerlemek. dotnet-msbuild plugin’i hem MCP server’ı hem de Copilot için hazır skill tanımlarını içeriyor; yanı bir yandan altyapıyı kuruyorsunuz, öte yandan Copilot tarafını da aynı anda toparlıyorsunuz (iki ayrı iş gibi dürüyor ama değil). VS Code ya da Visual Studio kullanıyorsanız, Copilot ayaruna birkaç satır ekleyip çıkıyorsunuz, işin aslı bu kadar sade (bu konuda ikircikliyim)
Bir örnek mcp.json ayaru kabaca şöyle dürüyor:
{
"servers": {
"binlog": {
"command": "dotnet",
"args": ["tool", "run", "binlog-mcp"],
"env": {
"BINLOG_PATH": "./artifacts/build.binlog"
}
}
}
}Sonra Copilot Chat’e dönüp, “build.binlog’da neden CS0246 hatası alıyorum?” diye sorabiliyorsunuz. Asistan tool’ları çağırıyor, dosyayı parse ediyor, hatanın hangi projede. Hangi dosyada çıktığını söylüyor; hatta bazen hedef zincirini de gösteriyor (burada insanın aklına ilk gelen şey başka oluyor ama mesele çoğu zaman o değil). Hatta düzeltme önerisi bile getiriyor.
Doğrusu, Evet.
Pratikte Ne Kadar İşe Yarıyor? Dürüst Değerlendirme
Şimdi biraz gazı kısalım. Çünkü her şey güllük gülistanlık değil.
İyi Çalıştığı Senaryolar
Tek başına duran, izole bir build hatasını çözmede baya iş görüyor. Property kaynağını bulurken de fena sayılmaz; hatta bazı durumlarda şaşırdım açıkçası. Performance bottleneck’leri yakalamada da elinden geleni yapıyor. Junior geliştiricilere “şu binlog’u Copilot’a sor” demek, öğrenme eğrisini baya aşağı çekiyor, ama burada da biraz yönlendirme lazım, yoksa çocuklar her cevabı altın sanabiliyor.
Evet.
Zorlandığı Yerler
Ama gel gelelim… Çok büyük binlog’larda (mesela 500 MB üzeri) AI’ın context window’u tıkanıyor; MCP server tüm dosyayı tek seferde vermiyor zaten, parça parça aktarıyor, yine de bazı sorgularda asistan resmî bütünüyle göremiyor ve orada biraz tökezliyor. Birden fazla custom MSBuild target yazıyorsanız ve task’larınız özel davranıyorsa, Copilot çoğu zaman somut konuşamıyor; genel kalıp bilgisiyle idare ediyor, işte bu da bazen insanı yanlış yere götürüyor.
Bir de şu var: Modelin halüsinasyonu hâlâ sıfır değil. Property kaynağını sorduğunuzda %95 doğru cevap veriyor. O kalan %5’te kendinden emin konuşup yanlış bir şey söyleyebiliyor, o yüzden can alıcı kararlarda mutlaka Structured Log Viewer ile çapraz kontrol yapmak gerekiyor. Peki neden? Çünkü burada güvenmek yetmiyor, doğrulamak şart oluyor.
Açıkçası, Maalesef.
Türkiye’deki Ekipler Açısından Değerlendirme
Kurumsal müşterilerde gördüğüm tablo biraz ilginç. Türkiye’de.NET ekipleri build sorunlarına yaklaşırken, çoğu zaman işin en başındaki parçayı atlıyor; yanı binlog’u. Hani “önce sinyal toplayalım” kısmı var ya, işte orası çoğu yerde eksik kalıyor.
Binlog’a Copilot bağlamak kulağa hoş geliyor, evet. Ama önce ekibin o binlog’u düzenli toplaması lazım, yoksa ortada analiz edecek bir şey kalmıyor; küçük bir alışkanlık gibi dürüyor. Pratikte asıl farkı o yaratıyor. Evet.
Bak şimdi, Küçük bir startup’sanız, açık konuşayım, işiniz daha rahat. Doğrudan kurarsınız, kullanırsınız, biter. Yatırım neredeyse sıfır, geri dönüş de fena değil; CI pipeline’ınız zaten binlog artifact topluyorsa, bunu Copilot’a bağlamak yarım gün bile sürmeyebilir. Daha fazla bilgi için Copilot Code Review’a AGENTS.md Desteği: Ne İşe Yarayacak? yazımıza bakabilirsiniz.
Şöyle söyleyeyim, Büyük bir kurumsal yapıdaysanız işe tablo değişiyor. Bak şimdi, burada teknik taraftan önce birkaç soru geliyor akla (ve bunlar genelde toplantıda bir anda ortaya çıkıp herkesi susturuyor): Binlog’lar production-like build çıktıları taşıyorsa bunları AI’a göndermek veri sınıflandırması açısından uygun mu, Copilot Business ya da Enterprise aboneliğinde context’in nereye gittiğini netleştirdiniz mi, iç MCP server mı çalıştıracaksınız yoksa public Copilot mu kullanacaksınız? Bunların cevabı sektöre göre baya kritik olabiliyor.
Dürüst olmak gerekirse, Bunlar süslü kaygılar değil. Finans ve telco tarafında bu sorular sorulmadan adım atılmıyor; hatta bazen konu teknoloji değil, doğrudan risk yönetimi oluyor. Maalesef durum böyle. Daha fazla bilgi için TypeScript 7.0 RC: Go ile Yeniden Yazıldı, 10 Kat Hızlandı yazımıza bakabilirsiniz.
Ne yalan söyleyeyim, Copilot Usage Metrics API’ye ai_credits_used Geldi: FinOps İçin Ne Anlama Geliyor? yazımda Copilot kullanım maliyetlerinin kurumsal tarafta nasıl izlenebileceğini detaylandırmıştım; bu başlık da onunla aynı yere çıkıyor, sadece bu kez bütçe yerine veri akışı tarafına bakıyoruz. Şey, ikisi birbirinden ayrı gibi dürüyor ama pratikte yan yana yürüyor.
Maliyet Tarafı: TL Bazında Düşünelim
Aracın kendisi ücretsiz, açık kaynak ve GitHub’da dürüyor (yanlış duymadınız). Asıl para Copilot tarafında gidiyor. Diyelim ki 30 kişilik bir.NET ekibiniz var; hepsi de Copilot Business kullanıyor. Aylık kabaca 30 x 19 USD = 570 USD eder, kur oynayınca da bu iş yaklaşık 23-25 bin TL bandına geliyor (inanın bana) Bu konuyla ilgili Intelligent Terminal 0.1.1: Bash Desteği, /fix ve /model Yenilikleri yazımıza da göz atmanızı tavsiye ederim.
Bunu biraz açayım.
Şimdi bakın, bu rakam ilk anda biraz can sıkıyor gibi geliyor. Ama bir de şunu düşünün: Ekibinizdeki senior bir geliştiricinin toplam istihdam maliyeti saatte 1500-2000 TL civarındaysa. Copilot + Binlog MCP ayda her senior’a sadece 10 saatlik build debug zamanı kazandırıyorsa (ben açık konuşayım, çoğu ekipte bundan fazlasını bile gördüm), işin hesabı bir anda değişiyor.
Size bir şey söyleyeyim, Yanı mesele sadece lisans ücreti değil. Evet, etiket fiyatı var. Ama o fiyatın karşılığında gece yarısı log kovalamak azalıyor, build kırıldıktan sonra “nereden başladı bu iş” diye paniklemek yerine daha hızlı kök sebebe iniyorsunuz; hani şu koca binlog dosyasını açıp satır satır dolaşma derdi var ya, onun yükü baya hafifliyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Alternatifler ve Karşılaştırma
Tabiî burada tek seçenek Microsoft’un sunduğu yol değil. Biraz bakınca tablo zaten kendini ele veriyor; kimi araç gözle gezmek için iyi, kimi de konuşarak işi hızlandırıyor, yanı ikisinin derdi aynı değil aslında.
| Araç | Yaklaşım | AI Entegrasyonu | Maliyet |
|---|---|---|---|
| MSBuild Structured Log Viewer | Görsel, manuel | Yok | Ücretsiz |
| Binlog MCP Server | AI-driven, konuşma | Tam | Ücretsiz (Copilot ayrı) |
| Kendi grep/script’leriniz | CLI, manuel | Yok | Zaman maliyeti |
Açık konuşayım, Structured Log Viewer hâlâ el altında durması gereken bir araç. Yerine geçmiyor bu yeni yapı, daha çok omuz veriyor; hani görsel ağaç içinde gezinmeniz gerekiyorsa yine önü açarsınız, ama “bu hata nereden çıkmış” gibi rutin sorularda Copilot tarafı baya iş görüyor.
Ve işler burada ilginçleşiyor.
Peki, size bir şey söyleyeyim, Peki neden? Çünkü her problem aynı değil. Bazen log içinde gözle dolaşmak gerekiyor, bazen de kısa bir soruyla sonuca gitmek daha mantıklı oluyor; işte tam o noktada ikisini yan yana düşünmek daha doğru geliyor bana.
Evet.
İlk Adım Olarak Ne Yapmalısınız?
Eğer denemek istiyorsanız, ben olsam işi şöyle kurarım:
- Önce bir test projesi açın, sonra
dotnet build /bl:test.binlogile binlog alın. - .NET Agent Skills repo’sundan MCP server’ı kurun. (bu kritik)
- VS Code Copilot konfigürasyonuna bunu ekleyin. (bu kritik)
- Projeye bilerek bir hata sokun; eksik using, yanlış paket sürümü, ne çıkarsa artık. — ciddi fark yaratıyor
- Copilot’a “build neden patladı” diye sorun, cevaba biraz dikkat edin.
- Aynı şeyi ekibinizin gerçekten patlayan bir build’inde de deneyin.
Bu altıncı adım bence kritik. Çünkü sentetik testte her şey uslu uslu çalışıyor, ama gerçek hayatta tablo değişiyor; kirli kod tabanında, garip target tanımlarında, custom NuGet feed’lerinde, hatta bazen insanın “bu da nereden çıktı” dediği bir ayarda bile sonuç bambaşka oluyor. İşte asıl fark orada çıkıyor.
Sıkça Sorulan Sorular
Binlog MCP Server hangi.NET sürümleriyle çalışıyor?
Hani, MSBuild binary log formatı üreten her.NET sürümüyle çalışıyor. Yanı pratikte.NET Framework 4.7+ ve.NET 6/7/8/9 binlog’larını parse edebiliyorsunuz. Tabiî bazı eski format sürümlerinde hani belirli alanlar eksik kalabiliyor, bu da AI’ın verebileceği cevabı biraz kısıtlıyor.
Binlog dosyalarımı Copilot’a göndermek güvenli mi?
Kısacası, ne yalan söyleyeyim, Aslında bu duruma göre değişiyor (şaşırtıcı ama gerçek). Copilot Business. Enterprise planlarında prompt verileri model eğitimi için kullanılmıyor ve data residency garantileri var. Ama binlog’larınız hassas yol adları, ortam değişkenleri veya bağlantı bilgileri içeriyorsa — bunları temizlemek ya da self-hosted bir AI gateway üzerinden geçirmek bence çok daha mantıklı. Finans veya sağlık gibi regüle sektörlerdeyseniz mutlaka data classification yapın, açıkçası bu konuda risk almayın.
MCP server’ı self-hosted çalıştırabilir mıyım?
Evet, server tamamen local çalışıyor. Binlog parsing kısmı sizin makinenizde gerçekleşiyor, sadece AI asistanı yanı Copilot cloud taraflı. Eğer tamamen offline bir setup istiyorsanız, local LLM (Ollama, vs.) ile MCP-uyumlu bir client kullanarak air-gapped bir çözüm de mümkün. Tecrübeme göre kalite Copilot seviyesine ulaşmıyor ama yine de işe yarıyor.
Structured Log Viewer’ı tamamen bırakabilir mıyım?
Hayır, bence bırakmayın. MCP server hızlı sorular ve genel inceleme için gerçekten harika (ki bu çoğu kişinin gözünden kaçıyor). Ama mesela complex bir build issue’sunda, target dependency graph’ını görsel olarak takip etmeniz gerekiyor — orada viewer’a ihtiyacınız var. İkisini birlikte kullanın, biri diğerinin yerini tutmuyor.
Bu araç ileride ücretli olacak mı?
Şu an için açık kaynak ve ücretsiz, Microsoft’un.NET Agent Skills çatısı altında. Bence Copilot ekosisteminin organik bir parçası olarak ücretsiz kalmaya devam edecek,. Asıl gelir zaten Copilot lisanslarından geliyor. Ama tabiî %100 garanti yok, lisans modeli her zaman değişebilir.
Kaynaklar ve İleri Okuma
Microsoft.NET Blog: AI-Powered MSBuild Investigation with the Microsoft Binlog MCP Server
.NET Agent Skills GitHub Repository (buna dikkat edin)
İnanın, Model Context Protocol Resmî Dokümantasyonu
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder