Al: Cannot upload the same Tenant Customization to more than 1 production Tenant

Created on 18 Dec 2018  Â·  16Comments  Â·  Source: microsoft/AL

Hi team,

Look, I have created Tenant customization, with

  • app id = guid1
  • app name = app name 1
  • publisher = publisher 1
  • version = 1.0.0.0

Then i uploaded that to the Online Business Central Production Tenant A => Everything works fine.
Then i uploaded the same tenant customization (with the same id, publisher name, app name and a version) to the Online Business Central Production Tenant B => And I've got an error that the same version of this app is already exists!

So why is that? Is it a bug? Or this is by design?
Thanks.

P.S. Sorry if i created that in a wrong thread.

enhancement extension-management

All 16 comments

Hi,
I have experienced the same thing! Changing the version number solves it, but that's not what I like to do since it's not a new version....

@dkatson how are you uploading the extension to the BC production tenant?

Hi, Extension Management => Upload Extension

Dmitry

On 19 Dec 2018, at 10:34, Alexandru Toader notifications@github.com wrote:

@dkatson how are you uploading the extension to the BC production tenant?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

We are experiencing the same issue when deploying tenant customizations on production tenants. Is there any way to avoid or mitigate this issue?

This behavior has been explained on the BC Yammer group (https://www.yammer.com/dynamicsnavdev/threads/1168396130) and it's due to the 3 keys that must be unique for each extension and upload (and they must be unique over all tenants in a regional service):

a. Package ID (this is unique for every compilation of the extension)
b. App ID and Version
c. Name, Publisher, and Version

Does this means that for two customers located in the same region (as West Europe) who want the same extension, we have to provide differents PackageId's ?
If I understood correctly, how will it work for an extension available in the market place ? Does this key "evolves" each time the extension is downloaded in a specific region ?

Hi, no Package ID should be the same for 2 PTC if you want to upload it on 2 diff tenants.

Dmitry

On 15 Jan 2019, at 14:19, jdecottignies notifications@github.com wrote:

Does this means that for two customers located in the same region (as West Europe) who want the same extension, we have to provide differents PackageId's ?
If I understood correctly, how will it work for an extension available in the market place ? Does this key "evolve" each time the extension is downloaded in a specific region ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

this is a really terrible management !!! if I have many customers who need the same app, it is necessary to have a different project for each customer. If we have other apps that depend on each other, to which to make updates ... you become crazy !!! Also it is not sure that changing only the app id the publication is successful! Can anyone has found a way to manage apps in a centralized way, and branch out the deployment based on the necessary tenants?

Hi, read here
https://community.dynamics.com/nav/b/katsonsnavblog/archive/2019/01/23/top-tips-and-tricks-on-how-to-create-per-tenant-extensions

Dmitry Katson,
MVP

My Blog
My Twitter
My LinkedIn

On 12 Feb 2019, at 14:11, giann85 notifications@github.com wrote:

this is a really terrible management !!! if I have many customers who need the same app, it is necessary to have a different project for each customer. If we have other apps that depend on each other, to which to make updates ... you become crazy !!! Also it is not sure that changing only the app id the publication is successful! Can anyone has found a way to manage apps in a centralized way, and branch out the deployment based on the necessary tenants?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

We are aware of the issue but we don't have a good solution for it yet.
You are able to publish the extension for another tenant if you change the version number and I know it is just a workaround and not a solution to the problem.

This is a big issue for us and will be an issue for a lot of other developers. We really want to be able to write tools that we can deploy to multiple tenants, even if they aren't functionality the client themselves will use.

We have data import tools we use for implementation that we've converted to BC that help us mass apply templates. We've also created customisations that we've found multiple customers are interested in, but we aren't an ISV so we aren't putting these on the app store.

Being able to only publish these tools to a single tenant without having to bump the version numbers is frustrating to say the least!

Hi @charlespockert ,

We resolved these problems through changes in internal process. See here for details, it may help: https://funwithcside.wordpress.com/2019/05/03/versioning-per-tenant-extensions-using-github-releases/

Cheers
Jurica

@JuricaB so what the error is actually saying is that some differences between one package and another exist, and in fact you can deploy the same customisation across multiple tenants as long as you use the same build files from tenant to tenant.

I have no issue with this as we can just generate build artifacts or check in packaged versions (it's a shame that Azure DevOps doesn't have the same "releases" functionality as GitHub).

Going to give this a shot.

@JuricaB are you aware if the limitation on deployment extends to sandbox? e.g. if we deploy to sandbox, does this prevent us publishing a recompile of the same extension to a production tenant?

@JuricaB are you aware if the limitation on deployment extends to sandbox? e.g. if we deploy to sandbox, does this prevent us publishing a recompile of the same extension to a production tenant?

I have not run into any such issues - so far! Maybe I have just been lucky?

Vote here to make this possible

Was this page helpful?
0 / 5 - 0 ratings