Upgrading full trust solutions from SharePoint 2013 to SharePoint 2016 (still in beta)
Background
During preparations for all our full trust products to support SharePoint 2016, I came across a few gotcha moments.I must say, the vast majority of things just worked as is on SP2016 without any need for change in our code or packaging from SharePoint 2013.
Even the fact that the layouts URL is still _layouts/15 and not _layouts/16 didn't seem to fool our code, since we noticed O365 is running 16 version but still uses /15 in its URL path.
That said, we did have a couple of issues and these are things you can do today in your code to make sure you are ready for SP2016 upgrade.
Also, although it is a bit early to know for sure, but SharePoint 2016 really feels more like an update than an upgrade. Packing a lot of usability enhancements and UX enhancements, at the very core it looks and feels like SharePoint 2013 with many enhancements, which in my book is way better than re-writing the entire UI from scratch every time, don't you agree?
Anyway, here is a short list of things that we did need to change in our package:
Changes needed
Beware of non-API JavaScript functions
Like many other good SharePoint developers, we are, too, lazy in our core. Being a lazy developer is a good thing since you always try to use, reuse and recycle what the environment gives you before trying to write it yourself.
However, I have noticed many functions that were available as part of SharePoint core, init or other JavaScript files are now missing in SP2016. Probably, due to some sort of cleanup process done by the SharePoint team on functions that were no longer being used by the product itself.
For instance, many SharePoint examples on how to get the selected items in a SharePoint list view had the following code:
var selection = SP.ListOperation.Selection.getSelectedItems(context);CountDictionary was a function defined in inplview.js however this function is no longer available in SP2016.
if (CountDictionary(selection) > 0)
As a general rule of thumb, MS does not recommend you rely on any JavaScript function that is not under the "SP" namespace, as they are not intended to be a part of the product's public API. In other words, if it does not start with "SP.*" don't use it.
For this specific example, it is safe to just check the selection.length since getSelectedItems seems to return an array.
SharePoint Versioned Paths
This one is tricky. Make sure you got your code logic right on this one.
When using any path under _layout, SharePoint 2016, v16, uses _layouts/15. The Same path as SharePoint 2013, v15.
But, when probing for files on the SharePoint root folder, SharePoint 2016 uses the 16 sub folder, not the 15.
In our logic, we check if the SharePoint version is 15 or greater, use _layouts/15 and as for the file system - we recommend you use the Microsoft.SharePoint.Utilities.SPUtility.GetVersionedGenericSetupPath API to get the correct folder.
If your code needs to be compatible with SharePoint 2010 and the above method is not available in the API, use reflection to call it. Here is a code example:
try {
var method = typeof(Microsoft.SharePoint.Utilities.SPUtility).GetMethod("GetVersionedGenericSetupPath");if (method != null) {//does not exist in sp2010var result = method.Invoke(null, new object[] { folderPath, Constants.SharePointConstantsBase.SP_Version }) as string;if (!string.IsNullOrEmpty(result)) return result;}}catch { /*handle code in case function is not availalbe*/
return SPUtility.GetGenericSetupPath(folderPath);}
Top bar changed its name
If you are planning to hide or manipulate the top bar area, this is perhaps one of the most noticeable changes in SharePoint 2016. In your code, if you have referenced it using document.getElementById("suiteBar") you will now need to check if it does not exist, look for it with its new ID: document.getElementById("suiteBarDelta")
Our custom master page crashed
This one, I am not sure why did it happen or what technically has changed. But, our custom master page that we use for some settings pages crashed on SharePoint 2016. The fix was hard to find, but simple to implement. For some reason, it would not work unless we added this code to the top of the master page:
<%@Master language="C#"%>You will see this is added to the SharePoint OOB master pages as well.
User Profiles and other services
Needless to say, if your product rely on some other SharePoint farm service like the user profile - you will probably need to redo these parts and fit them to SharePoint 2016. I noticed a few differences in the API for the user profile service, as well as a change in the DataBase schema in case you were probing that as well.
Client side OM
As for CSOM, it is pretty safe to say everything from SP2013 works on SP2016, with more things supported on 2016. I will write another post going from O365 apps and making them work on SP2013 which will cover some CSOM gaps you might notice going the other way around, but moving forward (upgrading) I didn't encounter any code to stop working, except for more heavy throttling being done on O365.
I hope this post helps, feel free to leave comments below
