Dynamics 365 Business Central and per-tenant extensions: check page control names between platform upgrades

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.

 

 

 

11 Comments

  1. I’m not able to download symbols even with the AL:GO! (al extension 3.0 installed).
    I only configure the name and server instance of the launch.json

    You know any issue with this?
    Thanks

    Like

    1. Thanks for your quick reply.

      This is my launch

      {
      “version”: “0.2.0”,
      “configurations”: [
      {
      “type”: “al”,
      “request”: “launch”,
      “name”: “MyPersonalizations”,
      “server”: “https://businesscentral.dynamics.com/xxxxxxxx-9285-d5f6e42d4330/Sandbox2”,
      “startupObjectId”: 22,
      “startupObjectType”: “Page”,
      “breakOnError”: true,
      “launchBrowser”: true
      }
      ]
      }

      The sandbox2 info:
      Application version: 14.0.29537.29654
      Platform version: 14.1

      Like

      1. This launch.json is wrong. If you’re working with an online sandbox, when creating your project with AL:Go! you’ve to select the “Cloud Sandbox” option.
        Then, as default VS Code will connect to the default online sandbox for your user. You can specify tenant = “YourTenantID” if you want to connect to a specific online tenant. If you want to connect to another sandbox different than the default one, you can specify sandboxName = “YourSandboxName” in launch.json.
        Here, server parameter must not be specified.

        Like

  2. Yeah! I dind’t known that now connects directly throw my user.

    I have another problem when I try to pusblish the extension in my Sandbox. The compilation ends, but then I have an error. Maybe I have some incorrect configuration….
    https://community.dynamics.com/business/f/758/t/318698

    Another thing, related to this post. We need to make a codeunit to update the ext per tenant? Or we only have to fix any error caused by new version and the upload with the next major release option?

    Thank you so much, there is no much info.

    Like

  3. Hi Stefano, Thank you for your post. I guess this small taste of many issues with breaking apps we can expect to get when Microsoft’s refactoring to sub modules really takes of. In your case, then work-around may be to fix it to a field, which exists in both, and move it when upgraded. Definitely not ideal, but that may work.

    Like

  4. Great post Stefano.
    Thanks for sharing with us.

    I have a small query. I got same message regarding upgrade for one of our per-tenant extension, so it can be compatible with upcoming major release.
    But there is something confusing me.
    I have an extension A that I need to upgrade, but there are other 6-7 extensions , which are dependent on extension A. Now I am confused, if I upgrade my extension A, would it uninstall all other dependent extensions.

    Also when I am going to download symbols for this Main Extension A, its saying that it have dependency.

    Kindly suggest.

    Like

    1. You can upgrade A (change at least the version number), all other extensions will not be uninstalled.
      Regarding last question, I’ve not understood…

      Like

      1. Thanks for your prompt revert.
        My last question was.
        Some fields from Extension A being used in Extension B. So I defined dependency of Extension A in Extension B, so that Extension B can download symbols for this dependency.
        Now, when I am upgrading Extension A, its saying that it have dependency in Extension B. because some fields from this extension A is being used in B.
        But I think , when I upgrading main Extension A, it should not ask to download dependency from inherited Apps.

        What you think?

        Like

      2. Yes, this is one of the top noisy problem actually with dependency. We currently need to unpublish and uninstall all dependent extensions, before we can publish the main app again.

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.