Tuesday, 17 March 2015

SharePoint Development

Most code examples have been used with SharePoint 2013


SharePoint is a great platform.   But there are times when you need to add additional functionality, such as:

  • Custom pages that display data in a different way to normal SharePoint pages
  • Custom forms that manipulate data in a different way to a normal SharePoint form - eg some fields read-only
  • Interface SharePoint data to other systems, eg sync or push/pull with an external data source
  • Etc

There are many ways this can be done, including

  • Develop SharePoint app using the SharePoint app module.
  • Develop ASP.NET pages that interface with SharePoint
  • Use external .NET tools, eg PowerShell to manipulate SharePoint data
  • Use the SharePoint web services

These have various pros and cons

SharePoint Apps

Admittedly I haven't investigated SharePoint App development under SharePoint 2013 much, but I have developed apps for earlier versions of SharePoint.

  • App development was complicated, needed complex (And picky) templates and config files
  • You needed to have SharePoint on the development machine (or develop on the SharePoint machine)
  • Deploying the app to the GAC folder meant you had to mess with the SharePoint .config and security settings
  • But you could integrate nicely into a webpart, and use the SharePoint style configuration controls  and configuration storage.

I know with SP2013 there are more ways to develop webpart apps, and the deployment is different - but have not tried this.  I guess I ought to when I get the time.

ASP.NET pages to extend SharePoint
This is a relatively easy way to add functionality to SharePoint whilst retaining some of the look and feel (eg topbar / quicklaunch) of SharePoint.

The main catch is that the pages have to run on/from the same server as the SharePoint system in order to access the SharePoint object model.  For this reason the same issue applies as above about debugging, you can't debug the code unless you have SharePoint and visual studio on the same machine.  (Actually, I believe it can be done, but I haven't tried it don't know the implications)


PowerShell scripts to manipulate SharePoint data
PowerShell can interface to SharePoint and access SharePoint list data.

The script needs to run on the SharePoint server, but apart from that, this is a fairly easy way into simple access to SP data.

SharePoint Web Services

SharePoint ships with web services that can be used by an external system to access and update the SharePoint data.

These use a combination of SOAP, CAML and XML to request data and transfer results.

They can be called from a range of systems, including JavaScript (with or without Jquery), external program on another computer, PowerShell script on another computer,  ASP.NET application on another computer etc.

The big advantage of the web services is that they do not need to run on the same server as SharePoint itself, and are therefore much more flexible in where they can be used. 


The big disadvantage is that they are not easy to use, picky about syntax and often poorly documented (at least that was the case when I started using them under SP 2010)

No comments:

Post a Comment