Skip to content

Practical SharePoint Development for the Core Team and Beyond

If you’ve been reading my blog over the last several years you know that I’ve got a ton of technical posts including posts about both infrastructure issues (like claims, Kerberos, and performance) as well as development concerns. However, lately I’ve left the technical blog posts to some of my contemporaries. While I’ll occasionally blog (or log) my technical issues, their root causes and resolutions, I’ve been much more focused on the business and organizational issues of SharePoint. However, this post has to unify those views. Customers are coming to me and asking whether they should be doing SharePoint App development – and when. (Complicating the matters are that Microsoft has renamed SharePoint App development to Add-in development and has released another model for development for Office 365 applications.) While the answers are simple in some cases, they get complicated fast. However, there are answers to the questions.

In the Beginning

On the first day of SharePoint there was the SharePoint 2001 based on ASP (not ASP.NET) and it was not so good but we customized it to make it acceptable. On the second SharePoint Day we got SharePoint 2003 and the ability to use ASP.NET (and the SQL based file engine). It was good because we could customize it and add our .NET goodness to it. On the third SharePoint day we got SharePoint 2007 and the package solutions and it was too good. Suddenly everyone wanted to be able to develop their applications on the SharePoint platform. As a result many of the support calls Microsoft received were because of poorly performing code that customers had written. On the fourth SharePoint day we got SharePoint 2010 complete with its Sandbox for code we didn’t trust. The problem with this is that while it worked for corporations who had rogue development organizations internally that weren’t controlled by corporate IT, it didn’t work at the scale of the cloud. There were some things which couldn’t be protected against. On the fifth day of SharePoint we got SharePoint 2013 and the brand new model of development – Apps. From a hosting perspective, Apps are great. No code ever runs on the server and therefore it’s not possible for applications to bring down the server. (Again, Microsoft recently renamed this type of development to Add-ins.)

All would be good if Sandbox solutions and Apps could use the same skills the developers already had, the same coding styles, and could solve all the same problems. The problem is that this isn’t the case. Sandbox solutions had a set of limitations based on how they were implemented. For instance, you couldn’t access the page object to include script you needed. Apps are substantially different than solutions development – either full trust or sandbox. And that’s where the rub comes in.

Smart car or Semi-trailer Tractor

The problem is that the SharePoint solutions were a Semi-trailer Tractor. You could do anything with them. You can pull along branding, custom solutions, recurring timer jobs, configuration, etc. However, if someone fell asleep at the wheel it caused a multitude of problems from performance to stability and even in some cases data integrity. That’s why the Sandbox solution was designed. What if we could get folks into a big pickup truck? They couldn’t carry as much, they wouldn’t be able to do as much – but at least if they fell asleep at the wheel – or if they were malicious – they couldn’t do as much damage. The problem is that the available damage wasn’t tolerable at scale.

On the other end of the spectrum is something like a Smart car. When I see them on the street I tend to comment that there goes half a car. They’re efficient, small, and are quite capable of transporting two human beings from one location to another. Federal census data from 2009 indicates that 76% of American workers drive to work alone. If 3/4ths of the time you don’t need to have any passengers – let alone carry cargo, why would you drive around a big Semi Tractor and Trailer?

The way that you drive a Semi-tractor trailer is different than the way that you drive a half a car.


The car to semi analogy breaks down when we start to think about how they’re actually technically different. Certainly the capabilities are different and they’re optimized for different things. When used for what they’re designed for they’re both great answers. However, in that analogy both drive fundamentally the same way. There’s a steering wheel, gas, and a break. The Semi might have manual shifting and the Smart car an automatic transmission but fundamentally they behave the same. However, the way that Apps (and Add-ins) are designed and the way that traditional solutions were designed are substantially different.

Consider that there are two ways to balance a budget. One way is to increase your income from another job, a second job, or working more hours. The other way is to downsize your house, replace your car with a less expensive solution, cut out cable, and eat less expensively. Which approach is right? Both. They’re just two sides of the same coin. Both of these aren’t really equal, however, because it takes a disproportionate change in income compared to the same reduction in expenses. Said more plainly you have to change your income more dramatically than the same amount of savings. Why? Because of taxes and other ways that making more money doesn’t return 100% of the gain to your bottom-line budget.

Help Your SharePoint User

Apps are a similar situation. There are some great new benefits but they come at a cost and they create new limitations.


Apps are more difficult to write. Full stop. They are. Both remaining paths to writing apps are. Some of that is due to skills and tooling but some of it is inherent in the additional complexity of Apps. Apps fundamentally come in two categories. The first category is a provider hosted which are hosted on another server somewhere and SharePoint just communicates with the other server. The second category is a SharePoint hosted application which is all client side scripting (JavaScript.)

Provider hosted applications can be built in whatever technology you want so in that sense there aren’t new skills to learn to build the application. However, the challenges exist in managing the communication with SharePoint which requires a deeper knowledge of Public Key Infrastructure (PKI), certificates, encryption, and identity management than most developers (SharePoint or not) have.

SharePoint hosted applications must be built with client scripting technologies – which effectively means JavaScript. Unfortunately, working in JavaScript is much slower and more difficult than working in a traditional server compiled language. The very dynamic nature of JavaScript means that it’s difficult to check for syntactic errors at compile time and so even seasoned developers find themselves spending more time debugging code than normal.

Somewhere around here I fully expect folks to tell me that developing in JavaScript is just as easy as developing in C# or that they’re as efficient at JavaScript as they are with a compiled language. I appreciate they believe this, however, the research and data as well as my personal observations don’t bear this out to be truth.


SharePoint is a portal platform. Though portal was dropped from the name many editions ago, it remains a product that’s designed to bring resources from disparate sources together. On the super easy side this is done by placing links on the SharePoint page to the other applications that users need. However, in many cases this isn’t sufficient to get the kind of view that users need of their environment. In the past SharePoint web parts have been the windows to the information stored in other systems. Some amount of code would fetch information from a back end system and display it on a page. Several different web parts could be added to retrieve data from multiple back end systems. That’s great but it required code running on the server.

In the App world where this is no longer an option, you can’t directly fetch the information and add it to the page on the server. You can use client-side techniques to inject that content into the page but this has potential side effects. Or you can use technology we tried to eradicate in the 1990s – that is the humble IFRAME. IFRAMES are inline frames and have been a part of HTML for a long time. IFRAMEs have their own set of issues when used in a portal including communication between the host page and the IFRAME content, getting the consistency of look and feel, etc. Look and feel is interesting because IFRAMEs are outside of the processing for CSS and styles that are applied so it’s necessary to get the CSS into the IFRAME.

SharePoint App Parts are designed to handle some of these challenges including providing to the application the CSS used at the server. However, the problem of messaging to the host page of an app part isn’t fully resolved by the framework. As a result for dashboards and other situations where multiple parts on the page need to communicate and react to each other – like our old web part connections – App parts are problematic.

For provider hosted applications, you also have to make sure that the applications are accessible to the user wherever they are. If you’re hosting your own applications and users access SharePoint from outside your network – you’ll have to make the applications available.


What benefits to Apps offer? Besides the obvious advantage of not having untrusted code running on the server, there’s the advantage of being able to develop in any language you want. Sure there may not be a pre-made Python or Ruby library for connecting to SharePoint as an application but it’s technically possible to do. If you’ve got an army of developers who write in Java and need applications to plug into SharePoint, Apps are the way to go.

If you’ve got a Java based system that you need to connect to and you have developers that understand that system the effort to make the app work in SharePoint may be less effort than trying to teach .NET SharePoint developers how to access the data and functionality in the Java system.

Which Way Do You Go?

Right now if you want to use office 365 you have to write a Sandboxed Solution or an App. Microsoft has said that the sandbox will be deprecated from Office 365 “soon” so it’s not an area to make further investments in. However, all of these statements apply to Office 365. If you’re going to be running SharePoint on premises then you can use full trust solutions, sandbox solutions, or Apps. So when you’re in an on premises environment it doesn’t matter which way you go. Leverage apps where you need to get cross-platform support.

Complicating this are Office 365 Apps which only work on Office 365 but provide a unified API across the Office 365 services. If you’re doing Office 365 these Apps are fundamentally similar in technology to SharePoint Apps – or add-ins – but use different APIs and are published differently. They’re published into the Azure AD that backs Office 365.

Complicating Factors

One of the complicating factors for deciding to develop Apps is that the application lifecycle management doesn’t really work. For SharePoint Apps (Add-Ins) you can’t migrate the configuration and data from environment to environment with Apps enabled. You have to reconfigure the apps in each environment. This can be problematic no matter how you manage your configuration. For provider hosted applications there’s the added issue that you compile an App package and it has a fixed URL endpoint so all of your SharePoint environments will point to one target provider application – in development, quality assurance, and production environments.

The work around to this is to leverage a build server that creates separate packages for each environment on the SharePoint site. However, this is more sophisticated than most software development organizations I’ve seen.

Office 365 Apps have some tricks that can be done with Azure hosted apps and deployment slots that allow you some level of control over which environments point to which versions of the App. However, these controls are still relatively minimal.

So basically this creates a fork in the road. If you’re going to be on premises you’ll want to continue full trust code. If you’re on Office 365 you’ll want to create Office 365 applications. If you’re walking the fence you may want to deliver SharePoint Add-ins that can run both on premises as well as in Office 365 – but this is a somewhat unique case – that I wouldn’t generally recommend.

1 Comment

  1. From where SharePoint development was with the release of 2007 to today, I don’t see how the story could have possibly got any more convoluted.

    I wonder if anyone who cares about SharePoint (Microsoft, customers, consultants, ISVs) will ever be able to look back on the journey and say it ended in a better dev story (and more importantly, a net increase in business problems being solved for SharePoint customers) than what has been available with full trust code since 2007? Right now, its really hard to see how that could happen.

    Stepping back from it all, it seems like a classic case of “wanting to have your cake and eat it to”. Microsoft 1) wants to have Office 365 as a platform that customers and partners can extend to solve all kinds of business problems (which increases the platform’s desirability and value in the marketplace) and 2) wants the same enthusiasm for this from developers\consultants\ISVs as was experienced in the heyday of full trust code\farm solutions.

    Right now it is hard to see how they are going to be able to have both. Meanwhile, confusion and complexity reigns in the SharePoint dev world, as compared to the state of affairs a few years ago.

    Excellent analysis and guidance, Rob!

    Jeff Cate
    PremierPoint Solutions (formerly SharePoint Solutions)

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share this: