SharePoint Tip of the Month
Developing SharePoint-Hosted Apps for Office 365
As the popularity of SharePoint Online (Office 365) continues to grow, SharePoint developers must begin to approach development of custom applications from a different angle. The biggest challenge that developers face in this new arena is that SharePoint farm solutions built using server-side code like C# cannot be deployed to Office 365 environments. Therefore, any custom functionality must be developed using the SharePoint app model that was introduced in SharePoint 2013.
This new paradigm for SharePoint development certainly presents a learning curve for developers that will take time to conquer. However, some aspects of this shift will also make things easier. Foremost, SharePoint developers don’t need to setup virtual machines with full-scale SharePoint environments to build SharePoint apps for Office 365 as is required for on-premises development. All that is needed is Visual Studio 2012, or later, and an Office 365 SharePoint site collection where apps can be deployed and tested.
SharePoint App Hosting Models for Office 365
There are two hosting models available for SharePoint Apps for Office 365: SharePoint-hosted and Provider-hosted. The biggest difference between these two models is that SharePoint-hosted apps are installed on and execute within the Office 365 SharePoint site, while Provider-hosted apps are installed on the Office 365 site but require a remote web application, running on either an on-premise web server or Microsoft Azure, where the app is actually executed.
Developing SharePoint-hosted apps is the focus for this tip, so let’s explore that model a little further.
SharePoint-Hosted Apps for Office 365
Host Webs and App Webs
When a SharePoint-hosted app that contains SharePoint components (i.e. app parts, custom pages, custom lists, etc.) is deployed to an Office 365 site, the app is available from the Site Contents page on the host web where it can be launched. However, the app itself, along with any lists, content types, pages, etc. is deployed to a special website that has its own isolated domain called the app web. Even though the app web has its own isolated domain, the app web and host web are contained in the same site collection.
For example, suppose that an app, with SharePoint components beyond just the UI elements that can be deployed to a host web, is installed on a host website at the following URL:
The app for SharePoint will be deployed to app web with a URL like the following:
Notice that the app web URL contains the App ID (bdf2016ea7dacb), which is a hexadecimal number generated when the app is installed.
The following diagram illustrates the relationship between the host web and the app web:
Cross Domain Library
The fact that the client-side code runs in the app web, yet may need to access data from the host web presents an interesting set of challenges for developers. For security reasons, modern browsers include blocking mechanisms that prevent client-side code from communicating across domains. Therefore, by default any client side code running in the app web that is trying to retrieve data from the host web will be met with an “Access Denied” error when executed.
More information about implementing the Cross-Domain Library, as well as code samples, can be found at http://msdn.microsoft.com/en-us/library/office/fp179927(v=office.15).aspx.
This SharePoint Tip of the Month contributed by SharePoint Architect Rob Aycock.