Letztes Jahr, Mittelstandsprojekt, 60 Entwickler. Der Build-Server brauchte für die Hauptsolution 47 Minuten. Niemand wusste warum. Der Senior-Dev, der das ursprünglich aufgesetzt hatte, war seit zwei Jahren weg. Die .targets-Files waren ein Archäologieprojekt.
Ich habe damals drei Stunden mit dem MSBuild Structured Log Viewer verbracht, Binlogs händisch durchgeforstet, und am Ende war das Problem ein einziges <Target> das bei jedem Projekt dreifach ausgeführt wurde, weil jemand ein Import-Statement falsch gesetzt hatte. Drei Stunden für eine Zeile. Das wäre mit dem, was Microsoft gerade veröffentlicht hat, wohl anders gelaufen.
Was Microsoft hier eigentlich gebaut hat
Der .NET-Blog stellt den Microsoft Binlog MCP Server vor — einen Model Context Protocol Server, der MSBuild-Binlogs für KI-Assistenten wie GitHub Copilot zugänglich macht. Statt manuell durch den Structured Log Viewer zu klicken, kannst du deinen AI-Assistenten direkt fragen: "Warum schlägt mein Build fehl?" oder "Was macht meinen Build langsam?"
Das Tool bringt 15 spezialisierte Funktionen mit: Build-Fehler mit vollem Kontext, Property-Tracing (wo wurde diese Variable gesetzt?), Performance-Analyse der langsamsten Projekte und Tasks, Vergleich zweier Builds, und Zugriff auf eingebettete Quelldateien. Die Integration läuft über VS Code, Visual Studio 17.14+ oder die Kommandozeile — also auch Claude Code. Einrichtung: zwei Zeilen Konfiguration, dotnet tool run, fertig.
Der Ansatz ist technisch solide. MCP als Standard ist die richtige Wahl. Und 15 Tools statt eines monolithischen "analysiere alles"-Prompts zeigt, dass hier jemand mit Build-Systemen vertraut ist.
Wie das im KMU-Alltag wirklich landet
Lass mich direkt sein: Für wen das hier gebaut wurde, steht nicht im Artikel. Der Beitrag liest sich, als wäre die Zielgruppe ein .NET-Team bei Microsoft selbst oder ein Startup mit 5 Senior-Devs, die alle schon wissen, was ein Binlog ist, MCP konfiguriert haben und GitHub Copilot Enterprise abonniert haben.
Die Realität bei meinen Mandanten — Unternehmen zwischen 30 und 300 Mitarbeitenden, oft mit 3 bis 15 Entwicklern im Team — sieht anders aus.
Was davon sich lohnt:
Das Property-Tracing via binlog_explain_property ist Gold wert. Ich sehe regelmäßig Projekte, wo niemand mehr weiß, warum $(OutputPath) auf einen bestimmten Pfad zeigt oder woher $(DefineConstants) seine Werte bekommt. Das war bisher mühsame Handarbeit. Ein natürlichsprachiges "Wo kommt dieser Wert her?" ist ein echter Zeitgewinn.
Die Performance-Tools — binlog_expensive_projects, binlog_expensive_targets — sind für Teams wertvoll, die ihren Build-Prozess professionalisieren wollen, aber noch nicht wissen, wo sie anfangen sollen. Der Artikel nennt das Beispiel eines Builds mit 200+ Projekten. Solche Solutions existieren auch im Mittelstand: Große ERP-Eigenentwicklungen, historisch gewachsene Produktsuites. Hier zahlt sich das aus.
Der Build-Vergleich (binlog_compare) hat einen konkreten Use Case, den der Artikel nicht explizit nennt: Regressionsanalyse nach Dependency-Updates. Du willst wissen, ob sich nach dem NuGet-Update irgendetwas am Build-Verhalten geändert hat? Zwei Binlogs, eine Frage. Das ist praktisch.
Was nicht funktioniert, wie versprochen:
Der Artikel beschreibt die Einrichtung als "zwei Zeilen Konfiguration und fertig." Das stimmt — wenn dein Team bereits in der AI-Toolchain zu Hause ist. Für ein KMU-Entwicklungsteam, das mit VS 2022 und dem Standard-Setup arbeitet, bedeutet das zuerst: GitHub Copilot Enterprise oder eine andere MCP-fähige AI-IDE einrichten, verstehen was MCP überhaupt ist, und dann erst das eigentliche Tool konfigurieren.
Das ist kein Showstopper, aber es ist auch nicht "einfach mal ausprobieren." Es ist ein halber Tag Setup-Aufwand für jemanden, der das noch nicht kennt.
Was im Artikel fehlt:
Der Binlog enthält potenziell sensitive Informationen. Embedded source files, interne Property-Werte, Pfade zu internen Systemen. Der Artikel erwähnt das mit keinem Wort. Wenn du diesen MCP-Server mit einem Cloud-basierten AI-Assistenten verwendest — was die primäre Nutzungsart ist — schickst du Teile deines Builds in externe Infrastruktur. Für Teams mit NDA-Verpflichtungen oder Kunden aus regulierten Branchen ist das eine Abwägung, die getroffen werden muss. Ich sage nicht, dass man es nicht tun soll. Ich sage, dass man es bewusst tun soll.
Außerdem: Das Tool löst ein Symptom, nicht die Ursache. Warum ist dein Build komplex genug, dass du KI-gestützte Analyse brauchst? In vielen KMUs, die ich sehe, ist die Antwort: weil das Build-System über Jahre gewachsen ist ohne klare Verantwortung. Das Binlog MCP Tool hilft dir, die akuten Schmerzen zu diagnostizieren. Es hilft dir nicht, das strukturelle Problem zu lösen.
Meine Empfehlung
Wenn dein Team bereits GitHub Copilot oder eine andere MCP-fähige AI-Umgebung produktiv nutzt: Installier das Tool und probiere es bei eurem nächsten unklaren Build-Problem aus. Der Einstiegspunkt "dotnet build /bl && frag die KI" ist niedrigschwellig genug, dass du in 30 Minuten erste Ergebnisse hast.
Wenn du noch nicht in der AI-Toolchain unterwegs bist: Ich würde das nicht als Einstiegsgrund nehmen. Der Binlog MCP Server ist ein Werkzeug für Teams, die AI-gestützte Entwicklung bereits in den Arbeitsalltag integriert haben. Als erstes AI-Projekt für dein Team gibt es bessere Startpunkte mit schnellerem ROI.
Und unabhängig vom Tool: Wenn dein Build so komplex ist, dass du regelmäßig in die Logs musst — dann ist das das eigentliche Signal. Ein gut strukturierter Build mit klarer Projekt-Hierarchie und dokumentierten .targets-Konventionen braucht selten forensische Analyse. Das Binlog MCP Tool ist nützlich. Aber es ist ein Symptombehandler, kein Heilmittel.
Für den konkreten Einstieg: Erzeuge einen Binlog mit dotnet build /bl, schau ihn einmal händisch im MSBuild Structured Log Viewer an — das schärft dein Verständnis — und entscheide dann, ob die KI-gestützte Variante für euer Team Sinn ergibt.
Der vollständige Original-Beitrag von .NET Blog (MS): AI-Powered MSBuild Investigation with the Microsoft Binlog MCP Server
Hast du gerade ein Build-Problem, das dich beschäftigt — oder fragst du dich, ob das AI-Tooling für dein Entwicklungsteam überhaupt der richtige nächste Schritt ist? → 30 Min Klartext-Sparring
— Bernhard