First, you will learn about the details of how
apps are packaged into redistributable files. After that, you will see
how these files are published and installed to make SharePoint apps
available to users. As you will see, the SharePoint app model provides valuable support for managing apps in a production environment and upgrading to newer versions.
A SharePoint app is packaged up for deployment by using a distributable file known as an app package.
An app package is a file built by using the zip archive file format and
it requires an extension of .app. For example, if you create a new
SharePoint-hosted app project named MySharePointApp, the project will
generate an app package named MySharePointApp.app as its output.
Note that the zip file format for creating an app package is based
on the Open Package Convention (OPC). This is the same file format that
Microsoft Office began using with the release of Office 2007 for
creating Word documents (.docx) and Microsoft Excel workbooks (.xslx).
The primary requirement for an app package is that it contains the app manifest as a top-level file named AppManifest.xml. The SharePoint host environment
relies on metadata contained in the app manifest so that it can
properly configure an app during the installation process.
An app package will usually contain an app icon file named AppIcon.png. The AppIcon.png file, like many of the other files in an app package, is paired with an XML file named AppIcon.png.config.xml. The purpose of this XML file is to assign the AppIcon.png file an identifying GUID.
Understanding the app web solution package
In addition to the AppManifest.xml
file, the app package often contains additional files that are used as
part of the app’s implementation. For example, the app package for a
SharePoint-hosted app contains a file for the app’s start page along
with other resources used by the start page such as a CSS file and a
JavaScript file. These are examples of files that are added to the app
web as part of the app installation process.
The distribution mechanism used by a SharePoint app to add pages and
lists to the app web during installation is a standard solution
package, which is a CAB file with a .wsp
extension. If this sounds familiar, that’s because the solution package
file embedded within an app package has the exact same file format as
the solution
package files that developers have been using to deploy SharePoint
solutions in SharePoint 2007 and SharePoint 2010. The one key
difference is that the solution package used by the SharePoint app
model to add files to an app web is not a stand-alone file. Instead, it
is embedded as a .wsp file within the app package, as shown in Figure 1.
When a user installs a SharePoint app, the SharePoint host
environment examines the app package to see if it contains an inner
solution package. It is the presence of an inner solution package
within the app package file that specifies to the SharePoint host
environment whether it needs to create an app web during installation.
If the app package does not contain an inner solution package, the
SharePoint host environment installs the app without creating an app web.
The app web
solution package contains a single web-scoped feature. The SharePoint
host environment activates this feature automatically on the app web
immediately after the app web is created. This feature is what makes it
possible to add declarative elements such as pages and lists to the app
web as the app is installed.
An app web solution package cannot contain a .NET assembly DLL with
server-side code. Therefore, you can say that the app web solution
package embedded inside an app package is constrained because it must
be a fully declarative solution package. This is different from the
solution packages for farm solutions and sandboxed solutions, which can
contain assembly DLLs with custom .NET code written in either C# or VB.NET.
Keep in mind that the installation of a SharePoint app doesn’t always result in the creation of an app web. Some apps
are designed to create an app web during installation and some are not.
A SharePoint-hosted app is the type of app that will always create an
app web during installation. This is a requirement because a
SharePoint-hosted app requires a start page that must be added to the
app web.
However, things are different with a cloud-hosted app. Because a
cloud-hosted app usually has a start page that is served up from a
remote web, it does not require the creation of an app web during
installation. Therefore, the use of an app web in the design of a
provider-hosted app or an autohosted app is really just an available
option as opposed to a requirement as it is with a SharePoint-hosted
app.
When you design a provider-hosted app or an autohosted app, you have
a choice of whether you want to create an app web during installation
to store private app implementation details inside the SharePoint host.
Some cloud-hosted apps will store all the content they need within
their own external database and will not need to create an app web
during installation. Other cloud-hosted apps can be designed to create
an app web during installation for scenarios in which it makes sense to
store content within the SharePoint host environment for each installed
instance of the app.
