Like many companies nowadays we have bunch of customers with different Business Central versions that we need to support.

On top of this many of us tries to “create  money while we sleep” by creating stand alone apps that we could reuse/resell to new customers and perhaps eventually put them on AppSource in the next step.

This means that we need to support/maintain our standalone apps in multiple versions.

The first idea that comes to mind is to create different version branches for our standalone apps and then we cherry pick each update to each version branch.

Is this a good solution? NO WAY!

As it is our team just learned half a year ago on how to do proper pull requests and still struggle with setting the correct devops status when pull request completes.

Should the same team be responsible to remember, “Oh it is this app I’m working on, then I should cherry pick this change to all the other branches”. I’m sorry to say but that’s not gonna happen. That would be asking for trouble.

The ideal thing would be if we only needed to handle/maintain ONE version branch that works for many versions.

This is actually possible with preprocessor directives in AL .

By using this we get a selective statement of how we would like the compiler to run. This means that we can actually pick which code we want the compiler to compile by using a statement.

When we pick which version we would like to compile for we specify our statement as a preprocessorSymbol in the app.json. Here I have specified to use CLEAN22, that should be used with my BC 22 version.

After that we move on to the selective statement. In our code example we have done a simple page action that shows a message but different message depending on which preprocessorSymbols you have specified.

When we run this after compile we get the following message.

If we change the preprocessorsymbol to CLEAN18 it would instead give us the following:

This is also possible to do this at a larger extent. You could wrap in entire files with this. Example, a table is being deprecated and moved. The deprecated table can be wrapped into a #if CLEAN17, CLEAN18, CLEAN19, CLEAN20… and then you create a new file that should only work for new versions. I’m not saying you should, but that you could.

The latest use we had for this is the that the table “Item Cross Reference” is deprecated in BC22 and replaced by “Item Reference”