1. Manifest and Assets
At the heart of an .app
file is the app manifest file. This file is the central location that
SharePoint reads from when interrogating an app. The manifest contains
things such as the app name, product ID, version, security information,
and information about the starting page of the app. An example of a
simple app manifest follows:
<?xml version="1.0" encoding="utf-8"?>
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
Name="SharePointAppPackage" ProductID="{6b80672f-3edc-409c-94fe-608ee4264280}" Version="1.0.0.0"
SharePointMinVersion="15.0.0.0">
<Properties>
<Title>SharePointAppPackage</Title>
<StartPage>~remoteAppUrl/Pages/Default.aspx?{StandardTokens}</StartPage>
</Properties>
<AppPrincipal>
<AutoDeployedWebApplication />
</AppPrincipal>
<AppPermissionRequests>
<AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web"
Right="FullControl" />
</AppPermissionRequests>
<AppPrerequisites>
<AppPrerequisite Type="Capability" ID="A83C8D70-71DE-4260-9FB8-677418EB47F2" />
<AppPrerequisite Type="Feature" ID="5B79B49A-2DA6-4161-95BD-7375C1995EF9" />
<AppPrerequisite Type="AutoProvisioning" ID="Database" />
<AppPrerequisite Type="AutoProvisioning" ID="RemoteWebHost" />
</AppPrerequisites>
</App>
In this example you can see in the app node the
name of the application specified; the product ID, which uniquely
signifies this app; the version of the app; and the minimum version of
SharePoint that is required. Although at the time of writing there is
only one version of SharePoint 2013, in the future developers will be
able to target their apps at a minimum version to ensure compatibility.
Additionally, in the AppPermissionRequests
node an application can specify the minimum permissions it needs
granted for it to work correctly. In this case it is asking for full
control permissions on the host Web. Finally, the manifest specifies a
number of AppPrerequisites.
These are IDs of features and capabilities that must be enabled or
turned on in the SharePoint site and farm so that the app can run. For
example, the sample code is requesting that the Media Player Web Part
feature be activated and as well as the Managed Metadata Service
Capability. As a developer you don’t need to know the IDs by GUID. The
Visual Studio tools assist with this via a GUI-style property panel.
When you deploy an app to SharePoint the first
thing SharePoint does is unpack and take a look at the manifest file.
This tells SharePoint what sort of app it is, such as Autohosted.
Additionally, SharePoint looks for the other deployment assets such as
a SharePoint solutions package, a Web deploy package, and a database
package. Each of these are deployed differently and are discussed in
the following sections.
3. SharePoint Solution Package
An .app
file may also contain a SharePoint solution package, which would in
turn contain a variety of SharePoint components such as the following:
- Lists/libraries
- Site columns
- Content types
- Event receivers
- Modules
- UI actions
Much like in SharePoint 2010 full-trust
applications and sandbox solutions, the aforementioned components are
defined declaratively using XML and packaged in a .wsp file, which makes up the SharePoint Solution file. In fact, in many regards the new app model’s .wsp packages are the next generation of solution package formats that started with custom template .stp
files in SharePoint 2003. Much of the declarative XML contained within
these new packages shares historical roots in the earlier template
formats. However, don’t be fooled — many of the techniques and options
you might have used in the past are no longer supported or available in
the new packaging format, so caution is advised.
In the past, understanding the structure of a .wsp
file was important, and in many ways it still is for those looking to
do more advanced debugging and diagnosis. However, the SharePoint tools
in Visual Studio have developed so much in the 2012 edition that the
packaging format is largely taken care of for you along with inclusion
of the .wsp inside an app package.
Similar to an .app file, a .wsp file is another type of file in disguise — in this case a .cab file. These can be simply renamed and opened with Windows Explorer. Also like an .app file, a .wsp file contains a manifest and other supporting assets.
Along with the manifest file, a .wsp
file contains XML definitions for the components it contains, which are
grouped into Features. A Feature can be activated or deactivated
through the SharePoint UI and is a fundamental building block of
SharePoint solutions. When you’re building apps many of the same
Feature constructs apply. Components are grouped into Features, which
are packaged into a .wsp. Visual Studio takes care of much of the Feature creation for you; however, it is worth being familiar with the contents of a .wsp so that if you need or want to learn about how something works under the hood you know where to look.
During installation of an app the .wsp
package is used to deploy the Features and artifacts to the app Web,
which is the SharePoint site that is created for the instance of the
application. Note the .wsp isn’t
deployed to the host Web, which is the site that the application is
installed in. Therefore, lists, content types, and so on that are
defined in this package will be deployed to the app Web only.
Only two types of components can be deployed into the host Web versus the app Web. Those are:
- Client Web Part (Host Web) also known as App Parts
- Custom UI Action (Host Web)
These are not included in the .wsp but rather included in the app package as Features without a parent .wsp.
