Binlog MCP Server: Build Sorunlarını Copilot'a Çözdürmek

⏱️ 11 dk okuma📅 20 Haziran 2026🔄 Güncelleme: 15 Temmuz 2026

Ş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.

📋 İçindekiler

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.

Şö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.

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)

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.

💡 Bilgi: Binlog MCP server’ı doğrudan CI/CD pipeline’larınızda da kullanabilirsiniz. Build failure durumunda otomatik olarak binlog’u parse edip Slack/Teams’e özet gönderen agent’lar kurmak mümkün. Bu, “build kırıldı” mesajının ötesine geçip “şu nedenle kırıldı, şuradan başla” der.

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.binlog ile 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

MSBuild Structured Log Viewer

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102