In AX 2012 there’s a macro you can extend to suppress best practice checks (SysBPCheckIgnore). There are a lot of issues related to it, e. g. its size and compilation, the fact that it belongs to exactly one model per layer (colliding with other solutions) etc. Of course there are some workarounds but clearly there was room for improvement. Here’s what we have now and how you deal with it.
Best Practice Options
You can set up the set of best practice rules that get checked during compile via Tools > Options > Dynamics ‘AX 7’ > Best Practices in Visual Studio. The definition of the rule set is per Model. You switch between the models using the combo box in the right upper corner. In particular I’m dealing with the outcome of the Customization Analysis right now, the rules for it are available in VS, too. You need to activate Microsoft.Dynamics.AX.Framework.CustomizationAnalysisRules for the whole set of rules.
Make sure the build itself does BP checking – there’s a check box for that in the next area, Build, named Run best practice checks.
You might have to Rebuild (instead of Build what you should use usually because it’s way faster btw – please visit the Wiki article Build operations for further information) to get the new BP rule set applied.
Best Practice Suppressions
Best practice messages can be suppressed per model. This is driven by an XML file. You can access it by right-clicking a project in Solution Explorer and selecting Edit Best Practice Suppressions.
If this is new to you it’s likely that you’ll face an error message telling the file that is used for suppression does not exist yet:
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.
To create the missing file I’d suggest to simply copy one that is included in standard already. There’s one in C:\Packages\ApplicationSuite\Foundation\AxIgnoreDiagnosticList, for example. So copy and paste it to your model’s AxIgnoreDiagnosticList folder and rename it to the correct name, ModelName_BPSuppressions.xml (replace ModelName with your model’s name of course – you can see it in the error message).
Next you’ll want to open the file and replace the Name part with yours (Foundation_BPSuppressions to ModelName_BPSuppressions) and remove everything inside the Items opening and closing tags. The resulting content of the file looks as follows:
<?xml version="1.0" encoding="utf-8"?> <IgnoreDiagnostics> <Name>ApplicationSuite.GWS_BPSuppressions</Name> <Items> </Items> </IgnoreDiagnostics>
To be able to save the file you might have to remove the Read-only attribute of it first.
Now you are able to open the file by using Edit Best Practice Suppressions in Visual Studio. Do not forget to add it to version control (using Source Control Explorer and Add Items to Folder in your model’s directory, selecting the AxIgnoreDiagnosticList folder entirely).
Add Entries to Suppression List
As you saw in the standard suppression file before every entry is in a Diagnostic tag and has a seemingly complicated structure. The very cool thing is you can get the correct entry from an existing file! Every build you execute leads to resulting xml files in the related package folder. So if you build your model that belongs to Application Suite in folder C:\Packages\ApplicationSuite the file BuildModelResult.xml gets rebuilt. You only need to search for the right entry there (I use an example that is left in standard as of now – a yet to come form pattern application for form AssetWarehouseTransfer), copy, paste and slightly modify it. According to what is in the standard suppression file you only need the tags DiagnosticType, Severity, Path, Moniker and Justification. Therefore you only need to replace the former Message by a meaningful Justification.
<Diagnostic> <DiagnosticType>BestPractices</DiagnosticType> <Severity>Warning</Severity> <Path>AxForm/AssetWarehouseTransfer/Design</Path> <Moniker>BPErrorFormDesignPatternUnspecified</Moniker> <Justification>Microsoft surely assigns a pattern soon.</Justification> </Diagnostic>
PS: Did you know that you can filter the Error List in Visual Studio by using the search field in the upper right corner (see screenshot)? Very powerful!
PPS: Actually I experienced some trouble with getting the right BP entries out of the build of a single project (there’s a BuildProjectResult.xml file as well). Additionally it seems like not all BP rules I checked are logged to the file during full package build. I’m sure this will be improved / clarified until RTW at the latest. Since the syntax is not too complicated you should be able to type working entries in case of necessity, I think. If you realize my expectations are wrong, please let me know in the comments 🙂
What I nearly forgot to say
I would like to put an end to this with pointing out that you should not suppress Best Practice Errors and Warnings unless you are pretty sure about they are not reasonable in that particular case!