The AL Language extension (the language for developing applications for Microsoft Dynamics 365 Business Central) contains fourcode analyzers for analysis of your code at build time. “Code violations” are displayed in the Problem window when the code is analyzed. The information is valuable for identifying and jumping to Code Analysis Tool rule violations.

Now that you potentially have a list of “violations,” what if you want to treat them differently or even ignore them? Within the AL language, a few ways to control code analysis exist.

The al.codeAnalyzers setting allows you to specify which code analyzers are active for a particular environment, workspace or project. Code Analysis enforcement is only for the analyzers listed, leaving the option to only include the analyzers you want to enforce.

The al.codeAnalyzers settings identifies the code analyzers used in code analysis

Rulesets are another option for specifying how code analysis reports the issues it encounters while analyzing AL code. The name and path for the ruleset file is set with the al.ruleSetPath setting. A Ruleset file is a JSON file that contains the Rule objects that define how to report a specific rule. In a rule, you specify the id of the diagnostic, the action (None, Hidden, Warning, Error) to take when the diagnostic is encountered, and a justification comment to note the rule. A Ruleset is applied globally within the scope of the setting.

A Ruleset file is a JSON file that contains the Rule objects that define how to report a specific rule.

Another option to control Code Analysis problems is the Pragma Warning Directive. The pragma warning instruction allows you to enable or disable specific warnings in a location of code. When disabling warnings with the pragma directive, the warnings are not reset back to the original state until you restore them.

An example of using the pragma directive to disable the rule id AA0001 for one section of code and restoring it.

There are several ways to enhance Code Analysis in AL, leaving you the flexibility to manage your code. Remember that if you submit an extension to AppSource, that Code Analysis is part of the technical validation, and your Rulesets may hide issues that cause the extension to fail validation.

Note: The code listed in this article is for informational and demonstration purposes only. This content was created referencing Microsoft Dynamics 365 Business Central 2022 Wave 1

Microsoft Dynamics 365 Business Central Application Developers often need to store sensitive information their application uses. In earlier Dynamics NAV versions, developers often saved this data in table fields. The table field values were accessible to any other application or user that had access to the table. Information such as API keys, user credentials, or any additional information there is a desire not to have easily accessible was often stored and easily read from the table. Thankfully there is a more suitable way to do this in Business Central – Isolated Storage.

Isolated Storage in Microsoft Dynamics 365 Business Central is data storage that isolates data between extensions and even within the Extension. An application developer can store Key-Value Pairs in Isolated Storage and define the stored data’s scope (access level). Isolated Storage Key-Pairs’ DataScope can be limited to the Extension, a specific Company, a particular User, or a specific Company and User combination, providing an easy way for a developer to save values with a limited access scope.

Isolated Storage data isolation is accessed with the IsolatedStorage Data Type. The IsolatedStorage DataType provides methods to Set, Get, Delete or check if a Key Contains a value. 

The Set Method saves a Key-Value Pair to Isolated Storage within the scope defined in the DataScope parameter. 

The Get Method retrieves the Value for a Key in the scope defined by the DataScope parameter.

The Contains Method determines if the Key has a value in the scope defined by the DataScope parameter.

The Delete Method deletes the Value of a Key in the scope defined by the DataScope parameter.

For more information, see Isolated Storage.    

Note: The code listed in this article is for informational and demonstration purposes only. This content was created referencing Microsoft Dynamics 365 Business Central 2022 Wave 1

The AL Language extension (the language for developing applications for Microsoft Dynamics 365 Business Central) contains four code analyzers for analysis of your code at build time.

The AppSourceCop analyzer enforces rules for extensions intended for listing in Microsoft AppSource. Whereas the CodeCop analyzer enforces AL Coding Guidelines and the UICop analyzer enforces rules for the Web Client. The PerTenantExtensionCop analyzer enforces individual tenant rules.

The al.enableCodeAnalysis setting is used to set the state of code analysis and the al.codeanalyzers setting specifies which of the code analyzers to enable.

Note: as with most settings, the al.enableCodeAnalysis and al.codeanalyzers settings may be set for a project, workspace, or development environment.

Once the code analysis is enabled and the code analyzers specified, the Rule Id and Title appear for each file,  in the Problems window of the VS Code editor for any code “violations.”

It is possible to override the behavior of the code analyzer for specific Ids via the use of Pragma and Rulesets; that is for another time.

Note: The code listed in this article is for informational and demonstration purposes only. 

In the AL Language, the programming language behind Microsoft Dynamics 365 Business Central, the ModuleInfo Data Type provides information about an application. I have often used the ModuleInfo returned by the NavApp to check specific application version information.
The NavApp DataType includes information about a NavApp and has a few methods that retrieve a ModuleInfo for the Calling, Current or Specific application.

local procedure ModuleInfoDemo(ModuleInfoReqType: enum "DVLPR ModuleInfo ReqType");
    var
        ModuleInfo: ModuleInfo;
    begin
        case ModuleInfoReqType of
            "DVLPR ModuleInfo ReqType"::Calling:
                NavApp.GetCallerModuleInfo(ModuleInfo);
            "DVLPR ModuleInfo ReqType"::Current:
                NavApp.GetCurrentModuleInfo(ModuleInfo);
            "DVLPR ModuleInfo ReqType"::Specific:
                NavApp.GetModuleInfo('{c512d720-63b9-4b26-b062-a0c09b4ed322}', ModuleInfo);
        end;

        PopulatePageFields(ModuleInfo);
    end;

    local procedure PopulatePageFields(ModuleInfo: ModuleInfo)
    var
        i: Integer;
        ModuleDependencyInfo: ModuleDependencyInfo;
        DependencyNames: Text;
        AppVersion,
        DataVersion : Version;

    begin
        AppVersion := ModuleInfo.AppVersion;
        DataVersion := ModuleInfo.DataVersion;
        Clear(DependencyNames);

        ModuleID := Format(ModuleInfo.Id);
        ModuleName := ModuleInfo.Name;
        ModulePublisher := ModuleInfo.Publisher;
        ModuleAppVersion := Format(AppVersion);
        ModuleDataVersion := Format(DataVersion);
        ModulePackageId := Format(ModuleInfo.PackageId);

        for i := 1 to ModuleInfo.Dependencies().Count() do begin
            ModuleInfo.Dependencies.Get(i, ModuleDependencyInfo);
            DependencyNames += ModuleDependencyInfo.Name + ',';
        end;

        ModuleDependency := DependencyNames;
    end;