How to: Update remote components in apps for SharePoint
Learn how to update the remote web applications and databases in an app for SharePoint.
Last modified: May 28, 2014
Applies to: apps for SharePoint
Be familiar with How to: Update apps for SharePoint and the prerequisites and core concepts listed in it.
For the most part, only very general advice can be provided for updating the remote components because of the wide differences in platforms and tenancy systems. The following two sections provide some guidance.
Update remote components in a provider-hosted app
For a provider-hosted app for SharePoint, you update the remote components using the best update practices of the platform on which the components are hosted. Just as the remote components of a provider-hosted app are installed separately from the installation of the app for SharePoint itself, they are also updated separately. Some points to consider:
The updated remote components should continue to work with all earlier versions of the app for SharePoint.
If you implemented a tenancy isolation system for your remote components, keep in mind that different tenants might be using multiple versions of your app, and a specific tenant might even have different versions installed on various SharePoint websites.
For a provider-hosted app for SharePoint that uses Microsoft Azure SQL Database or SQL Server, there are multiple methods for updating the database. To get started, see Upgrade a Data-tier Application.
Update remote components in an autohosted app
Basically three kinds of remote components can be in an autohosted app for SharePoint.
Azure Web Site
Microsoft Azure SQL Database
App event receivers
Some or all of these may need to be updated as described in the following sections.
Update the Azure Web Site components and the app event receivers of the autohosted app
For an autohosted app for SharePoint, you add and change elements of the Azure Web Site just as you do when you are first creating the app. When the app is updated, the autohosting infrastructure creates a new Azure Web Site with the new version of all the files, and then it deletes the old Azure Web Site. Because there is a whole-for-whole replacement, no update logic is required. And because every instance of an autohosted app gets its own copy of the Azure Web Site components, you don't have to design the new version of the Azure Web Site components to be compatible with the SharePoint components of an old version, as you do with a provider-hosted app. The same whole-for-whole replacement strategy also applies to autohosted app event receivers, InstalledEventEndpoint, UninstallingEventEndpoint, and UpdatedEventEndpoint.
Update the Microsoft Azure SQL Database in an autohosted app
You don't have direct access to the Microsoft Azure SQL Database in an autohosted app, so you can't use update methods that require either SQL Server Management Studio or the Microsoft Azure SQL Database portal. Therefore, you use data scripts or pre- and postdeployment scripts for update logic. There may be update actions that should not happen twice on the same database, such as adding a table or a column with a particular name. For this reason, you need to use conditional logic in the script to control what update actions are taken, depending on the version of the schema used by the app instance that is being updated. This, in turn, requires that the schema version be persisted, and some of the methods you could use to do this in SQL Server are not supported in Microsoft Azure SQL Database. You also need to ensure that the update of the app for SharePoint is rolled back if any error occurs when your scripts are executing. Neither of these tasks is difficult, and they are described in How to: Update the Microsoft Azure SQL Database in autohosted apps for SharePoint (with Transact-SQL code samples).
Return to Major steps in updating an app, or go directly to one of the following articles to learn how to update the next major component of your app for SharePoint.