SharePoint has lots of development techniques. And, they keep growing. By the time I am finished writing this article Microsoft might come up with another. So, let’s go through various options for SharePoint custom development and explain when to and when not to use them…
Before we start, let’s talk about the various ways to deploy SharePoint:
- On-Premises: on-premises is when you install a SharePoint server and control the Infrastructure. You have more options from a SharePoint Development technique perspective with on-premises implementations. However, you have the headache of maintenance and upgrades.
- SharePoint Online: we are talking about the Office 365 cloud here. Microsoft maintains the servers for you. Microsoft does incremental upgrades. But, because you don’t control the servers, you have limited SharePoint Development techniques. Why? Microsoft doesn’t want you breaking a server that is shared with you and someone else.
- Classic vs. Modern pages: this is an option if you use SharePoint Online (note: Microsoft has this on the roadmap for SharePoint 2019 On-Premises). As of right now, Modern pages are evolving and some of the techniques we will talk about differ for Modern pages vs. Classic pages.
SharePoint Farm solutions are the “old-school” way to develop against SharePoint. As any SharePoint developer who’s been around since the SharePoint 2010 version – they’ve probably done a farm solution. This is .Net development and server-side deployment. Basically, a developer assembles a deployable package of code. Typically the code is organized using the concept of site features which allow SharePoint admins to toggle the deployed code. These packages also have XML based configurations that allow developers to define the scope, type (ex: Custom Action vs Style Sheet), storage options (such as pushing files to places in SharePoint like the Master Page Gallery), etc.
The main point about Farm solutions is that it is a mix of putting files on the actual SharePoint server in a place called the “hive” and registering those files within the SharePoint database. The key here is that files are actually placed on the server. And server-side code runs against dlls on the SharePoint server.
The main benefit of Farm solutions is that you have full access to the SharePoint server-side API. You also have a variety of techniques that can only be used by leveraging server-side code (note: SharePoint client-side APIs are catching up to the server-side APIs, but anyone that’s developed long enough knows there are just some things you need to do on the server).
The main downside of Farm solutions is that you have to deploy them to the server. What does that mean? It means these only work for On-Premises installations. That’s right, the way we’ve developed SharePoint for over 10 years’ is no longer an option for SharePoint Online.
Another downside of Farm solutions is that you have to develop on a SharePoint server. Most SharePoint developers actually have virtual SharePoint machines purely to do development. If you don’t develop on a SharePoint server Visual Studio will complain about missing dlls required to do development. There are some “tricks” to develop on your own machine, but they all have side-affects. So, the investment and maintenance to develop Farm Solutions is very high.
When to use Farm Solutions:
Only use Farm Solutions for On-Premises installations. In fact, this should be a last resort. Why? There is always the chance you will migrate to SharePoint Online in the future. You could spend weeks, months, if not years building something that you might have to completely re-build in the future. I rarely build Farm Solutions anymore. I’ve converted too many of these to SharePoint Online recently. So, with all new implementations, I am forward thinking and try to never resort to this development technique anymore.
Sandboxed Solutions were introduced in SharePoint 2010. They use a limited server-side API and run in something called the Sandbox. The intent from Microsoft when introducing Sandboxed Solutions was a valid attempt. They were trying to be forward thinking for co-hosted SharePoint servers and probably eventually for their cloud based solutions. Supposedly, Sandboxed Solution code was limited in order to prohibit developers from writing code that could greatly affect the security or stability of a SharePoint environment. However, many developers didn’t like the limitations of Sandboxed Solutions. Over time Microsoft started taking features away from Sandboxed Solutions. In fact, Microsoft no longer allows custom code in Sandboxed Solutions. So, basically Sandboxed Solutions have been relegated to deployment of declarative (anything configured through XML – copying files, list template instances, etc…) and client-side customizations.
In addition, Sandboxed Solutions run On-Premises and SharePoint Online.
However, there are downsides. Similar to Farm Solutions, you need a SharePoint server to do development. If you try to add a Sandboxed Solution project to Visual Studio on your local development machine you will get an error. It’s the same problem as Farm Solutions. It’s looking for dlls on your computer that come with the SharePoint installation.
In addition, what you can actually do with Sandboxed Solutions is very limited. You can’t build complicated WebParts. You can’t write code that accesses the SharePoint server-side API. There is just a lot you can’t do.
When to use Sandboxed Solutions:
Add-Ins (previously known as Apps) were introduced in SharePoint 2013. RePoint is very familiar with them. In fact, we won the inaugural Office/SharePoint Add-In development contest. Basically, Microsoft was trying to solve a couple issues with one development technique.
- Ability to run in SharePoint Online
- Ability to deploy to the Microsoft Office Store to sell
- Similar techniques for all Office products (i.e.: similar techniques in SharePoint, Word, PowerPoint, Excel and Outlook)
The basic premise of Add-Ins is that they run in a separate context than the actual SharePoint site (i.e.: they are actually running in a separate website). You connect the add-in website to the SharePoint site through oAuth and use the client-side framework to talk to each other.
Imagine this scenario: You want to build a custom website, but would like to store data in SharePoint and use SharePoint to authenticate. This is a perfect scenario for Add-Ins. In fact, RePoint Technologies built our timesheet system this way. We built a custom website and made it a SharePoint Add-In. We log in through SharePoint to get to this custom website. And, this custom website stores data in SharePoint lists so we can take advantage of SharePoint workflows.
There are technically 2 types of Add-Ins for SharePoint:
- Provider Hosted – this means the Add-In website lives outside of SharePoint. For instance: you could host the site in Azure, Amazon Cloud, local servers, etc… SharePoint connects to this website through the oAuth techniques and allows the Add-In website to talk to SharePoint. The benefit of this is you can actually write server-side code on your server. You still have to use the client-side APIs to communicate with SharePoint. But, if you have a requirement to do server-side code, you can use the server to run it.
- SharePoint Hosted – this means the Add-In website actually lives within SharePoint. Technically, SharePoint creates a custom site collection for you to host the Add-In. The upside to this is that you don’t have to setup separate servers to host the website. The downside to this is you can only write client-side code. No server-side code is allowed with this technique.
In addition, there are a couple options when building the Add-In. One important one is called the App Part. This was “supposed” to be the way you write Web Parts when the Add-In model was introduced. It allows you to deploy an Add-In to the Web Part gallery so end users can add it to their page. In addition, it lets you build Web Part properties so end users can configure. At first glance, it looks like a great technique if you want a custom Web Part. But, if you look behind the scenes, it is just an iFrame. That’s right – since Add-Ins run in a separate site it has to show that separate site like it is part of the page. How do you do that? You use an iFrame. I hate iFrames. Why:
- Setting Width and Height is difficult – luckily SharePoint put a hook into this that allows us to programmatically set the width and height of the iFrame from the code in the Add-In. However, that doesn’t work all the time. Let’s say you are building an Accordion that changes heights dynamically. It’s not going to look smooth if you have to change the height programmatically after it finishes expanding. Basically, you have to really think through this issue if you want to use Add-Ins for App Parts.
- Performance – you are loading another webpage within your page. It takes time to load. Users are going to see it loading. There is no way around this. It will slow the overall load time of your page down.
- Deployment – The typical model for deploying an Add-In is to go to the App Catalog of your SharePoint instance and deploy the code. Then you go to the various sites in SharePoint and activate it (similar to a feature). This is really nice if you are deploying an “option” (i.e.: each owner of a site has an option to get the Add-In). But, what if you want to push out a global deployment of the Add-In (for instance: you want to globally push out the App Parts to an entire Intranet). You can’t do it! Add-Ins do have an option when you are building and deploying them to deploy globally. But, guess what – it won’t do it for the App Parts. That’s right, it’s even in the Microsoft documentation. That is one of the limitations. So, the only option is to manually activate the feature on all the sites and/or write a Powershell to do it. Also, you have to do this for any update (such as adding new parameters). It’s a pain.
When to use Add-Ins:
- You have a completely separate website you want to build with your own techniques and just need SharePoint for authentication, storage and other techniques that you can call to through the client-side API.
- You want to sell something on the Microsoft Office store as a third party
- You need to build a custom Web Part with properties and you have the following situation:
- SharePoint Online – so you can’t build a Farm Solution
- Can’t build a Sandboxed Solution because you don’t have the environment
- Can’t build a Sandboxed Solution because you need configurable parameters to the Web Part and don’t have the time to design your own, custom way to save properties
- Have a requirement that the Web Part must be reusable and must have properties. Otherwise we could use a simple Script Editor.
But, there is no way to package this up and deploy it.
Note: It is semi-possible to package up a Script Editor. You can actually write an Add-In purely to deploy Script Editor code. In fact, the Microsoft Patterns and Practices team have a whole article on how to do that. But, even if you do that, it doesn’t have any properties. So, there is no way to put custom properties on it.
When to use Script Editor:
Use when you want to write a single, non-reusable, component on a page. Great for a non-reusable Web Part. Something you want to write once for a requirement on a single page.
The SharePoint Framework (SPFx) is the newest way to build SharePoint Web Parts. This was built particularly for the Modern SharePoint site. It’s actually great. Developers can build client-side components that are packagable and can be deployed to a SharePoint site, just like classic Farm Web Parts use to be, or how SharePoint Add-Ins were supposed to work. In addition, Microsoft put a lot into the tooling around creating SPFx components. Microsoft is really pushing modern client-side development techniques like React and other modern frameworks. SPFx components can use all the client-side APIs to access SharePoint data. And, most importantly, SPFx runs in the current context and does not use iFrames! Thus, all the iFrame issues of SharePoint Add-Ins are gone.
SPFx components will work on the new modern SharePoint pages as well as classic pages. Basically, they are perfect for developing enterprise-wide, complex, custom Web Parts.
But, there is a catch – it’s difficult to do. The techniques used are very modern. Lots of command lines to setup projects. Using Gulp, Grunt, etc… It pushes newer client-side frameworks like React and Angular. Basically, all the stuff I love. However, not all developers are there yet. You really need to assess your development team before going down this path. I am finding that my clients are not setup to support this development. Most of my clients have .Net developers that maintain their environments. It’s hard to convince them to use this technique based on their skillsets.
When to use SPFx:
Use SPFx for all new Web Part development if you have a team that can support this modern type of client-side coding.