Managing DotNET Dependencies on AppSource for Business Central

When you try to convert existing C/Side objects to AL the first attempts are typically done while scoping OnPrem. This gives an overview of the errors to be fixed w.o things like DotNET.

In this phase you typically switch between C/Side and Visual Studio Code all the time fixing the errors one-by-one and reconverting.

Once the errors are fixed the software can be tested and deployed using either Docker or a local install.

This is a very safe way of ensuring there is a migration path for your existing customers what is not overly complex and thus affordable from a TCO perspective.

The next step is moving to AppSource and this is where you need to remove all the DotNET dependencies.

The biggest issue with DotNET is that it’s often used in interfaces and most partners that I’ve worked with put every interface they ever did in their C/Side toolbox just in case you ever need it again.

Chances are you may never need many or most of them, but how do you determine that? And where to start?

Decouple!

If you can somehow decouple your business logic from your DotNET dependencies you create a Core solution, and each interface can be a dependent extension.

These depedent extensions will most often be per-tenant extensions. You don’t want to go through the whole AppSource validation for interfaces you only need almost never.

Example

Let’s look at a simple real life example I did today. It’s an interface that reads the ferry sailing times from TT-Line and offers the option to book one.

Off course decoupling is smart here in the first place since you may also want to interface with other ferry companies but that’s not what we’re looking at now. In the example I have the C/AL code and the DotNET code is on one codeunit and it needs to be decoupled.

The Function GetTimeTable is called from the application somewhere. If I remove this codeunit from my extension I get errors.

Step 1 – Copy the codeunit using File-Save As and call it <<Name>> Impl.

This separates the link between your application and the code making the orriginal codeunit a Facade and the new codeunit the Implementation.

Microsoft also does this in the new System Application

Step 2 – Remove All Code from the Facade and change the functions in Event Publishers

This is different from what Microsoft does in System Application. In our case we don’t want a strong contract between the Facade and the Implementation.

Step 3 – Change the functions in the Implementation to event subscribers

Just enter the property window and add the correct properties. Trust me, it works.

Step 4 – Mark the decoupled codeunit in the Version List

When 100% conversion between C/Side and AL is the goal (and it should be the goal) you can use the Version List to mark your objects as part of Core, or as part of a dependent Extension.

Step 5 – Determine what’s next

Now you can ship to AppSource but you’ll have a function that does nothing. You need to rewrite this code to make it work.

Most often there are two scenario’s.

A:> Make use of the new HTTP type variables in AL

B:> Create an Azure Function

Both are valid options and the correct choice depends more on questions like flexibility and language of preference.

NEVER, EVER put interfaces in your Base AppSource solution unless you trust the contract of the API with your life!

Interfaces change all the time. Put them in a Per-Tenant extension or in an Azure Function because these can very easily be changed, debugged, etc.