Overview
From the perspective of “full trust” SharePoint Web Parts (vs. Apps) there are no required changes for SharePoint 2016 vs. SharePoint 2013, but there are some key points to be aware of:
- The default SharePoint 2016 Master Pages have changed how they set the document mode.
- SharePoint 2016 is currently only compatible with Windows Server 2012 R2 (Standard or DataCenter editions) and with either SQL Server 2014 SP1 or SQL Server 2016
- Installation no longer directly supports installing on a single server as part of the installation options. One example is http://sharepoint-tutorial.net/page/install-sharepoint-2016.aspx
- The stsadm command line utility (required for installation of the QueryVision Web Parts) can be found here for SP 2016:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN
Installation Changes
SharePoint Server 2016 doesn’t support the standalone install option, so it is no longer available in the setup program. Use the MinRole feature during installation and choose one of the available install options. The Single Server Farm option where everything is installed on the same computer is supported for dev/test/demo purposes. When you use this option, you must install SQL Server yourself and then run the SharePoint Server 2016 farm configuration wizard.. For more information, see “MinRole farm topology” in New and improved features in SharePoint Server 2016.
Master Page/X-UA-Compatible changes
If your organization sets the x-ua-compatible mode for your Master Pages, then the following is an important change to understand.
For SharePoint 2016 – which also applies the SharePoint 2013 Nov 2015 Cumulative Update (CU) or later – Master Pages can set the default “document mode”. While the recommended (and default) document mode setting via x-ua-compatible mode remains IE=10, how this is done has changed.
Prior to the Nov 2015 CU change for SP 2010 and SP 2013, the Master Page would include the following header meta tag:
<meta http-equiv=”X-UA-Compatible” content = “IE=x>
Where “x” would be “8” for SharePoint 2010 or “10” for SharePoint 2013/2016.
This has been replaced with the following header entry, in the same location/order in the header for the Master Page definition:
<SharePoint:IECompatibleMetaTag runat=”server” />
When the page is executed, this will be replaced by:
<meta http-equiv=”X-UA-Compatible” content = “IE=x”>
So that if you examine the page in the Browser debug view of the source code after running the page, that is what you will see.
Come key points:
- Microsoft has not published where the value of the IECompatibleMetaTag value (presumably IE=IE10 for SP 2016) is stored.
- If a line with the following is placed a head of the IECompatibleMetaTag line in the Master Page – for example:
<meta http-equiv=”X-UA-Compatible” content = “IE=edge”>
<SharePoint:IECompatibleMetaTag runat=”server” />
Then the result once the page is run will be the following:
<meta http-equiv=”X-UA-Compatible” content = “IE=edge”>
<meta http-equiv=”X-UA-Compatible” content = “IE=10”>
As the rule for x-ua-compatible is that the first line with the metatag is used and any following lines are ignored, so the second line (“IE=10”) will be ignored, effectively overriding the SharePoint:IECompatibleMetaTag line in the Master Page