- Get started with Dynamics 365
Stay on top of the latest features and releases
FastTrack your deployment
Speed up your rollout with personalized tools, resources, and best practices
Find the right eLearning courses for your role
Resources for people with disabilities
Learn how Dynamics 365 supports your GDPR compliance journey
- Get started with Dynamics 365
The AL developer environment is evolving with frequent updates. To stay up to date on the latest information and announcements, follow us on the Dynamics NAV Team Blog.
Development in AL
Extensions are a programming model where functionality is defined as an addition to existing objects and defines how they are different or modify the behavior of the solution. This section explains how you can develop extensions using the development environment for Dynamics 365 Business Central.
If you are new to building extensions, we recommend that you read this document to get an understanding of the basics and terms you will encounter while working. Next, follow the Getting Started with AL to set up the tools.
If you are looking for the C/SIDE documentation, visit our Dynamics NAV library.
Understanding objects in the development environment
All functionality in Dynamics 365 Business Central is coded in objects. The extension model is object-based; you create new objects, and extend existing objects depending on what you want your extension to do. Table objects define the table schema that holds data, page objects represent the pages seen in the user interface and codeunits contain code for logical calculations and for the application behavior. These objects are stored as code, known as AL code, and are saved in files with the
.al file extension. The AL Language extension also supports the multi-root functionality which allows you to work with multiple AL folders within one workspace. For more information on how to group a set of disparate project folders into one workspace, see Working with multiple AL project folders within one workspace.
A single .al file may contain multiple objects.
There are two other special objects which are specifically used for building extensions. Table extension objects and page extension objects are used for defining additive or overriding changes to table or page objects. For example, an extension for managing a business that sells organic food may define a table extension object for the Item table that contains two additional fields,
Produced Locally. The
Produced Locally fields are not usually present in the Item table, but through the table extension these data fields will now be available to store data in and to access from code. You can then use the page extension object to display the fields that you added to the table object.
Extension objects can have a name with a maximum length of 30 characters.
You have several options for creating new objects with the AL Language extension for Visual Studio Code. For more information about the objects that you can create for your extension, see AL Development Environment.
Developing extensions in Visual Studio Code
Using the AL Language extension for Visual Studio Code, you will get the benefits of a modern development environment along with seamless publishing and execution integration with your Dynamics 365 Business Central tenant. For more information on getting up and running, see Getting Started with AL.
Visual Studio Code and the AL Language extension lets you do the following tasks:
- Create new files for your solution
- Get assistance with creating the appropriate configuration and setting files
- Use code snippets that provide templates for coding application objects
- Get compiler validation while coding
- Press F5 to publish your changes and see your code running
For more information, see Visual Studio Code Docs.
If you have previous experience working with the C/SIDE development environment and need an overview of some of the changes between the two development environments, see Differences in the Development Environments.
The Designer works in the client itself allowing design of pages using a drag-and-drop interface. The Designer allows building extensions in the client itself by rearranging fields, adding fields, and previewing the page design. For more information, see Using Designer.
Compiling and deploying
Extensions are compiled as .app package files. The .app package file can be deployed to the Dynamics 365 Business Central server. An .app package contains the various artifacts that deliver the new functionality to the Dynamics 365 Business Central deployment as well as a manifest that specifies the name, publisher, version, and other attributes of the extension. For information about the manifest, see JSON Files.
Submitting your app
When all development and testing is done, you can submit your extension package to AppSource. Before you submit the extension package, we encourage you to read the checklist to help facilitating the validation. For more information, see Checklist for Submitting Your App.
Lately, a number of ISVs have asked me this question:
If you where me, what would you do?
To give the question a little context, we are talking about Solutions, Customizations, Extensions, Modifications or whatever name you use. We are talking On-prem, Hosted, Managed Service, Dynamics 365 for financials.
What is the magic bullet? What should the ISV do in order to make sure that you are ready for the future, without wasting a lot of time.
The answer can really be given from a technical or from a business model perspective, but since I am a Technical Evangelist (and not a Business Model Evangelist:-)), I have decided to see things from the technical side. I claim, that even if you would see this from the business model side, you will reach the same conclusions.
This post is my response to these ISVs.
Let me first start by defining a number of different “states” an ISV solution can be in. This list is not be complete, people can be in between or have more than one solution, but work with me on this, don’t get caught up on the details:
- Solutions are customer specific, every customer is running on their own version of the app on their own server (on-prem or hosted) and the customer pays to get upgraded to new versions of NAV. Best practices are followed as to tagging code customizations and a merge tool is used to merge the latest update from Microsoft with the customer solution when the customer decides to do so.
- Like 1 – except the solution is a standard solution following the guidelines of the Road to Repeatability program. Customers still decide when to upgrade to a new version, but when they do, they get the latest version, which is the same for all.
- Like 2 – except that the solution is running in a multi-tenant environment and all customers are in fact running on the same versions of the app. When upgrading, a new multi-tenant environment is spun up and customers are moved over.
- Like 2 or 3 – except that the solution is using event based architecture, using events to modify base behavior where possible and if no events are available, a new event is introduced in the base app as the only code modification to merge. A merge tool or the merge Cmdlets are used to automagically merge updates from Microsoft with the solution.
- Like 4 – except that the solution is actually packaged as an extension, meaning that all customers will be using the same base app and the individual tenants can install the extension if they like. Upgrade is done by rolling the extension off and on again, restoring the data where needed.
- Like 5 – except that the extension is Saasified and uploaded to AppSource and Cutomers using Dynamics 365 for Financials (always multi-tenant) can install the extension, try it out for free and the app can request a registration and/or payment to use full functionality. Upgrades are handled automagically every month.
These six models really showcase the transformation solutions in NAV has taken – just over the last approx. 5 years and no wonder that it can be hard to follow along – and now Microsoft is talking about Extensions v2 and Visual Studio Code????
You can probably easily identify where you are on the stairway – and maybe you even have a clear plan on where to do?
For every step you take up the stairway, you will meet challenges. Some are easy to overcome, some harder. Some challenges might even be to the point, where you decide not to take that step, but please be aware, that you normally cannot skip any steps on a stairway. You need somehow to get over it or be stuck below that step.
Here are a few of the challenges you will meet on your way:
step 3 – multi-tenancy means people cannot write to the app database, some scenarios are harder.
step 5 – real extensions means that you will have to live with the events that are exposed by the base app, you cannot modify and add new events.
step 6 – no server side DLLs, no file access, only limited .net interop, no Windows Client.
and when we talk about extensions v2 and Visual Studio Code, there will be more challenges, which Microsoft will try to provide good workarounds for (either by extending the language or making built in support for stuff like Azure Functions and Web APIs)
Note, that it is important for Microsoft to hear about the challenges from Partners. Microsoft cannot foresee every single obstacle every partner will ever run into, so feedback is important, whether it is missing events, missing functionality or other things that prevents partners from taking the next step up the stairways.
So, what would I do?
I assume that you want to move up the stairway – all the way to the top of the stairway to heaven… (sweet music:-))
I assume that you eventually want to be standing on the top with an app in AppSource but what should you do to get there? Should you wait until Dynamics 365 for Financials is in your country? and what if that date isn’t even planned yet?
If my solution was on step 1-3 on the stairway – I would refactor it in order to get to step 4 – Event Based Architecture.
Getting to step 4 will put you in a better place and doesn’t really add any challenges that cannot easily be overcome. It is just a good way of writing your code, which makes updates and merges easier and will enable you to identify missing events and know more about what it takes to move to an extension. This work can be done in NAV 2017 using the Classic Development environment.
Once at step 4 or above you can decide to continue up the stairway using Extensions v1 and the classic development environment or you can switch to Extensions v2 and use Visual Studio Code – and this is really determined by timing.
How does your code look at step 4
When refactoring your code for step 4 you should think about the next steps, but you shouldn’t limit yourself due to challenges you see today.
- Use events to intercept base app functionality and add your own behavior.
- Introduce new events in the base app if you cannot find events that meets your needs – this will be a code modification causing a delta and a challenge when moving to the next step. Postpone the resolution of that challenge until you take the next step, but check NAV Tenerife to see whether that event is coming – else notify Microsoft about the missing event.
- If you have code which you know will cause challenges at higher steps (could be Web Services communication, calling a DLL or other things), then encapsulate this in functions and use these functions throughout. Postpone the resolution to that challenges until you take the next step, but check NAV Tenerife to see if and how this challenge can be solved.
- Do not limit yourself to whats possible in Extensions v1 or in Extensions v2 today. If you meet a challenge, encapsulate the challenge, document, check NAV Tenerife, tell Microsoft and then postpone.
- Saasify your solution, use assisted setup, wizards, notifications and other tools to make sure, that your app is easy to use and doesn’t require a lot of training hours for users to understand.
- Make good use of design patterns in your implementation.
You can (and should) really perform a lot of the refactoring of your solution at step 4, when refactoring for the event based architecture. At this step, you can still ship, test and develop your software. You are in a safe haven.
Extensions v1 vs Extensions v2?
I hope that it is clear by now, that step 4, the event based architecture is the place to get to and that this has absolutely nothing to do with Extensions v1 or Extensions v2. It also has nothing to do with whether or not Dynamics 365 is available in your country – it is just a good step to be on and take a rest. Furthermore… it is a necessary step.
The two options you have now is Extensions v1 or Extensions v2. Extensions v1 is out there in NAV 2017 and apps on AppSource today is based on Extensions v1. Extensions v2 is in preview and you probably won’t be able to publish apps on AppSource before summer of 2017 using Extensions v2. Extensions v1 is likely to be deprecated in AppSource some time during 2017.
New events are available in CTP drops of NAV Tenerife – both for Extensions v1 and Extensions v2.
Extensions v1 and Extensions v2 will be supported in NAV Tenerife (on-prem). Extensions v1 will likely be deprecated in a future NAV release.
Whether Classic NAV Development will be deprecated at some point in time in the future – I have no idea and that is totally unrelated to this blog post.
Extensions v1 has limitations on where you can add code and it is cumbersome to work with. Extensions v2 is still in preview and doesn’t have full functionality yet.
With this info, it isn’t really a question about one or the other. It is more a question on when do you move to Extensions v2? and whether you are going to use Extensions v1?
Should you use Extensions v1 (C/SIDE)?
Maybe you are already on step 5 with extensions v1 or maybe you have an app in AppSource and you are at step 6, then you of course would use extensions v1 until you select to move to extensions v2.
If not, then IMO, you should have a business reason for taking step 5 with extensions v1. That reason could be that you need to ship something to AppSource tomorrow – then your only option really is Extensions v1.
When should you move to Extensions v2 (Visual Studio Code and In-Client Designer)?
If you haven’t already done so, you should spend some time on the NAV Developer Preview.
You should familiarize yourself with the new development environment, read the blog posts on the NAV Team Blog, follow the questions and issues on GitHub, Investigate the samples on GitHub and the earlier you get started, the better your chances of influence the shape of Extensions v2.
The conversion tool is likely to be shipped in the April update of the NAV Developer Preview and should be able to help you convert from Step 4, 5 or 6 to the same step using the new Development environment – allowing you to take the final steps in Extensions v2.
The conversion tool is not going to take you all the way, you will probably have to do some manual work too. You might also find that it would be best to refactor a few things in C/SIDE before the conversion to make the conversion run more smooth. Do that, run some test conversions and move over to Extensions v2 and Visual Studio Code once you have a business reason for making the move.
If you want to move your solution forward and up the stairway, you need to consider a few things.
If you are not there yet, you need to refactor your code to step 4 – Event Based Architecture.
While at step 4, make sure that you have everything in place for the next steps before going there.
- Identify challenges and engage with app solution providers or Microsoft to solve these.
- Easy to use user interface (how do users get a WOW experience in just 5 minutes of using your app)
- Test automation (when upgrades and release are automatic, you need to have high code quality)
- Sustainable Dev Structure (agile development, source code management, release management etc.)
- Good alignment between Marketing and Engineering
When you have all these things in place the next steps up the stairway are easy to see and easier to overcome.
I hope this is helpful
The Txt2Al conversion tool allows you to take existing Dynamics NAV objects that have been exported in .txt format and convert them into the new .al format. The .al format is used when developing extensions for Dynamics 365 Business Central and Dynamics NAV. Converting the objects consists of following two steps:
- Exporting the objects from C/SIDE in a cleaned format.
- Converting the objects to the new syntax.
Designing with customer regular license.
I was thinking about difficulties to teach NAV design to final customers without full developing license. Most of customer licenses only can develop code in reports and XML ports. They can´t put code into Codeunits, table and pages.
So essentially teaching final customers is create new tables, fields, pages and mainly report builder design. It´s easier to teach customer with full dev license, closer to your daily work and you are not fighting all the sessions with license limits and the absolute not funny fact: you can´t develop business logic.
The test with Visual Studio Code.
We configure in Nav 2018 local machine service with the specifications:
– No dev full license.
– Codeunit Objects purchased from 50000 to 50099.
A very common scenario in NAV customer final license.
So, the first test is develop an extension and deploy it pressing F5. The result is:
It failed because an object was out of 50000..50099 range (50150). If I change the number of the extension into available number range, the extension is successfully created.
I also notice, anyway with or without right range, the package can be created.
Conclusion: Customers can develop extensions with their own license, also Codeunits. The only requirement is assign numbers in their purchased range objects (even for tableextensions and pageextensions).
Able doesn´t mean easy. Opinion.
We can expect a crowd of final customers developing Coduenits by themselves……….or may be not.
We can see some difficulties for become this real: C/SIDE was simple and direct, more accessible to people without a strong programming knowledge. VIsual Studio Code is less democratic on that point. It free, but requires programming background.
Also we are all the time in an On-premise scenario and On-premise will not be future mainly scenario.
We’re pleased to announce the March update of the Developer Preview. We have been working hard on improving the capabilities of the toolset as well as fixing incoming issues reported by you. Below you can see the changes that we’re announcing for this update. The preview is already available if you sign up for the Ready to Go program. Read more at http://aka.ms/readytogo.
After April 2nd the build will become public and you can get it through http://aka.ms/bcsandbox.
Please note, that the improvements announced in this blog post are not available in Dynamics NAV 2018 and the following cumulative updates of Dynamics NAV 2018.
Static Code Analysis
Specifying “al.enableCodeAnalysis”: true in your settings will enable static code analysis for AL projects. Three analyzers have been implemented that will support general AL coding guidelines, AppSource, and per-tenant extension analysis. Analyzers can be individually enabled by specifiying them in the al.codeAnalyzers setting.
You can customize how the diagnostics generated by the analyzers are reported by adding a custom ruleset file <myruleset>.ruleset.json to the project and specifying the path to it in the “al.ruleSetPath” setting.
“al.ruleSetPath” : “myruleset.ruleset.json”
Using the snippets truleset and trule will get you started quickly.
For more information, see Using the Code Analysis Tool.
Help for new pages
When creating new Pages, Reports, and XMLPorts in Extensions V2, it is now possible to specify the help link that will be used when the user presses the Help button in the user interface.
You can do this by using the property HelpLink on Pages, for example:
page 50100 MyPageWithHelp
HelpLink = ‘https://www.github.com/Microsoft/AL’;
And by using the property HelpLink on the request page of Reports and XmlPorts:
report 50100 MyReportWithHelp
HelpLink = ‘https://www.github.com/Microsoft/AL’;
For more information, see Adding Help Links.
Creating Role Center Headlines
You can set up a Role Center to display a series of headlines, where headlines appear one at a time for a predefined period of time before moving to the next. The headlines can provide users with up-to-date information and insights into the business and their daily work.
For more information, see Creating Role Center Headlines.
Improved experience for event subscribers
We improved the snippets and IntelliSense around event subscribers, for both the attribute arguments and the method parameters. This is now working for trigger events, integration and business events. In case of business and integration events, the suggestion of the method parameters is made based on the attributes of the event publisher in order to know if the global variables and/or the sender should also be suggested.
Here is what it looks like to subscribe to an integration event when using the snippets:
Here is what it looks when writing the event subscriber from scratch:
Working with data?
You can now inspect the contents of a table when you publish an AL project (F5 and Crtl+F5) from Visual Code. Simply modify the launch.json file of the project to include the “startupObjectType=”table” and “startupObjectId”=” settings, replacing with the ID of the table that you want to see. The table will display in client as read-only.
From the client, you can also view a specific table by appending the URL with “&table=”, such as:
For more information, see Viewing Table Data.
Choose your cue layout on Role Centers
We now offer a wide layout option for cues. The wide layout is designed to display large values and gives you a way emphasize a group of cues. When set to the wide layout, a cue group will be placed in its own area, spanning the entire width of the workspace.
For more information, see Cues and Action Tiles.
As usual we encourage you to let us know how you like working with these additions and keep submitting suggestions and bugs. You can see all the filed bugs on our GitHub issues list (https://github.com/Microsoft/AL/issues).
For a list of our previous blog posts, see the links at the end of this post.
Converting from C/AL to AL can be a bit of a hassle:
- First you need to open den Development Environment
- Then filter the objects that needs converting
- Export the objects to a txt file in a folder
- Then Run the Txt2AL.exe
- Lastly import them in the workspace
The Script can be downloaded here:
With the general availability of Microsoft Dynamics NAV 2018 in the first week of December 2017, the new and Modern development environment experience becomes more and more used by developers; side by side with the C/SIDE development environment.
Working with a standard CRONUS database is pretty easy, while every developer would like to give it a spin with their own customized database. In this scenario, it is paramount to have the appropriate symbols generated in order to be successfully pulled out by AL Extension command in Visual Studio Code and develop a custom extension against a proper customized source database.
Installing CSIDE Development Environment side by side with Modern Development Environment is duly described in the docs, as well as how to generate / re-generate symbols. For more information, see https://docs.microsoft.com/en-us/dynamics-nav/developer/devenv-running-cside-and-al-side-by-side.
Here are a few tips that can be helpful when generating symbols.
As interacting with WebServices, especially JSON/REST based WebServices, becomes more and more important, it was very good to see that the new NAV dev environment made it quite easy to do exactly that a couple of releases ago. After reading AJ Kauffmann’s excellent blog post on that topic, I had the idea to auto-generate that code based on a JSON file, so that you no longer need to write a single line of code to get a working base structure. With release 2.3.0 of my VS Code extension this is now possible!