Sp-dev-docs: New version of app in the web is auto updating before User GET IT

[kskramki]

Category

• [x] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea
• [x] Example checked item (delete this line)

Expected or Desired Behavior

Once new version of SPFx solution package(has client side web-part using ReactJS) is uploaded in tenant app catalog and deployed(not tenant wide). App already installed in the web should not update automatically to new version, it should update only when user "GET IT" the app.

Observed Behavior

App is automatically getting updated to new version before user GET IT and all the new changes are reflection

Steps to Reproduce

Change the webpart code/ui of already installed app(client web part , React framework used)
Update the version in package-solution.json.
bundle and package the solution and
upload new version in app catalog and replace it and deploy.
Go to the page in which web par added, it will show new changes before user GET IT the version. Go to the App detail page it will show new version

Thanks for your contribution! Sharing is caring.

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[bcameron1231]

Thanks for comment. This is working as designed for SPFx solutions. Unlike Add-ins, the SPFx solutions will be readily available in all locations they have been deployed. With the exception of SPFx solutions that contain feature framework assets that need to be deployed, those assets follow the version upgrade path.

[CPritch]

@bcameron1231

With the exception of SPFx solutions that contain feature framework assets that need to be deployed, those assets follow the version upgrade path.

So would the app immediately update and then fail if there are any dependencies on the updated feature assets? Should we be informing SP Admins when to use 'Get it' for an update to our app? Or should we be setting up templates in our CD to upgrade every app in every site?

[bcameron1231]

Yes. This is possible if your code is tightly coupled to the feature framework that is deployed.

My personal recommendation, is not to rely on the feature framework (even if it's a possibility in SPFx). If you have solutions that have depend on lists/libraries etc... to deploy these solutions and changes to your tenant through a remote provisioning method and using the ALM APIs to deploy your SPFx solutions.

Hope this helps.

[CPritch]

Yes. This is possible if your code is tightly coupled to the feature framework that is deployed.

My personal recommendation, is not to rely on the feature framework (even if it's a possibility in SPFx). If you have solutions that have depend on lists/libraries etc... to deploy these solutions and changes to your tenant through a remote provisioning method and using the ALM APIs to deploy your SPFx solutions.

Hope this helps.

Thanks a bunch for the very useful info. We're currently trying to scope out our improved automated deployment. We've pretty much been ignoring any of the Feature XMLs and using the ALM Apis to update properties using Azure Pipelines. Still figuring out some details on the different deployment procedure for different types of extension.

[kskramki]

Thanks for comment. This is working as designed for SPFx solutions. Unlike Add-ins, the SPFx solutions will be readily available in all locations they have been deployed. With the exception of SPFx solutions that contain feature framework assets that need to be deployed, those assets follow the version upgrade path.

Thank you.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues