SharePoint 2013 Application Development Model

Hesam Seyed Mousavi, August 18, 2013



SharePoint 2013 is the next iteration of Microsoft’s SharePoint document management and collaboration platform, and you may have heard rumors about the new application development model that Microsoft has included in the release.

As a product architect for ———, I had the opportunity to participate in the Office 15 Technology Access Program (TAP) which provided us training and access to the Office 15 platform almost a year ago. I was part of the ——– team that released an Office 15 application called the Gimmal Drop Zone App for SharePoint 2013 in the Office Store that runs on the new App model.

Needless to say, I’ve learned a lot along the way and I wanted to make sure everyone who is interested in SharePoint 2013 knows what is coming and what it means. In this article, we will discuss the new App development models and I’ll explain how it will affect your SharePoint development endeavors.

Introducing SharePoint Apps

Microsoft is moving to the cloud as quickly as the market will allow, and this means that their architecture is shifting towards a software-as-a-service model. As far as I can tell, the end-goal is to have a model where businesses pay a monthly subscription fee for their users to access a SharePoint instance that is owned and operated by Microsoft. When you think of the infrastructure, support, maintenance, and upgrades that come along with SharePoint then it’s not necessarily a bad proposition for many companies.

One problem with a hosted model, however, is that SharePoint is a lot more useful when it can be completely customized around the particular needs of a business. Out of the box, SharePoint’s functionality is certainly useful, but most organizations rely on custom SharePoint applications to realize the full potential of the platform. In a hosted environment, this is problematic because custom code runs in a shared environment; not all custom code is good code, and bad code can quickly bring a server to its knees and upset a number of different customers using that server.

With this in mind, Microsoft set out to create an extensibility point in SharePoint 2013 that would allow customers to build their own solutions for SharePoint without hurting the hosted model whenever a customer’s code was found to be ‘executionally challenged’. They came up with a model called a SharePoint App, which is simply a solution with no SharePoint server side code.

What Do You Mean No SharePoint Server Side Code? Seriously, I mean there is no server-side code that is executed by the SharePoint server. A SharePoint App is essentially a solution that can only include HTML, CSS, JavaScript, Silverlight XAP files, images, and any other static files. However, you can’t include an assembly with custom code because that would need to be executed on the server. Of course, this leads to the question ‘how do you build something useful without server side code in SharePoint?’

What are the Three SharePoint 2013 App Deployment Models?

Before we get into the details of how it’s possible to build useful apps without SharePoint server side code, we need to go over the three deployment models for SharePoint 2013 Apps:

  •     SharePoint-hosted
  •     Self-Hosted
  •     Automatically Provisioned Azure Web Application

SharePoint-Hosted App

A SharePoint-Hosted App is an application made entirely of static files that reside directly in your instance of SharePoint. When you add an application to one of your sites, SharePoint deploys the files in your App to a special App domain where your App lives. When a user accesses your App, they are redirected to a page that lives in the App domain and from which, presumably, they can use your App. There is absolutely no server-side code allowed in this model.

Self-Hosted App

A Self-Hosted App is an application where the files for the application exist on an external server (e.g. you are hosting those files yourself somewhere outside of SharePoint). When a user accesses your application, they are redirected to a page on this external server where the application resides. In this model, you can run server-side code, but it has to be run on the external server. There is still no way to run custom code on the SharePoint server. One of the benefits of this model is that the external server does not need to be a Windows server: SharePoint is really just redirecting users to a web page, so you can use any operating system and application server you want as long as it can fulfill web requests. You could be a PHP developer with a Linux machine and still make SharePoint apps.

Another interesting reason to use this model is that it puts you in complete control of upgrades. Since you own the server, you can deploy updates and have them applied immediately for all of your clients. In the other models, the user has to take some action to upgrade because you do not have access to the server on which the App is hosted.
Automatically Provisioned Azure App

An Automatically-Provisioned Azure App is an interesting concept that requires a bit of a back story to describe. First, I believe this type of App is designed to be run only from Microsoft’s hosted SharePoint environment, so its primary audience is really software vendors looking to sell to SharePoint online customers. The other two App model options are available in the hosted SharePoint environment as well as on a SharePoint 2013 corporate install.

Now, if you are a software vendor creating an App for SharePoint you have a choice to make that will affect your budget. If you make a SharePoint-Hosted App, then you cannot run server side code, but you also do not have to pay for a server on which to host your app. If you opt for a Self-Hosted App, then you can run server side code but you are responsible for paying for that server to host your app.

An Automatically-Provisioned Azure App is the best of both worlds. It is an App that is designed to be deployed to Azure. This means that it will be hosted outside of SharePoint and can run custom code. However, when a SharePoint Online user adds the App to their SharePoint instance, SharePoint Online tells them that the App needs to be provisioned to Azure, and if they opt to let that happen then the Azure instance will be billed to their SharePoint Online account. So you get all of the capabilities and flexibly server side code without any of the costs associated with hosting it yourself. This was clearly a brilliant plan hatched by the accountants at Microsoft.
Building Useful Apps without Server Side Code on SharePoint

The Client-Side Object Model (CSOM) was one of the areas into which Microsoft poured a ton of work. SharePoint 2010 had a very limited set of functionality, but the CSOM in SharePoint 2013 really allows you to execute just about any operation you can think of. As you can imagine, you must have a fully-functional client-side API when you are trying to encourage people to move away from using server side code.

There are three ways that you can access CSOM functionality, so the deployment model that you are using for your SharePoint 2013 app will determine he option that you choose.

  •     .NET / Silverlight API
  •     JavaScript API
  •     REST API

SharePoint-Hosted App

If you plan to use a SharePoint-Hosted deployment model, then you are limited to static files. However, static files can include JavaScript and Silverlight XAP files that run dynamic code on the client side. As such, you are likely to employ the JavaScript API if you’re coding on an HTML / ASPX page or the Silverlight runtime if you decide to deploy a Silverlight XAP file. You can technically use the REST API from JavaScript and Silverlight if you so wish, but the other APIs are a better fit.

GimmalSoft opted for the SharePoint-Hosted App model because our Gimmal Drop Zone App for SharePoint 2013 in the Office Store actually started out as a Silverlight component for SharePoint 2010 and was a natural fit for converting into a SharePoint 2013 app.

Self-Hosted App

A self-hosted App can take on a number of forms because it can run on any number of different operating systems with any number of different application servers. If you opt for this deployment model, then I assume you want to run server-side code. If you are hosting on a server that runs ASP.NET, then it is a natural fit to use the .NET API. If you are running a LINUX / UNIX system then the REST API is going to be a better fit because most non-Windows servers really don’t run .NET code. JavaScript and Silverlight are available in any deployment model, but these are both client-side and not server-side technologies.

Azure Provisioned App

Azure is a .NET technology, so it makes the most sense to use the .NET API when implementing an Azure-provisioned application. Once again, note that you have the option of using any CSOM API mode that you want in an Azure application, but the .NET CSOM assemblies are the best fit, considering that Azure is running on the .NET platform.

What About Authentication and Authorization?

Now that Microsoft has exposed just about every SharePoint 2013 operation from the CSOM, you have to ask yourself how you keep every idiot, who can code against the JavaScript API, from bombarding your SharePoint instance with malicious requests to delete all of your data? Fortunately, Microsoft has placed a fairly extensive layer of security around the SharePoint 2013 app model.

A SharePoint 2013 App requests a specific set of permissions when they are installed. If the current user has the ability to grant the App those permissions, then the application can be installed. If the user cannot grant that level of access, then the application cannot be installed. It’s really as simple as that.

SharePoint-Hosted Apps have the benefit of using built-in security because they operate on the same domain where the files are hosted. Self-hosted and Azure-Provisioned Apps require the use of OAuth for security purposes.

Will My SharePoint 2010 Applications Still Work in SharePoint 2013?

Yes. Many organizations have tens of millions of dollars invested in custom applications for SharePoint, and if those applications did not port then Microsoft is keenly aware that upgrading from 2010 to 2013 would be a pretty hard sell. There really wasn’t a fundamental change in how full-trust farm solutions and partial-trust sandbox solutions work, so they still exist and are still supported. If you know how to develop in SharePoint 2010, then you should be able to seamlessly move to SharePoint 2013 using farm and sandbox solutions. The App model, however, is a new way to develop and opens up possibilities for selling a SharePoint 2013 App to the masses via the Office Store and for preparing for the day when SharePoint is entirely based in the cloud.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s