AX7 – Ignore-Liste für Best-Practice-Prüfungen

In AX 2012 gibt es ein Macro, das man erweitern kann, um einzelne Best-Practice-Prüfungen zu unterdrücken (SysBPCheckIgnore). Es gibt außerdem eine Menge Probleme damit, z. B. seine Größe, wie es kompiliert wird, dass es zu genau einem Model pro Layer gehört (was zu Kollisionen mit anderen Lösungen führt) usw. Es gibt natürlich für das ein oder andere auch Workarounds, aber auf jeden Fall gab es hier noch viel Raum für Verbesserungen. Im Folgenden erfährst du, wie das jetzt funktioniert und wie du es benutzen kannst.

Best-Practice-Optionen

In Visual Studio lässt sich das Regelwerk für die Best-Practice-Prüfungen über Tools > Options > Dynamics ‚AX 7‘ > Best Practices einrichten. Die Einstellungen erfolgen je Model. Man kann mit der Auswahlbox rechts oben im Fenster zwischen den Models hin- und herwechseln. Konkret beschäftige ich mich momentan mit dem Anpassungsanalysebericht / Customization Analysis Report, dessen Regeln in VS ebenfalls vorhanden sind und über den Eintrag Microsoft.Dynamics.AX.Framework.CustomizationAnalysisRules aktiviert werden können.

Best-Practice-Optionen

Prüfe und stelle auch noch sicher, dass beim Build überhaupt Best-Practice-Regeln geprüft werden – es gibt ein Kontrollkästchen dafür im Folgebereich Build unter der Bezeichnung Run best practice checks.
Man muss nach Änderung unter Umständen auch einen Rebuild ausführen, damit diese auch berücksichtigt wird – statt eines einfachen Build, den man aber sonst vorziehen sollte; bitte lies den Artikel Build operations aus dem Wiki für nähere Erläuterungen dazu.

Unterdrückung von Best-Practice-Prüfungen

Die Prüfungen und Meldungen von Best Practices können pro Model unterdrückt werden. Das Unterdrücken geschieht über eine XML-Datei, die man über einen Rechtsklick im Solution Explorer und der Auswahl von Edit Best Practice Suppressions erreicht.

Best-Practice-Unterdrückungen editieren

Wenn das ganze Thema neu für dich sein sollte, dann ist es wahrscheinlich, dass hierbei eine Fehlermeldung erscheint, weil die Datei einfach noch nicht existiert:

The Best Practice suppression list file
'C:\Packages\PackageName\ModelName\AxIgnoreDiagnosticList\
ModelName_BPSuppressions.xml' for model
'ModelName' does not exist. Make sure this file exists before
opening it in Visual Studio.

Fehlermeldung Best-Practice-Unterdrückungen editieren

Um die fehlende Datei zu erstellen, empfehle ich, eine vorhandene aus dem Standard zu kopieren. Es gibt z. B. eine im Verzeichnis C:\Packages\ApplicationSuite\Foundation\AxIgnoreDiagnosticList. Kopiere und füge sie in den Ordner AxIgnoreDiagnosticList unterhalb des gewünschten Models ein und nenne sie entsprechend um, dem Schema ModelName_BPSuppressions.xml folgend, wobei ModelName ersetzt werden muss durch den Namen deines Models – der zu wählende vollständige Dateiname steht zur Kontrolle auch in der Fehlermeldung).
Als nächstes öffnet man die Datei und korrigiert den Abschnitt Name (also z. B. Foundation_BPSuppressions zu ModelName_BPSuppressions). Dazu wirft man alles innerhalb der Klammerung Items weg, was dann zu folgendem Dateiinhalt führt:

<?xml version="1.0" encoding="utf-8"?>
<IgnoreDiagnostics>
  <Name>ModelName_BPSuppressions</Name>
  <Items>
  </Items>
</IgnoreDiagnostics>

Gegebenenfalls muss man den Schreibschutz der Datei entfernen, bevor man inhaltliche Veränderungen an ihr abspeichern kann.

Jetzt solltest du in der Lage sein, die Datei über Edit Best Practice Suppressions in Visual Studio zu öffnen. Vergiss nicht, dass sie zur Versionskontrolle hinzugefügt werden sollte (einfach im Source Control Explorer in das Verzeichnis des entsprechenden Models und über Add Items to Folder mit folgender Auswahl des Ordners AxIgnoreDiagnosticList).

Datei BPSuppressions

Einträge in der Ignore-Liste machen

Wie du schon in der Standard-Unterdrückungsdatei sehen konntest, wird jeder Eintrag in einem Tag Diagnostic geschachtelt und sieht schon eine ganze Menge notwendiger Informationen vor. Aber das macht nichts, weil man die korrekte Syntax einfach aus einer bereits existierenden Datei kopieren kann! Jeder ausgeführte Build erzeugt eine XML-Datei mit den Ergebnissen im entsprechenden Package-Verzeichnis. Wenn man also ein Model buildet, das zur Application Suite gehört, so wird die Datei BuildModelResult.xml unter C:\Packages\ApplicationSuite neu erstellt. Man muss nur nach dem richtigen Eintrag darin suchen (ich benutze ein Beispiel, das sich auf etwas bezieht, was im Standard noch nicht korrigiert wurde – ein sicherlich bald implementiertes, aber noch fehlendes Form Pattern für die Form AssetWarehouseTransfer), diesen kopieren, einfügen und ein kleines bisschen anpassen. Man benötigt nur die Tags DiagnosticType, Severity, Path, Moniker und Justification. Also muss man lediglich die bisherige Message durch eine aussagekräftige Justification ersetzen, sprich eine Begründung für die Unterdrückung hinterlegen.

    <Diagnostic>
      <DiagnosticType>BestPractices</DiagnosticType>
      <Severity>Warning</Severity>
      <Path>AxForm/AssetWarehouseTransfer/Design</Path>
      <Moniker>BPErrorFormDesignPatternUnspecified</Moniker>
      <Justification>Microsoft surely assigns a pattern soon.</Justification>
    </Diagnostic>

Kopieren aus Datei BuildModelResult

PS: Wusstest du schon, dass man die Error List in Visual Studio mit dem Suchfeld in der rechten oberen Ecke filtern kann (siehe auch Screenshot)? Sinnvoll eingesetzt ist das ein mächtiges Werkzeug 🙂

PPS: Tatsächlich hatte ich noch ein paar Schwierigkeiten, die richtigen Best-Practice-Verletzungen aus den Build-Log-Dateien herauszubekommen, wenn man ein einzelnes Projekt kompiliert (es gibt auch eine Datei BuildProjectResult.xml). Außerdem wirkt es so, als würden beim vollständigen Build eines Package nicht alle angehakten Best-Practice-Regeln sauber berücksichtigt / geloggt. Ich bin sicher, dass das bis spätestens zum Release verbessert oder klargestellt wurde. Nachdem die Syntax eines solchen Eintrags auch nicht allzu kompliziert ist, sollte man im Zweifelsfall auch in der Lage sein, einen funktionierenden selbst zu formulieren. Sollten meine Annahmen fehlerhaft oder meine Angaben ungenau sein, lass mich das bitte in den Kommentaren wissen 🙂

Jetzt ich fast vergessen, darauf hinzuweisen

Ich möchte den Post damit schließen, darauf hinzuweisen, dass man natürlich nicht einfach Best-Practice-Fehler und -Warnungen unterdrücken soll! Das sollte man nur dann tun, wenn man sich absolut sicher ist, dass im einzelnen und speziellen Fall keine Verletzung vorliegt.

Schreibe einen Kommentar