Namespaces in AL was one of the top requested features from a lot of time and now we can publicly say that they will be live soon because at last BC TechDays in Belgium Microsoft has officially unveiled the feature to everyone.
Starting from Dynamics 365 Business Central 2023 wave 2 release (v23, these are at least the announced plans) when you write an AL object, it will be decored with a namespace attribute (just like in languages like C#).
The namespace keyword is used to declare a scope that contains a set of related objects. You can use a namespace to organize code elements and to create globally unique types. Declaring your own namespaces can help you control the scope of class and method names in larger programming projects.
Namespaces have the following properties:
- They organize large code projects.
- They’re delimited by using the
.operator. - The
usingdirective obviates the requirement to specify the name of the namespace for every class.
In AL language, if you will reference an external object (like codeunit Math in this example) without specifying a namespace you will have an error saying that the object is missing:
The object is missing because codeunit Math is not in your custom namespace, but it’s in a Microsoft namespace. To use it, you need to specify the right namespace on which the object belongs to with one of the following ways:
- Add using statement in the beginning of your AL file including the external namespace: using System.Utilities;
- Fully qualify the object name: codeunit System.Utilities.Math;
The future AL language extension will provide actions to quick fix the namespaces, like in the below picture:
This will be a great improvement for developers, because this removes the actual usage of affixes for objects. Namespaces will not remove the need to use object IDs in your AL code (at least not in a near future).
Stefano Demiliani 
That is all nice.
Just wonder about initial Microsoft promises made when new extensions were rolled out;
“No more upgrades!”
Anyone remember that one?
LikeLiked by 1 person
That would have been great if it came when AL were new. Now it will cause a lot of issues and require a lot of changes without any actual benefit to thousands of extensions and apps.
Doesn’t the new “using” cause all the same issues as made Microsoft deprecate the “with” statement?
As an ISV we foresee issues maintaining a codebase supported by multiple BC versions. Our main codebase is currently build to all versions from BC14 using scripts to make the necessary adjustments. This is just a waste of time if we will be forced to adjust the source even further. I hope it will be possible to add the “using” statement in the dependency section of app.json so we only need to differentiate a single file and still comply with app source requirements. This of course requires Microsoft (and ISV partners!) to keep using unique object names with their affix.
LikeLike
Unfortunately at the moment adding using in app.json is not planned.
LikeLike
i updated the al language to the preview one and when defining the example as shown above i don’t get an error, that i need to qualify the math codeunit. why is it different for me?
LikeLike
Because the AL extension now adds the namespace for you (using clause at top of the AL object).
LikeLike