Since Apps are the “next big thing” for SharePoint, from an opportunity perspective, expect to see a lot of hullaballoo about how you should create apps because they’re going to be the greatest thing to happen to SharePoint since Shared Service Applications replaced the Shared Services Provider.  However, not all apps are created equal, and apps can be created in several varieties.  This blog is focused on setting up the flavor that the developer has the most control over: On-Premise Apps.

Update: After receiving a bunch of issues with Host Headers, I’ve posted a new blog covering host headers for both web applications and site collections here: SharePoint 2013 Apps and Host headers

Configuring SharePoint 2013 Preview for On-Premise Apps

On-Premise Apps are difficult to set up because you have to do all of the setting up to get your apps hosted on SharePoint manually.  There’s no pre-configured Office 365 environment for you to use.  Unfortunately, none of these steps can be done through the UI other than the creation of a Developer Site.  To successfully develop SharePoint On-Premise Apps, you need a Developer Site Collection, a pair of Shared Services Applications, running Shared Services Instances, the Office Developer Tools for Visual Studio 2012 Release Candidate, and an App Domain and prefix.  I’ll step through each item below.

Note: Microsoft has a guide just like this one on their SharePoint 2013 documentation site: How to: Set up an on-premises development environment for apps for SharePoint [Microsoft.com]

Developer Site

While you don’t explicitly need a Developer Site to use or develop SharePoint On-Premise apps, the site template provides testing and certification functionality that doesn’t exist in other site templates.  Therefore, I recommend that you create one to simplify your initial app development.  You can only deploy from Visual Studio to a Developer Site.  Fortunately, creating a Developer Site works exactly like creating any other site collection.  Note: a Developer Site must be a site collection.  You cannot create a developer site as a sub-site.

1. Open Central Administration and select Create site collections under Application Management
   
2. Give your site collection a name and URL.  Then select Developer Site from the Template Selection view.
   
3. Click OK to create your Developer Site.  Remember the address because you’ll need it for development.

Create an Isolated App Domain

The way that SharePoint 2013 hosts Apps is somewhat odd in that there’s a single domain that Apps reside in regardless of where they actually reside on SharePoint.  SharePoint 2013 does this through site host headers, a little-known feature that actually exists in SharePoint 2010.  So while physically a SharePoint App becomes a sub-site of the site that it’s activated on, it’s logically located at a custom app domain.  The advantage here is that you can control Apps on a network level and it fully isolates the apps from SharePoint.

This isolation comes into play with cross-site scripting restrictions and prohibiting access directly into SharePoint except through the SharePoint Cross-Site Scripting library.  This reason right here is the major reason for an Isolated App Domain for SharePoint Apps.  Anyway, let’s talk about creating this isolated domain or sub-domain.

Create an App Domain

You’ll need to be running an elevated SharePoint Management PowerShell to complete this task:

1. Ensure that the SharePoint Administration and SharePoint Timer services are running

    1: Start-Service SPAdminV4

   
   
   

    2: Start-Service SPTimerV4

2. Create your isolated app domain by running this command with your App Domain in quotes:

    1: Set-SPAppDomain -AppDomain "apps.ads.com"

Running Shared Services Instances

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

Before you create your App-specific Shared Services Applications you need to make sure the Shared Services Instances are running on at least one of your SharePoint farm servers.  You can do this either through an elevated SharePoint Management PowerShell or Central Administration:

From PowerShell:

1. Start the Shared Services Instances if they aren’t started already:

    1: Get-SPServiceInstance | Where-Object {$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance

2. Ensure that the Shared Services Instances are Online:

    1: Get-SPServiceInstance | Where-Object {$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"}

From Central Administration:

1. In Central Administration select Manage services on server from the System Settings group to open the Services on Server
   
2. Make sure that the App Management Service and Microsoft SharePoint Subscription Settings Service are started on at least one server
   

App-Specific Shared Services Applications

Once your Shared Service Instances are started, you can create your Shared Services Applications to host apps: App Management Service Application and Microsoft SharePoint Foundation Subscription Settings Service Application.  You should only have one of each shared services application because the Subscription Settings Service is finicky about multiple App Management Services at the moment.  You also can’t create the Subscription Settings Service from Central Administration, but you can create an App Management Service Application from Central Administration.  This walkthrough will omit the Central Administration way because of this creation limitation.

Another important point is that both of these shared services applications must run on Application Pools running with farm administrator credentials.  The simplest option is to reuse the SharePoint Shared Services System application pool.  If you insist on creating your own application pool, your managed account must be a member of the farm administrators group.

You’ll need an elevated SharePoint Management PowerShell to complete this task:

1. Get a handle on the SharePoint Shared Services System application pool:

    1: $applicationPool = Get-SPServiceApplicationPool -Identity "SharePoint Web Services System"

2. Create the Subscription Settings Service Application:

    1: $appSubscriptionService = New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings Service" -DatabaseName "SubscriptionSettingsServiceDB" -ApplicationPool $applicationPool

3. Create the Subscription Settings Service Application Proxy:

    1: New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubscriptionService

4. Create the App Management Service:

    1: $appManagementService = New-SPAppManagementServiceApplication -Name "App Management Service" -DatabaseName "AppManagementServiceDB" -ApplicationPool $applicationPool

5. Create the App Management Service Proxy:

    1: New-SPAppManagementServiceApplicationProxy -Name "App Management Service Proxy" -ServiceApplication $appManagementService

App Prefix

Now that you have your Shared Services Applications you can set the App prefix on the SharePoint farm.  This does a lot of stuff behind the scenes, especially with the Secure Token Service (STS) to open up the OAuth channels necessary for your Apps to communicate with SharePoint.  You must have your Shared Services Applications created and running before this step.

You’ll need an elevated SharePoint Management PowerShell to complete this task and a little bit of patience:

 1: Set-SPAppSiteSubscriptionName -Name "App" -Confirm:$false

Add Your App Domain to the List of Intranet Sites in Internet Options

Now that you’re able to host apps, you’ll want to visit their pages.  Since you’re going to be crossing domains to get to the app from SharePoint, you’ll get prompted for credentials.  You can silence that prompt by adding your App Domain to the list of intranet sites in Internet Options from Internet Explorer.

1. Open Internet Explorer, click the Gear icon, and select Internet Options
2. Select the Security tab and then click Local Intranet
   
3. Select Sites to open the Local Intranet sites detector.  From here select Advanced to set the list of sites
   
4. On the list of sites, provide your App Domain preceded by a star (as shown in the example) and click Add to add it to the list
   
5. Now that your app domain is added, click Close and then OK twice to save the settings.

Office Developer Tools for Visual Studio 2012 Release Candidate

Now that your SharePoint farm is configured for On-Premise Apps, you’ll need to grab the Office Developer Tools for Visual Studio 2012.  Unfortunately, SharePoint 2013 Preview and Office 2013 Preview shipped after Visual Studio 2012 Release Candidate, so Visual Studio doesn’t have any SharePoint 2013 tools built-in.  However, there’s a download for the tools available through the Microsoft Web Platform Installer.

Note: you’ll need a copy of Visual Studio 2012 Release Candidate installed to use the tools.

1. Open Microsoft Web Platform Installer and select the Products group
   
2. In the search box type Visual Studio 2012 Office and select to install both the Microsoft Office Developer Tools for Visual Studio 2012 RC – Preview and the Microsoft Visual Studio Tools for Office 2012 Design Time – Preview.  If you’re international, you can download the Microsoft Visual Studio Tools for Office 2012 Design Time Language Pack – Preview as well.
   
3. After you’ve selected Install and accepted the license, the Microsoft Web Platform Installer will download and install the necessary prerequisites and items to set up the tools.

Using Your New App

From here, you are ready to create and deploy your first SharePoint app.  Be sure to use the URL for the Developer Site you created in the first step or Visual Studio will not deploy your App.

Disclaimer: My initials are ADS, and neither I nor Perficient have any affiliation with ads.com.  I use it in this example because it’s short and easy to remember.