When checking if an Extension is already installed ALOps uses PackageId, not AppId

[DavidCurd]

When using ALOpsExtensionAPI@1, ALOps checks if the extension is already installed by comparing the PackageId and Version properties. However, BC compares the AppId and Version. This means if an app has been recompiled with the same version number and is already in BC, Alops will try to install it but error.

                - task: Hodor.hodor-alops.ALOpsExtensionAPI.ALOpsExtensionAPI@1
                  displayName: 'Publish Extensions'
                  inputs:
                    interaction: batch
                    api_endpoint: $(custenvironmentname)/api
                    authentication: Basic
                    username: '$(onprem-api-username)'
                    password: '$(onprem-api-password)'
                    artifact_path: '$(Pipeline.Workspace)'
                    artifact_filter: '*.app'
                    maxtries: 40

The below example is publishing to an on prem envirenment, but we have the same issue with SaaS:

Error in Alops:

*** Selected Company: CRONUS UK Ltd. [4128f995-4793-ef11-8a6d-6045bde98dce]
Invoke-RestMethod -Method Get -Uri 'https://########:7048/bcwebservicestest/api/microsoft/automation/v1.0/companies(4128f995-4793-ef11-8a6d-6045bde98dce)/extensions'
*** Installed Extensions:

...

@odata.etag     : W/"JzE5OzgzNjIwMDA0MjI4OTA2MjQzODIxOzAwOyc="
packageId       : 54f1fa95-2c9d-4a27-95fc-93bf7ffcd88d
id              : 94c83401-7a52-4b1c-905a-af2666fba998
displayName     : Production BOM and Routing No. on Item Variant
publisher       : Dynamics Consultants Ltd.
versionMajor    : 19
versionMinor    : 1
versionBuild    : 3
versionRevision : 0
isInstalled     : True
publishedAs     :  PTE

...

*** Publish App [C:\agents\_work\710\AL.ProdBOMRoutingOnItemVariant\DC Manufacturing\Dynamics Consultants Ltd._Production BOM and Routing No. on Item Variant_19.1.3.0_sandbox_27.1_gb.app]
*** Upload extension [C:\agents\_work\710\AL.ProdBOMRoutingOnItemVariant\DC Manufacturing\Dynamics Consultants Ltd._Production BOM and Routing No. on Item Variant_19.1.3.0_sandbox_27.1_gb.app]
*** Get App Info
 * App.PackageID = 1cfdccae-38ec-4b17-81b3-b4af11265285
 * App.ID        = 94c83401-7a52-4b1c-905a-af2666fba998
 * App.Name      = Production BOM and Routing No. on Item Variant
 * App.Publisher = Dynamics Consultants Ltd.
 * App.Version   = 19.1.3.0
*** Get Extension status
Invoke-RestMethod -Method Get -Uri 'https://######:7048/bcwebservicestest/api/microsoft/automation/v1.0/companies(4128f995-4793-ef11-8a6d-6045bde98dce)/extensions'
*** Update Extension
Invoke-RestMethod -Method Patch -Uri 'https://######:7048/bcwebservicestest/api/microsoft/automation/v1.0/companies(4128f995-4793-ef11-8a6d-6045bde98dce)/extensionUpload(0)/content'

*** Poll Deployment status
Invoke-RestMethod -Method Get -Uri 'https://######:7048/bcwebservicestest/api/microsoft/automation/v1.0/companies(4128f995-4793-ef11-8a6d-6045bde98dce)/extensionDeploymentStatus'
*** Deployment Status:


operationID : 31cb7657-f992-4140-86f1-d272e4953171
name        : Production BOM and Routing No. on Item Variant
publisher   : Dynamics Consultants Ltd.
appVersion  : 19.1.3.0
status      : Failed
startedOn   : 2025-11-20T15:58:27.84Z



##[error]App publish failed. Check the 'Extension Deployment Status' page in the Business Central client.
##[error]App publish failed, aborting batch

Error in event viewer

Server instance: BCWebServicesTest
Category: Extensions
ClientSessionId: 00000000-0000-0000-0000-000000000000
ClientActivityId: 00000000-0000-0000-0000-000000000000
ServerSessionUniqueId: 83064404-d4e1-4efd-99b5-1da556a03b8e
ServerActivityId: 81293025-2290-43ed-ac8a-ecaf64811f4a
EventTime: 11/20/2025 15:58:27
Message App 'Production BOM and Routing No. on Item Variant' (appId: '94c83401-7a52-4b1c-905a-af2666fba998') by 'Dynamics Consultants Ltd.' version '19.1.3.0' appears as already published. ErrorType: 'InvalidOperation'; ErrorMessage: 'This Extension cannot be published as it has the same App ID and Version as a previously published Extension.'.
ProcessId: 35208
Tag: 0000GQM
ThreadId: 14
ExecutionId: 2407
CounterInformation: 
CustomParameters: {
}
GatewayCorrelationId: 

Expected behavior
I would have expected ALOps to use the same logic as BC when checking if the extension is already installed. If the package ID needs to be checked this should be switchable with a parameter.

[DavidCurd]

To give a bit more context on why this is a problem, we use an environment branching strategy, eg we have a dev branch, test branch and main branch. Deployments are run from test and main. It looks like the above issue is occurring because a test environment is created from a production one which includes extensions that were built from the main branch, and we are now trying to publish all of this customers extensions from the test branches, some of which have the same version number but were built in a different build pipeline run against the main branches.

[waldo1001]

Hi David, this is by design, i'm afraid.
the only way for you to push a new app is by pushing a new version. You can easily do this by simply add the build-number in the app-version.

If we would just always publish an app no matter what version – that would be a MAJOR performance degradation in many pipelines as not doing this, is there exactly to speed up the pipelines.

[DavidCurd]

Hi Waldo, we had thought about that but the version built in main will have a higher build number than the version built in test. If you then create a sandbox environment from production the pipeline fails to deploy the extensions as there is already a higher build number there.

I agree it shouldn't always deploy extensions, but I think it should check the app id and version number (which seems to be what BC checks), not package id and version number. In our case we expect ALOps not to deploy the extension and the appid as version number match what is there already.

[waldo1001]

Please explain how this would happen? How is your flow?

• where do you do development? Dev sandbox?
• where do you deploy? Test first, then Prod?

Where does this situation happen?

Meantime - we'll look into it.

[DavidCurd]

Thanks, we've updated our versioning strategy to work around it in the mean time, but checking the package ID still doesn't seem right to me. The build number of our extensions is now 3xx when built from the dev branch, 2xx when built from test and 1xx when built from main. I'm not a big fan of this but it means an extension built from test can be deployed over an extension built from main when a new sandbox is created.

Yes, we do dev in a sandbox environment. This is in the customer's SaaS environment. For on prem customers we have VMs hosting SQL and a middle tier service per customer.

We don't currently deploy to dev from a release pipeline, that is done from VSCode in the dev context or manually via the client. We might do this later if we run into issues with extension deployed from VSCode being removed after updates. Extensions are then deployed via a release pipeline to the customers test environment, then via a second release pipeline to the customer's production environment.

This problem happens when a new test sandbox has been created from a production environment. I think it's only an issue if your versioning strategy doesn't include a build number, which ours now does. From our point of view this issue could be closed, but it might be relevant to other users. If you don't plan to change this it would not longer be a big issue to us.

[waldo1001]

We will do a small change, which will make you able to re-compile an app, with same version - which will now NOT install the app.

The message will be "Extension has a newer or same version already installed. Skipping publish."