Issues when re-downloading .alpackages symbols for different Application/System version?

[SteveKrisjanovsD365]

I have a tenant customization that I initially developed by connecting my .al project to a local docker instance (the tenant SaaS environment wasn't set up yet at the time so this was the best way to expedite development efforts).

At the time, the symbols it downloaded from the docker sandbox were as follows:

• Microsoft_Application_13.0.24630.24844.app
• Microsoft_System_13.0.12929.app

I tested this extension .app against both the docker sandbox as well as the tenant's sandbox with success.

Now that my customer's SaaS environment is set up (which is on a different version of business central), I deleted the contents in .alpackages and I re-downloaded the symbols but this time, from the tenant's SaaS sandbox. Not the docker one.

The files it downloaded are as follows:

• Microsoft_Application_13.0.24630.0.app
• Microsoft_System_13.0.12929.0.app

VS Code compiles the extension .app just fine, but I get the following error when I deploy this extension to both docker and SaaS (I tried both schemaupdatemode = recreate as well as synchronize. No dice):

The request for path /v1.0/sandbox/dev/apps?SchemaUpdateMode=recreate failed with code 422. Reason: The extension was unable to be deployed due to a dependency between extensions.

AL Language Extension is 2.0.48254.

Why won't the .app deploy? I didn't find any lingering dependencies in the .app file VS Code compiles. I'd hate to have to completely uninstall the extension to get past this hurdle (and it should be reasonable to expect to test the extension against newer versions of BC).

Below is my app.json

{
  "id": "ecd17510-9820-431f-86a9-b1830ef9201e",
  "name": "foo",
  "publisher": "bar",
  "brief": "",
  "description": "",
  "version": "1.0.0.0",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "",
  "capabilities": [],
  "dependencies": [],
  "screenshots": [],
  "platform": "13.0.0.0",
  "application": "13.0.0.0",
  "idRange": {
    "from": 50000,
    "to": 99999
  },
  "runtime": "2.0",
  "showMyCode": true
}

[SteveKrisjanovsD365]

even weirder now....

As a last resort I uninstalled the extension from the tennant's SaaaS sandbox and VS Code refuses to deploy the app.

The request for path /v1.0/sandbox/dev/apps?SchemaUpdateMode=recreate failed with code 422. Reason: This Extension cannot be published as it has the same Publisher, Name, and Version as a previously published Extension. There is no app published (I double checked on the tenant's SaaS sandbox), but the app refuses to deploy.

very frustrating

[StanislawStempin]

The error message means that you have another extension that took dependency on your app. This usually happens when a designer extension is created which in current release takes dependency on all other extensions on the system. This problem will be fixed from the next minor update.

In the meanwhile you would need to check that all apps that depend on your app are uninstalled before you will be able to republish your app.

The second error message indicates that you still have the app published on the system. It might be a corrupted state so it's worth trying to change the app ID and/or name.

Have you installed/uninstalled/unpublished any other extensions on that tenant?

[SteveKrisjanovsD365]

@StanislawStempin there are no other apps that depend on this app. It's a standalone extension. What do you mean by designer extension though? I did notice that when the debugger attaches to the web client, it brings up the default page in designer mode which I found really odd. Is that what F6 ultimately does. The default page specified in launch.json is page 22 (it, nor its dependencies have been extended).

FYI I've gotten into the habit of deploying from VS code via F6 (not F5) since if there is an error, F6 will give me relevant error outputs in the output window. F5 usually gives me nothing is something goes wrong.

At any rate I successfully deployed the extension to both docker and SaaS with the SaaS .alpackages app and system files but the only way for me to do it was to up the version number in the app.json file.

this begs several questions:

• why did I need to completely uninstall the extension before it would allow me to re-deploy with different BC app and system symbols?

• why did BC SaaS complain that a conflicting version/name/publisher was previously installed when there clearly was none published in the extension manager?

• why did I have to resort to upping the version in app.json?

If I understand this all correctly, should debugging via F6 be avoided?

[StanislawStempin]

Ok, if you truly didn't have any dependent extensions than it might be an issue with the fact that the previous symbol version numbers were stamped inside the app installed on the tenant. We will investigate further.

[SteveKrisjanovsD365]

thank you please do. it's imperative that extension developers can easily test against varying system and app .alpackages deps.

[SteveKrisjanovsD365]

@StanislawStempin I got confirmation from my boss that he was indeed creating other designer extensions at the time this was all happening.

You mentioned this will be fixed in a minor update. How will that minor update address this?

As it stands now I can't condone non-developers on my team to use the sandbox designer as it really interferes with developers such as myself who work in VS code.

or... if they must, have them complete their designs before my VS code extension is deployed to the sandbox. That way the design extensions doesn't force any depencencies.

[qutreson]

Hi @CanuckNav74, the fix should be part of CU2. The issue #1704 tracks the designer dependencies issue.

[SteveKrisjanovsD365]

Thanks for the update @qutreson

What version# will CU2 correspond to for SaaS? (FYI my customer's tenant BC is currently on CA Dynamics NAV 13.1 (26435))

[qutreson]

Sorry for answering so late. According to our online content, CU2 should have been version 13.0.26556/26413.

[MichelDant21]

In my case I corrected the platform and application number 17.0.0.0