Many years ago, in a previous role, I opted to join the consultancy team, specifically to work with a new product due to come out at some point in 2001. At the time, it was available to those that worked directly with Microsoft on projects. I was working at the Microsoft campus in Reading, UK, and for the project I was on got access to nightly builds which would become SharePoint Portal Server 2001, as that project expanded I got to do the same for SharePoint 2003 as well. I would install and test it, repeating that cycle almost daily. Back then I had no idea that I would still be working with SharePoint 16 years later. I am sure there are many of us that feel the same way.
Now one thing back then that was much harder was learning how to develop against the product, what was the right way, what should not be done and more importantly how to actually make it all work correctly. In reality we are 16 years on and I still see this issue, walking into clients trying to understand, why something was designed, coded and deployed in a specific way. Though we have better documentation in some areas, the issue still comes down to that people will build solutions in the way they know, not necessarily in the way that it should now be done.
SharePoint 2016 and SharePoint Online have now changed sufficiently that designing applications, more than ever need to be done the prescribed way. No longer can we really just hack something in and hope it will works. The approved ways of building solutions are down to the environment you are deploying into and of course if you want it cloud ready. For me there are five different approaches you can use that will cover SharePoint On-premises and Online. You will notice however there are six listed below, the sixth being the SharePoint Framework, which right now is only within Office 365.
As you look at these options, you can see we have many ways of building solutions. There are different pros and cons for each depending which route you take. For example, Full Trust is not allowed within SharePoint Online, so that option cannot be used for an Office 365 solution. The following table outlines what is supported and what is not.
The last option I call “Hacking” it not true hacking but what a lot of people do my using JavaScript injection. By using a JavaScript framework, and modifying effectively the DOM you are hacking the way that SharePoint works, whether using a Content Editor or Script Editor web part. Now one thing that does work well though is using a version of ES (ECMA Script) to utilize the new approaches of module based client side development, to override default web parts and have them utilize the REST API components for both SharePoint On-premises and Online. This will prepare you for building solutions using the SharePoint Framework. You can read a couple of posts I already put out there on this very subject.
- http://sharepointpromag.com/sharepoint/notes-field-sharepoint-framework
- http://sharepointpromag.com/sql-server/notes-field-office-365-and-content-delivery-network-cdn
There are still limitations though for the types of solutions you build that still require full trust code, for example a custom Membership and Role Provider for authentication or a custom Claims Provider cannot only be done using full trust code.
The lesson here is to select the approach carefully looking at what will work both On-premises and Online, as well as being future proof to some extent. Do not just build the way you know, as that may be the wrong decision long term. Take the time to learn something new!!
At IT/DEV Connections within the Enterprise Collaboration track, we are taking this subject seriously. Knowing how to build solutions whether using the existing approaches you know, or using some of the client side frameworks such as Angular or the new SharePoint Framework we have you covered. We will take you on a journey of creating applications, branding applications and enhancing them with client side components and code to ensure they work both On-premises and within the Cloud.
