I’ve talked a lot in the past about pros and cons of per-tenant extensions (PTE) in Dynamics 365 Business Central. Despite Microsoft’s guidance (use AppSource) this is actually the most common way for partners to deploy their extensions on a SaaS environment and this is the recommended way for developing specific customizations for a customer tenant.

Unfortunately, the partner’s live with the per-tenant extensions is not so easy nowadays  because (in my personal opinion) Microsoft has an internal process for managing PTEs that must be absolutely rethinked. I’ve talked in the past about the main noisy problem with PTEs, but there are other aspects that can cause problems on your tenants.

The problem I want to talk here today is a very noisy problem that I’ve personally experienced this morning on a customer’s SaaS tenant.

I have an extension that adds some fields on the Item List page. As a best practice, if possible I always suggest to add your new fields to a standard list page as last fields of the repeater control on that page.

Our customer has actually an online tenant with platform 13.5 and the new field was added in the following pageextension object:

pageextension 50301 ItemListExt_EID extends "Item List"
{
   layout
   {
      addlast(Item)
      {
         field("Item with Barcodes"; "Item with Barcodes")
         {
            ApplicationArea = All;
            Editable = false;
            Style = Attention;
            StyleExpr = attentionStyle;
         }
      }
   }
}

 

Today I’ve received an email from Microsoft (remember to always add your address in the tenant’s Admin Center email recipients) that says this:

The XXX extension that is installed in the Dynamics 365 Business Central tenant for YYY is not compatible with version 14.0.29537.31665. The compatibility issue must be resolved before the tenant for which the extension is installed can be successfully updated to version 14.0.29537.31665.

Error AL0270: The control ‘Item’ is not found in the target

Why this problem occours? Because I’ve added the Item with Barcodes field (my custom field) as LAST control of the standard repeater control on the Item List page and this repeater control on platform 13.5 was called Item:

D365BCControlRenameProblem_01

On platform 14, Microsoft has renamed the repeater control and this is now called Control1:

D365BCControlRenameProblem_02.jpg

Despite the step backward (calling a control like ControlXXX on a page is totally without sense in AL!), what do you have to do now?

You have to download the symbols for the new build and fix your app. For doing this, you have essentially two ways:

  1. Create a local docker container with the latest official build
  2. Directly from the online tenant you can create a secondary sandbox with the future version and fix your app by downloading symbols from that sandbox

The fix was simple, just change the repeater control name:

pageextension 50301 ItemListExt_EID extends "Item List"
{
   layout
   {
      addlast(Control1)
      {
         field("Item with Barcodes"; "Item with Barcodes")
         {
            ApplicationArea = All;
            Editable = false;
            Style = Attention;
            StyleExpr = attentionStyle;
         }
      }
   }
}

The problem appears if you want to directly upload this extension in the default sandbox  environment for releasing the app to your users for testing. Here, platform is again 13.5 and you don’t have Control1 in the Item List page.

If you want to do a fix that permits an immediate publising of this extension for the CURRENT release and that will be compatible for the future release, in this case you need to avoid using ADDLAST(RepeaterName) and add the field AFTER a standard field (ADDAFTER(FieldName)).

Instead, if you want to use ADDLAST(RepeaterName) and upload the fixed extension to the production environment and be ready for the future upgrade, remember that:

  • You need to compile the extension for the new build (new symbols)
  • Upload the extension for the NEXT MINOR version (not for the Current version as normally you’re doing for every extension):

D365BCControlRenameProblem_03.jpg

When you deploy an .app file for the next version, the extension will be queued up and it will be deployed as part of the customer’s tenant upgrade to the next version (so not immediately).

These are noisy aspect, I agree… but actually the platform could have also control names changements between minor releases and you should be aware of that and handle them accordingly.