Bis Mitte Juni 2025 ließ sich ein MAUI-Projekt mit dem Sentry-SDK problemlos für iOS/Mac Catalyst bauen. Nach dem Update auf Visual Studio 17.14.6 (Windows) hagelt es jedoch vier kryptische Cocoa-Fehler – alle verweisen auf eine Sentry.Bindings.Cocoa.xcframework in deinem lokalen NuGet-Cache. Der Build bricht ab, lange bevor Xcode oder der Apple-Linker ihr Werk tun. GitHub
Die Community hat den Common-Denominator schnell gefunden:
VS 17.14.5 → Build OK
VS 17.14.6 → Build KO („incorrect or unknown format … is a symlink“) GitHub
Warum passiert das mit Sentry?
Neue MAUI-Toolchain
VS 17.14.6 enthält eine aktualisiertemaui-publish-Pipeline. Beim Schritt native assets processing entpackt sie jede.xcframeworkin ein temporäres Verzeichnis.Symlinks in Sentry
Sentrys Cocoa-Binding nutzt symbolische Links, um mehrere Binär-Slices (iOS 17, Catalyst 17 etc.) in einer Zip zu bündeln. Die neue Pipeline verweigert jedoch Symlinks unter Windows und schmeißt einen incorrect or unknown format-Fehler.Falscher Suchpfad
Parallel verschiebt VS 17.14.6 einige .NET-iOS-SDK-Ordner. Der Remote-Build-Agent auf dem Mac sucht daraufhin Framework-Header an einer Stelle, die es nicht mehr gibt – und meldet ein generisches cocoa-error (pfadlos). GitHubGitHub
Work-arounds, die mit Sentry wirklich helfen
| Option | Aufwand | Effekt |
|---|---|---|
| VS zurück auf 17.14.5 (Installer → „Rollback“) | 5 min | Build läuft wieder – bestätigt von mehreren Issues GitHub |
| Sentry vorübergehend entfernen | 2 min | Projekt baut, aber kein Monitoring |
| Warten auf Patch (VS 17.14.7 oder Sentry 5.10.1+) | ? | Microsoft & Sentry-Team haben Bug als Regression markiert GitHub |
Tipp: Downgrade reicht meist; dein Mac-Agent muss nicht angefasst werden.
Mein persönliches Fazit
Dass eine Minor-Version von Visual Studio ein beliebtes Monitoring-SDK ausknockt, zeigt, wie fragil die Tool-Chain rund um MAUI noch ist. Ich empfehle aktuell:
Locken der VS-Version in CI/Build-VMs.
NuGet-Restore im Cache prüfen – korruptes Sentry-Paket löschen, bevor man stundenlang nach Pod-Fehlern sucht.
Bei wichtigen Releases: erst patchen, dann deployen – nie umgekehrt.
Bleibt zu hoffen, dass Microsoft die Symlink-Verarbeitung bald fixt. Bis dahin hilft nur „ein Schritt zurück“ – und natürlich ein gutes Monitoring für die Build-Pipeline selbst. 😉
Hast du ähnliche Stolpersteine? Lass es mich wissen – gemeinsam finden wir den Work-around, bevor der nächste Patch-Dienstag zuschlägt.
