In Dynamics 365 Business Central, the introduction of namespaces in AL (Application Language) marks a significant advancement, providing developers with a structured approach to code management. Namespaces are a critical concept in programming, allowing developers to organize code and avoid naming conflicts.

They can be used to help avoid naming conflicts between different extensions, making it easier to maintain and understand extensions, including the relationship between different objects.

💡 For now there won’t be registration of Namespaces, as we have for prefixes. But guideline should be followed!

Guideline about declaring name space would be, that the first part of a namespace is tied to the developing organization or an individual, followed by a product name, and logical grouping within the product, such as, for example, namespace SSOSIC.Extension1.Learn

This supports the two purposes of namespaces – object name unique and logical grouping of related functionality.

An AL file declares a namespace at the beginning of the file, and all objects in the code file belong to that namespace.

A given object can only belong to one namespace, but the same namespace can be used for multiple AL files, which means for multiple objects and for multiple modules. There are two compiler rules that apply to namespaces and object naming specifically:

  • You can only have one object of a kind with the same name in a module
  • You can only have one object of a kind with the same name in a namespace

💡 Renaming existing object or member names is a breaking change, therefore namespaces can only help with logical structure for existing objects.

Any app, which is dependent on your app will be broken if you rename namespaces, and likewise your app will break if any of your dependencies rename their namespaces.

To declare a namespace in AL, you must use the namespace keyword followed by the name of the namespace.

To declare more objects in the same namespace, you can use the same namespace declaration in other .al files. All code files that use the same namespace declaration belong to the same namespace.

But, to refer to objects in other namespaces, you can either use the fully qualified name, or the using directive. The using directive is used to refer to objects in other namespaces without having to use the fully qualified name. The using directive is placed at the top of the .al file, after the namespace declaration and before any object declarations.

If you decide to use namespaces in AL, than you must be also using using directive, otherwise you will get errors:

Code actions are available to help developers add namespaces to existing sources. If you position yourself to line 8 on Customer table declaration, and press Ctrl + ., than you will get possible fixes:

You can use different fixes, either Fully qualify:

Or using namespace for Customer:

For both type of fixes, you can do bulk fix:

It could do changes in whole document, project or workspace.

Meaning, once you define your custom namespace, you will get quite some errors. But with bulk fix, you could adjust your whole project and most likely get back to 0 errors.

Keep in mind that back to compiling solution must not mean that you are good to go, when objects are resolved, they’re resolved using the closest scope first. Therefore, to resolve to a similar named object in a dependent extension, the reference must use a fully qualified name.

If you would like to declare namespace for multiple objects easy, you can read more about it on yzhums blog post regards it: Blog Post Link

Two more nice features with name spaces:

  • Grouping objects by namespace makes it easier to focus on and find related objects.
  • Using namespace allows us to get away from prefix or suffix.

On first sights it looks complicated and unnecessary, but once you start using namespaces you will discover true benefit and see that there is nothing complex about it, so give it a try. 🚀

Categorized in: