Was ist der Microsoft Solution Checker?

Der Solution Checker ist in der Power Platform eingebaut und kostet erstmal nichts extra. Er führt eine statische Analyse Ihrer Lösung durch und meldet Verstöße gegen einen Satz von Best-Practice-Regeln, den Microsoft pflegt.

Wer regelmäßig Anpassungen ausliefert, sollte ihn kennen. Er ersetzt aber nicht jede Art von Prüfung, und es lohnt sich zu verstehen, wo seine Zuständigkeit endet.

Was er prüft

Der Schwerpunkt liegt auf Code und Konfiguration.

• Web-Ressourcen und JavaScript: veraltete APIs aus früheren Versionen, unsichere Muster wie "eval" oder direkte Zuweisungen an "innerHTML", Aufrufe auf Endpunkte, die abgekündigt sind, vergessene Debug-Anweisungen.
• Plug-ins und Workflow-Aktivitäten: doppelte Registrierungen, Schritte ohne Filterattribute, Registrierungen auf Nachrichten, bei denen es teuer werden kann.
• Power Automate Flows über den Flow Checker und Power-Fx-Ausdrücke über die App-Prüfung.
• Canvas Apps: unter anderem Barrierefreiheit, etwa fehlende Beschriftungen für Bildschirmleser.

Jeder Fund kommt mit Kategorie, Schweregrad und einem Link auf die Dokumentation, die erklärt, wie man ihn behebt.

Wie Sie ihn ausführen

In Power Apps unter Lösungen, dort neben der nicht verwalteten Lösung über das Kontextmenü. Die Analyse läuft einige Minuten, danach kommt eine Benachrichtigung. Die Ergebnisse lassen sich im Portal ansehen oder als Excel herunterladen (vorsicht, eine Prüfung sehr Lösung kann sehr lange dauern)

Alternativ gibt es ein PowerShell-Modul, mit dem sich die Prüfung in eine Build-Pipeline einbauen lässt. Für Teams, die regelmäßig ausliefern, ist das die sinnvollere Variante, weil die Prüfung dann automatisch mit einer Pipeline bei jeder Änderung läuft.

Für JavaScript gibt es zusätzlich ein ESLint-Plugin, das dieselben Regeln schon in der Entwicklungsumgebung anwendet. Das ist der früheste Zeitpunkt, zu dem man einen Fehler finden kann, und damit der billigste.

Wo die Grenzen liegen

Drei Einschränkungen sind wichtig.

Er läuft nur auf nicht verwalteten Lösungen. Wer eine fremde, verwaltet ausgelieferte Lösung bewerten will, kann ihn nicht einsetzen. Dies trifft z.B. zu, wenn ein Externer Dienstleister eine eigene Lösung mitbringt oder Funktionalität mit einem Drittanbieter Tool als verwaltete Lösung eingesetzt wird.

Er läuft nur innerhalb der Umgebung. Sie brauchen Zugriff auf die Umgebung, in der die Lösung liegt. Eine Lösung vorab zu bewerten, bevor man sie übernimmt, geht damit nicht. Dies erfordert für Sie Zugriff auf Administrative Accounts.

Er prüft Code, nicht Struktur. Ob Ihre Felder dokumentiert sind, ob die Namensgebung einheitlich ist, an wie vielen fremden Lösungen Ihre hängt oder ob Umgebungswerte fälschlich mitgeliefert werden: Dafür ist er schlicht nicht gebaut. Bei einer Übernahme oder Migration sind das allerdings die Fragen, an denen es oft hängt.

Microsoft selbst weist zudem darauf hin, dass ein sauberes Ergebnis keinen erfolgreichen Import garantiert. Die statische Analyse kennt den Zustand der Zielumgebung nicht.

Sinnvoll eingesetzt

Womit er sich ergänzt, zeigt der Überblick über die kostenlosen Analyse-Tools [Artikel dazu folgt in Kürze und wird dann querverlinkt]. Für den Zustand der UMGEBUNG statt der Lösung ist übrigens ein anderes Werkzeug zuständig, der Solution Health Hub.

Der Solution Checker gehört in die Auslieferungskette, am besten automatisiert. Er findet zuverlässig Code-Muster, die man von Hand übersieht, und die Verweise auf die Dokumentation machen die Behebung nachvollziehbar.

Für die Fragen daneben, also Zustand, Wartbarkeit und Übernahmefähigkeit, braucht es eine andere Betrachtung. Das ist kein Mangel des Checkers. Er will diese Fragen gar nicht beantworten.