We really need namespaces in AL

The curse of a single big namespace is a piece of technical debt from Navision that we need to get rid of. Microsoft is running out of excuses now that all codes is isolated in separate extension and dependencies between are well defined. Check the video for why it moved to the top of my list again:

https://youtu.be/hlA5tDF8CUQ

In this video, Erik demonstrates a frustrating real-world problem that AL developers face in Business Central: object naming collisions between extensions, and makes a compelling case for why namespaces are desperately needed in the AL language.

The Problem: Object Name Collisions

Erik starts by creating a simple, straightforward extension with a codeunit called “Helper Functions”:

codeunit 50139 "Helper Functions"
{
    procedure Helpful()
    begin
        Message('You are wonderful, have a nice day!');
    end;
}

The app manifest is as minimal as it gets — no dependencies, a clean ID range, and nothing that should conflict with anything:

{
  "id": "56158416-cadb-42da-a963-77ad9482cde9",
  "name": "namespaces",
  "publisher": "Default publisher",
  "version": "1.0.0.0",
  "dependencies": [],
  "idRanges": [
    {
      "from": 50100,
      "to": 50149
    }
  ],
  "runtime": "10.0",
  "features": [
    "NoImplicitWith"
  ]
}

When Erik attempts to deploy this perfectly reasonable extension to a cloud sandbox, he’s met with an error:

“The object name ‘Helper Functions’ can only appear once for the type codeunit.”

Who’s the Culprit?

It turns out Microsoft’s Dynamics GP Intelligent Cloud app — which is automatically present on the tenant even though Erik started with a fresh sandbox and has no need for anything GP-related — already contains a codeunit called “Helper Functions.” That’s it. A name as generic as “Helper Functions” has been claimed by a Microsoft app that’s forced onto tenants.

Erik’s object IDs don’t conflict. His app has no dependency on the GP app. The only collision is the name of the object, and the platform treats that as a hard error.

Why “Just Prefix Your Objects” Isn’t the Answer

The common workaround in the AL community is to prefix or postfix all object names with your company abbreviation or app identifier. Erik acknowledges this pattern — he even shows other objects in his projects that follow this convention. But he pushes back on the idea that this should be the developer’s responsibility:

  • Microsoft themselves used the completely generic name “Helper Functions” — if even Microsoft doesn’t prefix consistently, how can they expect everyone else to?
  • The name “Helper Functions” is incredibly common. Erik has created codeunits with that exact name multiple times in his career, and he’s confident most AL developers have too.
  • Microsoft’s apps are forced onto tenants, meaning they can silently break existing, well-functioning extensions simply by introducing a new object with a common name — and this can happen before AppSource apps get revalidated.

The Case for Namespaces

Erik argues that the platform already has the information it needs to solve this problem. Every app has a unique App ID, a publisher, and a dependency graph. There’s already a degree of scoping inherent in the extension model. In theory, Microsoft could scope object names to their parent extension — effectively prefixing the App ID internally — and the collision problem would disappear.

What Erik is really advocating for is proper namespace support in AL, similar to what exists in virtually every other modern programming language. Namespaces would allow:

  • Multiple extensions to define objects with the same name without conflict
  • Clear, unambiguous references when consuming objects from other extensions
  • An end to the clunky naming conventions (prefixes, postfixes, affixes) that pollute object names
  • Better alignment with how modern development ecosystems handle code organization

(Editor’s note: Since this video was recorded, Microsoft has indeed introduced namespace support in AL with Business Central 2023 Wave 2 / runtime 12.0, using the namespace and using keywords — a welcome and long-overdue addition to the language.)

Summary

This video highlights a real and painful limitation of the AL platform: the global uniqueness requirement for object names across all extensions on a tenant. When Microsoft’s own forced apps use generic names like “Helper Functions,” it creates unavoidable collisions for developers who have no control over what’s installed on a tenant. The solution isn’t better naming discipline from developers — it’s proper namespace support at the language level, bringing AL in line with modern programming standards.

Picture of hougaard

hougaard