If you are in the process of certifying your solution to be on the Microsoft Azure Marketplace, you will probably by working on cleaning up warnings in your Customization Analysis Report (CAR).
This post will help you learn about some known issues in the February 2016 version of the CAR report and describes cases where Microsoft will grant an exception from fixing a particular best practice warning.
To generate the Customization Analysis report (CAR), run the following command on a Dynamics AX development environment:
xppbp.exe -metadata=<local packages folder> -all -model=<ModelName> -xmlLog=C:\BPCheckLogcd.xml -module=<PackageName> -car=<reportlocation>
xppbp.exe -metadata=C:\Packages -all -model=MyAppSuiteCustomizations -xmlLog=C:\temp\BPCheckLogcd.xml -module=ApplicationSuite -car=c:\temp\CAReport.xlsx
(The xppbp.exe is located in c:\packages\bin or J:\AosService\PackagesLocalDirectory\bin)
All warnings and errors that appear in the Issues List sheet of the report must be resolved, unless they qualify for an exception or it is a known issue as described in this document.
Refer to this article for a description of CAR rules: https://ax.help.dynamics.com/en/wiki/car/
If your CAR report contains warnings in the Issues List sheet, and if a warning falls under any of the conditions described in this section, you will be granted an exception from fixing this warning. To document an exception, you can directly document it in the CAR report.
Also, if you attribute your X++ method with a BP suppression as shown in this example, the justification will appear in the CAR report.
[SuppressBPWarningAttribute("BPCheckSkipStatementValidation","Justification for suppressing the warning")]
public void mymethod()
When you customize (Over-lay) a method, you are practically taking ownership of the entire method, even if you only modify one line. If there is a warning on this method, and the warning is associated with a line of code that originally belongs to the baseline (lower layer) method (Owned by Microsoft or third party ISV), you can ignore this warning.
It is considered bad practice to add a large number of fields to an existing table because it may cause performance degradation, depending on usage and existing business logic. We recommend you get rid of this practice and define a new related table instead.
On the other hand, a warning associated with this rule will not block the process of certifying your Dynamics AX solution from the Azure Marketplace.
This rule fails if it finds a while select loop nested within a loop. This typically causes slow performance. Refactor your code to use joins instead of nested data access loops. If it is not possible to refactor the code without altering the business logic of your method, document an exception when you submit your Customization Analysis Report to Microsoft.
This rule fails if it finds nested select statements that aren’t joined. This typically causes performance degradation in your application. Refactor your code to use joins instead of nested select statements. If it is not possible to refactor the code without altering the business logic of your method, document an exception when you submit your Customization Analysis Report to Microsoft.
This rule fails if it finds "element" or "this" statements before the call to super() in the init method of a form. The intention of this rule is to make sure form runtime elements are not initialized before the call to super(). If this rule is violated, but the code in question does not cause any initialization to form runtime elements, an exception will be granted. Document an exception when you submit your Customization Analysis Report to Microsoft.
When a table relation does not define a delete action, but is used under any of the following conditions, you can ignore the BPCheckMissingDeleteActions best practice rule and should document an exception when you submit your Customization Analysis Report to Microsoft.
The table is a regular table but is only used to feed an SSRS report or any other reporting purpose. For example, the reporting table is related to a base table but the base table record must not be deleted even if the reporting table record is.
The table is a regular table but is only used as a log table, for example to log the status of a batch process.
A table relation references a log table that should not be deleted even if the related parent record is deleted.
This rule fails when the following condition is met: When you customize an Enum (over-layer), new Enum values are less than the maximum existing value + 10. However, if it is not possible to adhere to this rule because it will force you to use an Enum value that is > 250 (250 is the maximum allowed Enum value), document an exception when you submit your Customization Analysis Report to Microsoft.
This section describes know issues in the best practice rules of the CAR report. You can ignore any warning that falls under any of the known issues described below.
In some cases, this BP rule throws a warning on a relation that belongs to a table that you customized in your model, but the relation itself is not customized by your model (i.e. the faulty relation is defined in the baseline (lower layer) element).
If your warning falls in this category, i.e. the properties causing the warning do not belong to your model, you can ignore it. This bug will be fixed by Microsoft as part of a hotfix to the February 2016 release.
In some cases, this rule throws a warning on a customized table, even if you have not customized the properties TableGroup or CacheLookup in your model, i.e. the rule violation is coming from the lower-layer element.
If you have customized a class or a table that contains a method that violates the BPCheckSelectForUpdateAbsent rule, you may get this warning in your CAR report, even if you have not customized the faulty method.
Ignore any warning if it falls on a line of code that belongs to a method that you have not customized. This bug will be fixed by Microsoft as part of a hotfix to the February 2016 release.
This rule is designed to throw a warning if Select ForUpdate is used to select records, but an update isn’t being performed. It expects a call to the update or write method within the select loop. In some cases, this rule throws a warning even if a call to the write method is made. This is a bug and will be fixed.
If this rule fails on a field that does not have a label property defined, but it is associated with an EDT type that has a defined label, you can ignore the warning. This is a bug and will be fixed by Microsoft.