How to publish an update to an Office Add-In currently in the Store

3
votes

I am looking for some information regarding hosting an updated version of our current hosted application on web store.

My query is, the manifest file which our exiting version of app say Ver. 1.0 hosted on the web store is pointing to a source location (azure website) say myappversion1.0hostedapp.com, now I want to host the next version of the app, say Ver. 2.0 in which I have added few new functionalities and some bug fixes.

So do I have to push my current changes on the existing URL say myappaversion1.0hostedapp.com , and then submit the app on office web store, in this case the old version will get messed up.

OR

We have to give a new source URL say myappversion2.0hostedapp.com in updated manifest file and then submit the app to web store, this will make ensure that the old version remains intact till our new version gets verified by Microsoft team.

Questions-

  1. In case of later scenario, what will happen to our manifest file Ver. 1.0 which is pointing to the say myappaversion1.0hostedapp.com, when my new version gets approved by Microsoft tech team, say myappaversion2.0hostedapp.com

We are not very clear on hosting next version of app on the existing one. It will be great if someone can get us some clarity on this.

1
office-js

1 Answers

1
votes

There are several pieces to this question, and to the Office add-in publish/update process in general.

First off: if all you're doing is updating web content, there is absolutely no reason/need to rev your manifest. You simply redeploy the web content to your site, just like it were any other website. The only thing you need to worry about is the usual web caching -- i.e., if you had changed the DOM and now have a new button that's supposed to do something (or worse, you're renamed a button), but the JavaScript is cached and so the HTML page loads with the old JS/CSS, you would obviously be in an inconsistent state. But that's nothing new for Office add-ins, that's the standard thing you have to deal with on the web (with solutions such as incrementing the JS/CSS file names so that they go in lock-step with updated HTML, controlling cache expiration, etc.)

Now comes the Office-specific manifest part. The manifest captures a number of "external references" to the website, most notably the start page URL and icon URL. So if your website changes those, be sure to still keep the old version around (even if with just a redirect for the start page, and a copy for the icon) until your manifest has been submitted and approved by the store. I believe that once the manifest is approved by the store, add-ins will automatically start using the latest (I don't think users have a choice on whether to use the latest or not -- they get an FYI notification, but I don't believe they can just say "use the older app", since it's not the app but just the manifest that it would be referring to anyway). So your usage of the old URL should taper off fairly soon (though not 100% immediate -- I believe it would generally take someone closing and re-opening Word or Excel, etc., before the new manifest version would take effect).

PS: While the icon, start page URL, description, requirement set, etc etc can all change in the manifest between versions, the app ID must remain the same. This ID is the unique ID that identifies the app as being "the same" from the Store and from the reference-within-the-document perspective.

Hope this helps,

~ Michael Zlatkovsky, developer on Office Extensibility team, MSFT