You can install SharePoint in two
primary ways. As with SharePoint 2010, you can install the full version
of SharePoint Server and have all of your assets and content running in
an on-premises environment. Alternatively, you can provision an instance
of Office 365 (O365) and then take advantage of SharePoint Online (or a
cloud-hosted version of SharePoint). You saw some examples of
SharePoint Online in Chapter 1, “Introduction to SharePoint 2013,” and
you’ll see more in this chapter. Irrespective of how you deploy your
SharePoint instance, the new app model for SharePoint holds true for
both on-premises versions of SharePoint (SharePoint Server) and
cloud-hosted versions (O365).
Although you have the ability to manually create
SharePoint 2013 site collections and configure and brand those sites to
your business needs. One of the key
evolutionary areas in SharePoint 2013 is the new app model. You
implement the new cloud model, broadly speaking, through the creation
and deployment of either Apps for SharePoint or Apps for Office.
Apps for Office
Apps for Office are a new breed of
Office 2013 applications that use a nonmanaged code approach to building
in-context document and mail apps (think Excel, Word, and Outlook
add-ins). These apps enable you to use HTML, CSS, or JavaScript to build
lightweight apps that integrate with cloud-based apps. The cool thing
here is that you can use a rich JavaScript object model to integrate
with parts of the document or mail item. Apps for Office consist of a
web page plus an XML-based configuration file called a manifest
file, which configures items such as links to an external website,
permissions, and so on. You can think of Apps for Office as web apps.
Although Apps for Office primarily target Office,
you can integrate them with Office 365, documents, and mail items —
artifacts that might in some way integrate with SharePoint. Figure 1
shows an example of an App for Office. In this example, the App for
Office is integrated with the mail and it displays data from a Windows
Azure SQL database within the mail item: Related Requests from Chris
Johnson.
Apps for SharePoint
Apps for SharePoint (or SharePoint App)
is the official name for apps you build and deploy to SharePoint. For
those familiar with SharePoint, think of the SharePoint App as the
evolution of the SharePoint Solution (that is, WSP). As mentioned in
Chapter 1, the SharePoint App uses the .APP extension (whereas the
SharePoint Solution uses .WSP).
The SharePoint App is a move toward a more
cloud-centric development model — one where the code does not reside on
the same server as SharePoint. This is a result of a greater migration
of code to the cloud and a need to architect a platform to support
smother updates and code that is loosely coupled to SharePoint and
deployed to the cloud, as well as to mitigate the growing problems that
server-side code typically presents (for example, performance and
site-loading issues if the code is not properly written, deployed, or
tested). Figure 2
shows an example of an app for SharePoint that integrates Windows Azure
data — in fact, the same data that is being consumed in the app in Figure 1 is likewise integrated with SharePoint in Figure 2.
As mentioned earlier, when you build an app for
SharePoint, you are building an .APP file. In reality, the .APP file is a
“package” of files similar to a CAB file. Within the .APP package are a
number of key files that are primarily made up of configuration files
and libraries. For example, Figure 3
illustrates an .APP file that is created when you build and publish an
app for SharePoint (you will walk through this later in this chapter).
If you change the .APP extension to .ZIP you can see that the .APP
consists of a number of files and another ZIP file. The zipped files
represent the web portions of your SharePoint application, whereas the
XML files represent more detailed configuration information for your
app.
One of the key XML configuration files that you’ll see in both Apps for SharePoint and Apps for Office is the AppManifest.xml
file. In this configuration manifest you’ll find key elements such as
app meta data, app permissions and scope for those permissions, GUIDs
for Web apps, and so on. The following code snippet shows a simple
example of an AppManifest.xml file.
<?xml version="1.0" encoding="utf-8" ?>
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
Name="AutohostedEmployeeList"
ProductID="{125f9ba3-5efc-414a-ac53-023919ac2142}"
Version="1.0.0.0"
SharePointMinVersion="15.0.0.0"
>
<Properties>
<Title>AutohostedEmployeeList</Title>
<StartPage>~remoteAppUrl/Pages/Default.aspx?{StandardTokens}
</StartPage>
</Properties>
<AppPrincipal>
<AutoDeployedWebApplication/>
</AppPrincipal>
<AppPrerequisites>
<AppPrerequisite Type="AutoProvisioning" ID="RemoteWebHost" />
</AppPrerequisites>
<AppPermissionRequests><AppPermissionRequest
Scope="http://sharepoint/content/sitecollection/web"
Right="Write" /></AppPermissionRequests></App>
NOTE You can edit the AppManifest.xml file using either the Visual Studio 2012 IDE (visual designer), or you can right-click the AppManifest.xml file and select View Code to directly work with the XML.