Prinzipiell sollte jede Lösung in Dynamics 365 for Finance and Operations frei von Best-Practice-Abweichungen sein, dennoch gibt es ab und an die Notwendigkeit, sie unterdrücken zu müssen.
Ein solcher Fall sind beispielsweise Eventhandler, die ein vorgegebenes Paramterprofil aufweisen, im Falle eine Nicht-Verwendung eines dieser Parameter aber eine BP-Abweichung verursachen.
class MyFreeTextInvoiceHeaderFooterTmpEH
{
[DataEventHandler(tableStr(FreeTextInvoiceHeaderFooterTmp), DataEventType::Inserting)]
public static void FreeTextInvoiceHeaderFooterTmp_onInserting(Common sender, DataEventArgs e)
{
FreeTextInvoiceHeaderFooterTmp freeTextInvoiceHeaderFooterTmp;
freeTextInvoiceHeaderFooterTmp = sender;
if (freeTextInvoiceHeaderFooterTmp.CompanyBankAccount == "")
{
freeTextInvoiceHeaderFooterTmp.CompanyBankName = "Unknown";
}
}
}
Bei obigem EH würde folgende BP-Abweichung ausgegeben werden, da der Parameter e nicht verwendet wird:
BP Rule: [BPParameterNotUsed]:The parameter 'e' is not used.
Um dies zu verhindern kann man im einfachsten Fall das Attribute SuppressBPWarning verwenden:
Es besteht aber auch die Möglichkeit, all diese Suppressions in einer modulgebundenen Datei zu sammeln. Dazu muss man im Verzeichnis des Modules eine XML-Datei wie folgt anlegen:
<?xml version="1.0" encoding="utf-8"?>
<IgnoreDiagnostics>
<Name>YourModel_BPSuppressions</Name>
<Items>
<Diagnostic>
<DiagnosticType>BestPractices</DiagnosticType>
<Severity>Warning</Severity>
<Path>dynamics://Class/MyFreeTextInvoiceHeaderFooterTmpEH/Method/FreeTextInvoiceHeaderFooterTmp_onInserting</Path>
<Moniker>BPParameterNotUsed</Moniker>
<Justification>Event handler parameters that cannot be removed from the method's signature.</Justification>
</Diagnostic>
</Items>
</IgnoreDiagnostics>
Darauf achten, daß im XML der Name des Models den Gegebenheiten angepasst werden muss.
DiagnosticType ist immer "BestPractices". Severity, Path und Moniker können meist aus der Fehlermeldung in der Error list von Visual Studio ausgelesen werden. Meiner Erfahrung nach aber leider nicht immer. In diesem Fall kann man auf dieser Seite nachlesen, ob man einen passenden Moniker findet:
Mir selbst sind bislang die folgenden Monikers über den Weg gelaufen:
BPParameterNotUsed
BPEmptyCompoundStatement
BPErrorMethodUnbalancedTtsbeginCommit
BPCheckParametersModified
BPUpgradeCodeLateBoundCall
BPErrorClassNewNotProtected
Sobald man eine solche XML-Datei angelegt hat, kann man das Kontextmenü des Projektes von Visual-Studio nutzen, um die Datei zu berarbeiten: Edit Best practice suppressions
Man kann für diese XML-Datei übrigens im selben Verzeichnis ein XML-Schema ablegen, um den folgenden Fehler zu vermeiden:
Could not find schema information for the element 'IgnoreDiagnostics'.
Ein solches Schema erstellt man über Visual-Studio unter XML > Create schema (dieses Menü ist nur verfügbar, wenn man grade eine XML-Datei geöffnet hat).
Um die XML-Datei (und ggf. das Schema) zur Versionskontrolle hinzuzufügen, muss man über den Source Control Explorer in das Verzeichnis des entsprechenden Models wechseln und über Add Items to Folder die Dateien auswählen.
Übrigens hab ich die Erfahrung gemacht, daß man die XML-Datei ausserhalb von Visual-Studio bearbeiten sollte.
Dieser Beitrag bezieht sich auf die Version: Dynamics 365 for Finance and Operations
Diese Webseite verwendet Cookies, um Benutzern einen besseren Service anzubieten. Wenn Sie weiterhin auf der Seite bleiben, stimmen Sie der Verwendung von Cookies zu.
Mehr dazu
Prinzipiell sollte jede Lösung in Dynamics 365 for Finance and Operations frei von Best-Practice-Abweichungen sein, dennoch gibt es ab und an die Notwendigkeit, sie unterdrücken zu müssen.
Ein solcher Fall sind beispielsweise Eventhandler, die ein vorgegebenes Paramterprofil aufweisen, im Falle eine Nicht-Verwendung eines dieser Parameter aber eine BP-Abweichung verursachen.
Bei obigem EH würde folgende BP-Abweichung ausgegeben werden, da der Parameter e nicht verwendet wird:
Um dies zu verhindern kann man im einfachsten Fall das Attribute SuppressBPWarning verwenden:
Es besteht aber auch die Möglichkeit, all diese Suppressions in einer modulgebundenen Datei zu sammeln. Dazu muss man im Verzeichnis des Modules eine XML-Datei wie folgt anlegen:
K:\AosService\PackagesLocalDirectory\YourModel\YourModel\
AxIgnoreDiagnosticList\YourModel_BPSuppressions.xml
Darauf achten, daß im XML der Name des Models den Gegebenheiten angepasst werden muss.
DiagnosticType ist immer "BestPractices". Severity, Path und Moniker können meist aus der Fehlermeldung in der Error list von Visual Studio ausgelesen werden. Meiner Erfahrung nach aber leider nicht immer. In diesem Fall kann man auf dieser Seite nachlesen, ob man einen passenden Moniker findet:
https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/dev-tools/customization-analysis-report
Mir selbst sind bislang die folgenden Monikers über den Weg gelaufen:
Sobald man eine solche XML-Datei angelegt hat, kann man das Kontextmenü des Projektes von Visual-Studio nutzen, um die Datei zu berarbeiten: Edit Best practice suppressions
Man kann für diese XML-Datei übrigens im selben Verzeichnis ein XML-Schema ablegen, um den folgenden Fehler zu vermeiden:
Ein solches Schema erstellt man über Visual-Studio unter XML > Create schema (dieses Menü ist nur verfügbar, wenn man grade eine XML-Datei geöffnet hat).
Um die XML-Datei (und ggf. das Schema) zur Versionskontrolle hinzuzufügen, muss man über den Source Control Explorer in das Verzeichnis des entsprechenden Models wechseln und über Add Items to Folder die Dateien auswählen.
Übrigens hab ich die Erfahrung gemacht, daß man die XML-Datei ausserhalb von Visual-Studio bearbeiten sollte.