FAQ for Developing in AL
This topic contains a number of frequently asked questions and answers to these questions.
How do I get started?
For an overview of developing apps for Dynamics 365 Business Central, see aka.ms/GetStartedWithApps
Next, follow the Get Started with AL to set up the tools.
Which version of the AL Language extension for Microsoft Dynamics 365 Business Central should I use?
For Dynamics 365 Business Central cloud sandboxes you must use the AL Language extension for Microsoft Dynamics 365 Business Central offcial release available in the Visual Studio Code Marketplace.
For the latest developer preview releases, you can use the latest pre-release available in the Visual Studio Code Marketplace or the AL Language extension for Microsoft Dynamics 365 Business Central, which is available in the next major artifact through the "Ready! for Dynamics 365 Business Central" program on Microsoft Collaborate.
How do I enable the debugger?
Why do the symbols downloaded to Visual Studio Code have different versions from the apps that are installed on my tenant?
We always download the highest published version of symbols. This means that if one of your dependencies has a higher version published, that version will be downloaded even if it's not installed for your environment.
Where do I find help regarding AppSource validation and submission?
What constitutes the identity of an app?
To read about app identity and why it is important to keep certain settings for an app unchanged, see App Identity.
File APIs are not available in Extensions V2. What do I do?
Code that relies on temporary files must be rewritten to rely on
OutStream types. Code that relies on permanent files must be rewritten to use another form of permanent storage.
DotNet types are not available in Extensions V2. What now?
For cloud solutions .NET interop is not available due to safety issues in running arbitrary .NET code on cloud servers.
With the AL Language extension for Microsoft Dynamics 365 Business Central, you can find AL types that replace the most typical usages of .NET like HTTP, JSON, XML, StringBuilder, Dictionaries, and Lists. Many .NET usages can be replaced directly by the AL types resulting in much cleaner code. For more information, see HTTP, JSON, TextBuilder, and XML API Overview.
For things that are not possible to achieve in AL code, the recommendation is to use Azure Functions to host the DLL or C# code previously embedded and call that service from AL.
Extensions published from Visual Studio Code or created using Designer have disappeared from a sandbox environment. Why?
Extensions that have been published to a sandbox environment from Visual Studio Code or created using Designer are removed when the sandbox environment is updated or relocated within our service. However, the data of an app is not removed, so you only have to re-publish and install the app to make it available.
If you have per-tenant extensions (PTEs) installed that depend on extensions published from Visual Studio Code, the per-tenant extensions will be removed too.
For more information, see Sandbox Environments.
Can I create something similar to Menusuites?
In the AL Language extension for Microsoft Dynamics 365 Business Central, the concept of Menusuites is not supported. The two primary purposes of Menusuites are:
- Making pages searchable
- Making pages accessible through a navigation structure
The first purpose can be achieved in Extensions by using the new properties added to Pages and Reports. For more information, see Adding Pages and Reports to Search.
The second purpose can be achieved by extending the Navigation Pane page and/or by adding Actions to other existing pages that can serve as a navigation starting point. For more information, see Adding Menus to the Navigation Pane.