These two types of features are used to extend
the user interface of the host web, as opposed to many of the other
types of elements in an app that are added to the app web. For this
reason, the XML files containing the definitions of client web parts
and UI custom actions are not deployed within a solution package
embedded within the app package. Instead, the XML files that define
client web parts and UI custom actions are added to the app package as
top-level files.
Consider an example SharePoint app named MyAppParts that contains
two client web parts. The contents of the app package for this app will
contain a top-level elements.xml file for each of the client web parts and a top-level feature.xml
file for the feature that hosts them. When Visual Studio 2012 creates
these XML files and builds them into the output app package file, it
adds a unique GUID to each file name to avoid naming conflicts, as
illustrated in Figure 2.
The feature that hosts client web parts and UI custom actions is a web-scoped feature known as a host web feature.
The SharePoint host environment is able to detect a host web feature
inside an app package during app installation and activate it in the
host web. When an app with a web host feature is installed at tenancy
scope, that feature will be activated in more than one site.
Packaging for autohosted apps
When it comes to packaging
a SharePoint app for distribution, autohosted apps are more complicated
and deserve a little extra attention. The extra complexity is required
because the app package for an autohosted
app must contain the resources required to create an ASP.NET
application on demand to deploy the remote web. An autohosted app can
also be designed to create a SQL Azure database, as well, during the
app installation process.
When you create a new autohosted app, Visual Studio 2012 creates two
projects. There is one project for the app itself and a second web
project for an ASP.NET application to implement the remote web. For
example, if you create a new autohosted app using the name
MyAutoHostedApp, Visual Studio 2012 creates an app project named
MyAutoHostedApp and an ASP.NET project named MyAutoHostedAppWeb, and
adds them to a single Visual Studio solution.
What is important to understand is that the app package built for
the MyAutoHostedApp project must contain all the necessary files to
deploy the ASP.NET project named MyAutoHostedAppWeb. This is a
requirement because the installation of this app package must provide
the Office 365 environment with the means to provision the remote web
as a Windows Azure application. This is what makes it possible for an
autohosted app to create its own remote web during the installation
process.
Visual Studio 2012 relies on a packaging
format that Microsoft created especially for the Windows Azure
environment by which all the files and metadata required to deploy an
ASP.NET application are built in to a single zip file for distribution.
This zip file is known as a web deploy package.
When used within the SharePoint app model, the web deploy package is
embedded within the app package of an autohosted app for distribution.
When Visual Studio 2012 builds the web deploy package for an autohosted
app, it creates the file by combining the app package name together
with a web.zip extension. For example, an app packaged named MyAutohostedApp.app will have an embedded web deploy package named MyAutohostedApp.web.zip.
Now, consider the scenario in which an autohosted app has an
associated SQL Azure database. The Office 365 environment must create
this database on demand during app installation. Therefore, the app
package must contain the resources required to create a SQL Azure
database containing standard database objects, such as tables, indexes,
stored procedures, and triggers.
The SharePoint app packaging model takes advantage of a second packaging format that Microsoft created for Windows Azure known as a Data Tier Application package.
In this packaging format, the metadata required to automate the
creation of a SQL Azure database is defined in XML files that are built
in to a zip file with an extension of .dacpac. The name of the Data
Tier Application package is typically based on the name of the
database. For example, a SQL Azure database named MySqlDatabase will
have an associated Data Tier Application package named MySqlDatabase.dacpac. If you look inside a Data Tier Application package, you can locate a file named model.xml, which defines the database objects that need to be created.
Figure 3
shows the layout of an app package for an autohosted app that will
trigger the Office 365 environment to create a remote and a SQL Azure
database as part of the app installation process. Remember that the web
deploy package is required in an autohosted app package, whereas the
data tier application package is optional.
When you create an autohosted
app, Visual Studio 2012 automatically creates the web project and takes
care of setting up all that’s required to build the web deploy package
into the app package. However, you have to take a few extra steps to
create a SQL database project and configure it to properly build the
Data Tier Application package in to the app package.
The first step is to create a new SQL database project in Visual
Studio 2012 and add it to the same solution that contains the
autohosted project. Next, on the Properties page of the SQL Database
project, go to the Project Settings tab and change the target platform
setting to SQL Azure. This is the step that changes the project output
to a Data Tier Application package. After this, you must build the SQL
database project at least once to build the Data Tier Application
package.
The final step is to configure the app project to reference
the Data Tier Application package. You can accomplish this by using the
property sheet for the autohosted app project. You will find that there
is a project property named SQL Package. Once you configure the SQL Package property to point to the Data Tier Application package (.dacpac)
file, you have made the necessary changes so that Visual Studio 2012
will begin building the Data Tier Application package into app package
file.
