Microsoft launched SharePoint 2013 with great fanfare. But what stuck out was the introductory blog post by Corporate SVP of SharePoint, Jeff Teper. You can read the blogpost titled “The New SharePoint”. But one paragraph has stuck out,
“Use SharePoint as an out-of-box application whenever possible - We designed the new SharePoint UI to be clean, simple and fast and work great out-of-box. We encourage you not to modify it which could add complexity, performance and upgradeability and to focus your energy on working with users and groups to understand how to use SharePoint to improve productivity and collaboration and identifying and promoting best practices in your organization.”
The keywords here is “whenever possible”. The reality is, frequently it is not possible to not customize SharePoint in order to meet the customer requirements. But you must try and minimize SharePoint customization.
There are many ways to deliver functionality in SharePoint.
1. Directly through the browser. SharePoint comes with an immense set of capabilities that don’t require you to open any development tool – you can create and author basic functionality such as document libraries, discussion boards, wikis directly through the browser.
2. Thick or thin Office client applications. Applications such as Excel, Access, Word, InfoPath, Visio allow you to greatly enhance SharePoint functionality. These also come in a “thin” form, which is running under Office Web Applications. Even there, they are quite useful and work quite well with SharePoint. Under most circumstances they can also be used with SharePoint online/Office 365 as well. Of very special mention here is an application called SharePoint Designer. SharePoint Designer allows you to do thing such as author external content types that bring external data into SharePoint, or author workflows, etc. SharePoint designer is an invaluable asset in the hands of both IT professionals and tech-savvy business users.
3. PowerShell scripts. I put this under development because that is pretty much what it feels like. But, usually PowerShell scripts are text files with extension .ps1. Their purpose is to automate – and they are usually used by IT staff. So technically speaking, you can use PowerShell to automate tasks that you need to do reliably in a repeatable fashion. PowerShell is increasingly being used with every Microsoft product, and Office 365 and SharePoint are no exception.
4. Visual Studio based development. These is where things get tricky, but remember I said essential – visual studio development is essential, you cannot shun it out. Microsoft offers a rich set of tools for developing against SharePoint using Visual Studio. Visual Studio based development lets you develop various kinds of artifacts.
a. Solutions: These are .WSP files, which are .CAB files renamed to .WSP. Inside them, they always contain a manifest.xml which tells SharePoint what is inside the WSP. WSPs can be deployed in two different ways. Note I said “deployed” as – because the WSP itself has no clue or information if it is a farm solution or a sandbox solution. There is no flag inside a .wsp that says “isSandbox=true”. But given how you deploy them, they run differently in SharePoint. I cover the technical details of how exactly they run and how exactly they are architected in a different chapter. For now, here are the two kinds of .wsps (or rather how they are deployed and run) -
i. Farm Solutions: These are .WSP files that are deployed using powershell and require farm level admin access to the server. They are added to central administration, and then made available to one or more web applications. These are very powerful .wsp files that require you to have full farm level admin access to the server to deploy. Installing a farm solution can make changes to the disk, deploying DLLs in GAC (Global Assembly Cache), and be able to do things like format your c drive, call an external database or web service etc. These are sometimes essential, but their use must be minimized. In SharePoint 2007, this was the only Visual studio based .wsp you could write or deploy.
ii. Sandbox Solutions. Sandbox solutions are also .wsp files with the same structure as farm solutions. The biggest difference however is that they are much more restricted, monitored, with boundaries on what they can do placed ahead of time, and most of all – much easier to deploy. The biggest advantage of Sandbox solutions is that they can never bring the farm down. The maximum damage they can cause is to bring a site collection down for up to 24 hours. A site collection admin can deploy and activate a sandbox solution directly through the browser. A sandbox solution can never touch the file system or GAC of the server – it works completely through the content database. The biggest disadvantage of Sandbox solutions of course is that they are extremely restrictive. As a result, you have to do some interesting workarounds to get basic functionality working in them.
b. Apps. You have a smartphone? No? But you are aware that there is this invention called smart phone and on this invention they have this thing called apps, right? Apps are these well-defined, pre-fabricated widgets of functionality that you can download and install on your device. They perform a very specific function. For instance, you may have an app on your smart phone to check local gas prices. With SharePoint 2013, and Office 2013, Microsoft is extending this app concept to SharePoint and Office. This is really exciting because this will allow customers to gain functionality they need and can trust, and it creates opportunities for developers to create applications with a revenue model. And it is great for Microsoft because it keeps SharePoint and Office much more stable – everyone wins. Within App Development, you have many choices,
i. SharePoint Apps. The important thing to remember about SharePoint apps it that these code running in the browser – and NOT on the SharePoint server. This does not mean you don’t have code running on the server, code can run on the server – just not on the SharePoint server. Such code is usually running on a different server, one that you provide, or one that sits in Azure. The obvious question here is that how do you handle cross-domain requests – afterall your app-server could be and will usually be on a separate domain. Also, how does your app gain access to SharePoint resources? The answer is, this is all built on a cross-domain friendly, JSONP and OAuth 2.0 based architecture. But since you don’t have any code running on the SharePoint server, you can never damage the SharePoint server – and that’s a big win for apps. Within SharePoint apps, you have various categories, you can think of these categories categorized based on two criterion, a) How you host the app, b) How you run the app.
1. How you host the app. There are mainly three choices here,
a. An App Web. This provisions an isolated SPWeb (SharePoint site) on a parent web. This cannot leverage any server side code – only client side code is allowed. Client side code however is free to interact with SharePoint using client object model and REST API.
b. Developer or Self-Hosted app. Put simply, this is client side code that runs inside SharePoint, and talks to server side code that runs on a server that you bring. I call this BYOS – Bring your own server. The server side code can run ASP.NET MVC, PHP, Java, or anything you wish. This code can interact with SharePoint using CSOM/REST + OAuth.
c. Azure Auto-provisioned App. This is “developer hosted app made easy”. The server side code here runs in Azure, but they make it a bit more convenient for you to provision the server side code for you in Azure. When the app is installed, it automatically provisions an Azure website when the app is installed. The important thing to remember here is that you get a new website anytime the app is installed – so if 3 people install the app, you have 3 azure websites.
2. How you run the app. How I run the app, I mean the user experience. Here also, you have 3 choices,
a. Immersive App: This type of app takes over the entire page – it runs as an IFRAME inside the browser. There is of course a standard way of hosting this IFRAME within SharePoint, it’s not just any IFRAME.
b. Part App. This type of app occupies a portion of a page. You have to be particularly careful of an app that shares page space with other apps – remember a browser does not provide app isolation. So if there is another app that has secure access to an external site, your app can bridge over to it.
c. Extension App. Think of this as a launch into another application through SharePoint. This could be as simple as a link on the ECB menu.
Writing SharePoint apps is a whole science in itself. There are many things to consider such as branding, architecture, app scoping, etc. Yet another important consideration is how do end users obtain such apps. There will be a public marketplace, a possible enterprise corporate catalog, or an alternate custom deployment process. These are considerations I cover in a subsequent chapter.
ii. Office Apps. Along with Apps for SharePoint 2013, Microsoft has also rolled out the concept of Apps for Office clients. This includes both Office thick client and thin client. These are also client side code that runs inside the office client and can interact with both the office client and server side artifacts. The client side code is usually written in JavaScript and HTML5, though you could write it in Silverlight and Flash. I wouldn’t advise using Silverlight or Flash if you can achieve the functionality through JavaScript. These apps are usually categorized into the following,
1. Task Pane Apps. Think of these as apps running in a task pane by the side of the main document you are working on. These are available in Excel thick client and web companion, Word thick client only, and project thick client.
2. Content Apps. These apps become part of the content of the document itself – so usually when you print, the content of the app will get printed as well. These are available in Excel thick client and web companion, and outlook thick client and mobile web and web app.
Visual Studio shows you the various app development choices in its introductory screen to Office Apps,
5. Office 365 development tools, or Codename “Napa”. This is an alternative to Visual Studio when it comes to app development for the cloud. This is a lightweight, completely in-browser experience allowing you to build SharePoint and Office web apps. It is an online companion to Visual Studio. Similar to Visual Studio, it presents you with a dialog asking you what kind of app you would like to build as shown below,
Once you select the kind of app you would like to write, it presents you, right through the browser, the equivalent of a visual studio solution right through the browser. You can edit JavaScript, HTML, expect things such as intellisense, code highlighting, autocomplete features, code cleanup and navigation features similar to what you are used to in Visual studio – except there is no Visual Studio to install, everything is running completely through the browser.
Finally, if you do need to leverage the full power of Visual Studio, you can export your “Napa” app into Visual Studio and get rolling with features such as JavaScript debugging etc.
So coming back to the original point of contention – to custom develop or not! Here is a little decision tree. This decision tree does not cover office apps.
To reiterate, avoid custom development. But when you can’t, pick the least invasive custom development approach.