Export (0) Print
Expand All

Register app dependencies in SharePoint 2013

apps for SharePoint

Learn how to tell SharePoint about the SharePoint capabilities and Features on which your app depends.

Last modified: November 08, 2013

Applies to: apps for SharePoint

If your app for SharePoint depends on a SharePoint capability that is not available and cannot be made available on the app web, then it will not work properly and your customers will complain. You can ensure that your app is not installed where the requisite services and Features are not available by registering the dependencies of the app in app manifest. The installation infrastructure for apps for SharePoint will check for these prerequisites and it will block installation of you app if any of them is not available.

For services, such as Excel, Access, or Visio services, the infrastructure will verify that the service is installed and licensed.

For Features, such as a Task list, the infrastructure will verify that the Feature is deployed and either:

-- activated at the Farm, WebApplication, or Site (site collection) scope

or

-- activatable, with Web scope, on the app web that is created when the app is installed.

Note Note

The app installation infrastructure will automatically activate such Features on the app web when it is created.

The following sections provide the details you need to register your prerequisites.

When your app needs access to SharePoint components outside of the app web, it must request permission for these resources in the AppPermissionRequests section of the app manifest. These permission requests also serve as prerequisite registrations because SharePoint will infer from the permissions that your app requests that it the app needs certain SharePoint capabilities to be available. In many situations, SharePoint can infer all the capabilities that your app needs and the remaining sections of this topic are not needed. However, redundant dependency registrations are not harmful.

When your app has a dependency that is not implied by its permission requests, you register each dependency with an AppPrerequisite element in the app manifest. There are three attributes in this element; Type, ID, and (optionally) MinimumVersion.

There are three possible prerequisite values for Type; Feature, Capablility, and AutoProvisioning. A Feature prerequisite is simply a SharePoint Feature that must be deployed and activated on the app web or a broader scope that includes the app web. A capability is a set of related Features and services that must be available on the app web. (AutoProvisioning is discussed in the next section.)

The optional MinimumVersion specifies the lowest version of the Feature or capability that your app requires. The attribute values are of the form n.n.n.n; for example 15.0.0.0.

The ID specifies which Feature or capability is required. If Type is Feature, the ID is the bracketed, hyphenated GUID of the Feature; for example {151D22D9-95A8-4904-A0A3-22E4DB85D1E0}. If Type is Capability, the ID is the GUID of the capability. The capabilities are listed below. To get the find the GUID of a capability see AppPrerequisite element (AppPrerequisiteCollection complexType) (SharePoint App Manifest).

  • Access Services 2010

  • Access Services

  • Managed Metadata Web Service

  • PowerPoint Services

  • Secure Store Services

  • Machine Translation Service

  • User Profile Service

  • Visio Graphics Service

  • Work Management Service

  • Duet

  • Workflow

  • Search

  • EDU

The following is an example of raw AppPrerequisites markup that registers the Workflow capability. If you are using Visual Studio, you edit the app manifest in a designer tool.

<AppPrerequisites>
  <AppPrerequisite Type="Capability" ID="{CDD8F991-B459-4512-8048-03D5A03FF27E}" MinimumVersion="15.0.0.0" />
</ AppPrerequisites>

The third Type of AppPrerequisite is AutoProvisioning. This type of prerequisite is used only with autohosted apps and you use it to register the components of the app that need to be autohosted. When prerequisite type is AutoProvisioning, the ID attribute is not a GUID. Instead, it is one of the following strings:

  • "RemoteWebHost" (To register a Azure Web Site.)

  • "Database" (To register a SQL Azure.)

If your autohosted app includes both a Azure Web Site and a SQL Azure database, then each of then gets a separate AppPrerequisite element. The following is the markup that registers both.

<AppPrerequisites>
  <AppPrerequisite Type="AutoProvisioning" ID="RemoteWebHost" />
  <AppPrerequisite Type="AutoProvisioning" ID="Database" />
</ AppPrerequisites>
Show:
© 2014 Microsoft