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 solutionwith 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
Client side coding is appreciated now 🙂
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:
- Automatically Provisioned Azure Web Application
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.
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
- REST API
GimmalSoft opted for the SharePoint-Hosted App model because our Gimmal Drop Zone App for SharePoint 2013in 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.
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?
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