ForceSync deployment fails on sandboxes after update to BC24: This Extension cannot be published as it has the same App ID and Version as a previously published Extension.

[PeterConijn]

Describe the bug This might be Microsoft, but I am putting this here in case others have the same problem. Since Microsoft has (finally) managed to upgrade our Accept sandbox to BC24 last night, the deployment suddenly fails with the following errors:

Status Code 422 : Unprocessable Entity Er is geen gepubliceerde extensie die overeenkomt met de opgegeven parameterwaarden. // (translation: There is no published extension that matches the provided parameter values) Status Code 422 : Unprocessable Entity This Extension cannot be published as it has the same App ID and Version as a previously published Extension. Status Code 422 : Unprocessable Entity This Extension cannot be published as it has the same App ID and Version as a previously published Extension.

The exact same pipeline has been working fine on the 23.5 sandbox until it updated yesterday. NA Sandbox (still on 23.5) is also fine. The pipeline is set to ForceSync (since I cannot find a way to skip deployments of already installed versions) and Replace Package ID, which has been sufficient of managing this up till now.

VSCode shows identical behavior I have also been able to replicate this behavior in VSCode. Using the Dysel System App with the same version number and schemaUpdateMode: ForceSync, publishing to the BC24 environment fails, while publishing to the BC23.5 environment succeeds.

It almost looks like Microsoft broke ForceSync.

the used yaml please provide the yaml that you used. It helps you put the yaml like this:

#Your build pipeline references an undefined variable named ‘azure_tenant_id’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972

#Your build pipeline references an undefined variable named ‘Deployment-TenantId’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972

#Your build pipeline references an undefined variable named ‘Deployment-ClientID’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972

#Your build pipeline references an undefined variable named ‘Deployment-ClientSecret’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972

#Your build pipeline references an undefined variable named ‘Deployment-UserId’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972

#Your build pipeline references an undefined variable named ‘Deployment-UserPassword’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972

steps:

- task: Hodor.hodor-alops.ALOpsExtensionAPI.ALOpsExtensionAPI@1

  displayName: 'Deploy to NL'

  inputs:

    interaction: batch

    api_endpoint: 'https://api.businesscentral.dynamics.com/v2.0/$(azure_tenant_id)/DyselNL-Acceptance/api'

    dev_endpoint: 'https://api.businesscentral.dynamics.com/v2.0/DyselNL-Acceptance/dev'

    dev_schemeupdatemode: forcesync

    azure_tenant_id: '$(Deployment-TenantId)'

    azure_app_client_id: '$(Deployment-ClientID)'

    azure_app_client_secret: '$(Deployment-ClientSecret)'

    username: '$(Deployment-UserId)'

    password: '$(Deployment-UserPassword)'

    replacepackageid: true

  retryCountOnTaskFailure: 2

the output Also the complete output is necessary for us to see what is going on. Also use backtics: Log file tasklog_13_NL.log

Expected behavior I would have expected the behavior to remain consistent.

Screenshots

Additional context

• Problem occurs in BC24 sandboxes
• Have tried with API version 1.0 and 2.0 with similar results
• Tried turning replacing package ID off which did not change the outcome
• After the pipeline error, the Dysel System App package is published, but not installed. Installing manually from Extension Management works without issue
• Publishing the same app (with the same version no.) from VSCode gives the same error for NL Accept (BC24), but not for NA Accept (23.5)
• I have restarted the BC24 NL Accept environment (so I have tried turning it off and back on again): no effect

[MortenRa]

This is a bug at Microsoft and they are working on a solution

[waldo1001]

Thanks the info, @MortenRa !

[PeterConijn]

Thanks, @MortenRa! I was just going to comment that even an increase of version no. does not allow me to publish.

Is there a Viva Yammer Engage thread for this, that you know of?

[MortenRa]

Yes Yammer https://www.yammer.com/dynamicsnavdev/#/threads/show?threadId=2760254900903936

and Github issue: https://github.com/microsoft/AL/issues/7721

[MortenRa]

MS also put this info into VS code under AL Home

[PeterConijn]

I have tried to keep publishing, but it fails with 100% consistency. There is a sort of/kind of work around for sandboxes (and Production PTEs).

1. Publish your app via VS Code: this will result in the error
2. Go to Extension Management on your sandbox: you will find your app in a published, but non-installed state
3. Install the app via the install option in Extension Management
4. Repeat for each app as needed.

Latest on the grapevine is that Microsoft are pushing a hotfix, but it might take up to two weeks before all tenants have been updated.

[waldo1001]

We're waiting for Microsoft to solve this on infrastructure level on their side.

[PeterConijn]

Microsoft have resumed updates and the issues seems(!) to have been resolved.

[waldo1001]

We'll close this issue. If it comes back, you can reopen it again!