Custom code in SharePoint

Posted on 7/28/2012 @ 10:59 AM in #SharePoint by | Feedback | 4627 views

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 isdeveloper 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.

Sound off but keep it civil:

Older comments..

On 7/28/2012 11:09:29 AM Sahil Malik said ..
PS: Yes I know the last image got cut. This is a general issue with my site - going to be fixed very soon.

On 7/28/2012 10:16:12 PM Not So Fast My Friend said ..
I cannot help but feel that the real underlying message from Microsoft regarding custom code in SharePoint 2013 is this: we (Microsoft) don't want to bother making SharePoint easier to customize by developers any more. It costs us (Microsoft) a lot of money to create a good developer experience (something we deliberately didn't have ready for Visual Studio 2005 when SharePoint 2007 first came out back in 2006) and quite frankly, we (Microsoft) don't see a lot of revenue being generated in a future that promises to be dominated by smart devices, not desktop PC's. You (developers) should be glad we (Microsoft) finally, after years of your incessant begging, decided to make SharePoint development a tiny bit easier by "borrowing" (some might say copying) things like WspBuilder and LINQ to SharePoint from CodePlex and sticking them inside Visual Studio 2010 (and eventually the three additional things we forgot: list instance, list template and content types into Visual Studio 2012), so do us (Microsoft) a favor and stop trying to write custom code because we just don't feel like putting forth the effort any more to provide a first-class developer experience. It just doesn't make sense financially any more to us (Microsoft) or our shareholders to enhance the developer experience in Visual Studio any more. Yes, we (Microsoft) know that what you see in Visual Studio 2012 in the year 2012 should have been in Visual Studio 2005 back in late 2006, but hey, better late than never, right? As for the future, look what we did with Entity Framework - it's now open source because we just don't feel like paying our own people to fix and enhance it. It's probably what we'll eventually do with SharePoint developer tools too although we'll hold off on announcing it until we can sell a bunch of copies of SharePoint 2013.

On 7/29/2012 7:37:27 AM Sahil Malik said ..
To the last person who left the comment. Don't be afraid to leave your name :).

I think you're absolutely right. Microsoft cannot make SP innards clean enough to allow custom code. So all this stuff they are coming with seems to be geared around pushing your custom code out of SharePoint. The server is too fragile, don't touch it LOL.

But honestly, is that a bad thing? Think about it this way,

We moved on from Win32API to .COM to .NET for the same reasons, it's easier and cleaner to write code in .NET.

As long as I get a way to meet end user requirements, I am okay with not having to put my code inside SP. Though I will admit, we are not there today. But either way, I am happy to see options other than farm solutions for at least many scenarios.

Sometimes, it is cheaper to drive around a rock than to drill a hole through it.

On 7/31/2012 2:29:24 AM Prasad said ..
Thanks Sahil for coming up with an excellent blog.

Even though we know sharepoint is ECM offering from microsoft with all the necessary OOTB features, in reality i have seen people use sharepoint as just a frontend website to put all their custom code and design. This might be because they are from developer background want to suffice every single requirement using their .net expertise.

This may be because microsoft is not marketing sharepoint as one of the code less solution with all ecm features or there no proper awareness to tell when custom code is essential or they may dont know all the capabilities of SharePoint.

And the million dollar question is, why companies are spending money on custom code development even after buying costly SharePoint licences.

On 1/10/2013 5:07:01 AM Jakeem Russell said ..
You can modify HTML, anticipate things such as auto complete functions and routing functions just like what you are used to in Visible studio.