I have been using the SharePoint 2013 Client Components SDK for more than two years now to develop console apps against both SharePoint 2013 and SharePoint Online. This worked pretty well for me as then I could build a single console app that deploys solution assets to On-Prem Development environments and then deploy those same solution assets to Office 365 for integration, UAT, Staging, and Production environments.
As of September 2014, things changed! All of a sudden there were two SDKs, a “SharePoint 2013 Client Component SDK” and a “SharePoint Online Client Component SDK”. Both SDKs are named “sharepointclientcomponents_x64.msi” and sharepointclientcomponents_x86.msi” (x64 and x86 versions respectively for each SDK). I was about to think that these are the same SDKs, but targeted for the On-Prem/Online environments only. Then I looked at the file size and was confused…
Why are these files named exactly the same name and published exactly the same date, but are different sizes??? So I started digging to find the answer…
After some searching, I found out that the version numbers of the SharePoint 2013 Client Components SDK is version 15. This makes sense as this matches the version number of SharePoint 2013. The publish date indicated to me that this SDK included all the changes from SharePoint 2013 Service Pack 1. This is the same SDK I have been using all along for the past two years, but updated from Service Pack 1.
I also found out that the SharePoint Online Client Components SDK is version 16. This is the version number for the next version of SharePoint On-Prem (SharePoint 2016 presumably). At first I thought that was strange, but then after all the news and changes that Microsoft has been pumping out regarding the changes over the past year in Office 365 and the news that some (not all) of these changes will be pushed into the next On-Prem version, it started to make sense.
Here is what I think happened (only my perceptions from everything I could find out up to this point)…
SharePoint 2013 and SharePoint Online were using the same codebase (assemblies) up to the release of SharePoint 2013 Service Pack 1. From that point on, SharePoint Online’s codebase version changed to 16 to reflect the new development in SharePoint Online only as promised by Microsoft when they beat us with their “Cloud First” strategy message. The fact that the version number changed in SharePoint Online was first pointed out and documented by Gary Lapointe in his post “SharePoint 2013 Version 188.8.131.520???”: http://blog.falchionconsulting.com/index.php/2013/08/sharepoint-2013-version-16-0-0-1810.
So what does this mean for developers and SharePoint ALM???
Well, in general we can no longer use the same codebase to deploy solutions for both SharePoint On-Prem and Online as they are likely to never be the same again (with On-Prem always lagging by a major version number). Online development must start in a SharePoint Online development site and deployed/migrated to different tenants/site collections using the SharePoint Online Client Components SDK.
If we want to deploy the same codebase to both On-Prem and Online, then we will have to use the SharePoint 2013 Client Component SDK, but can not use any of the new capabilities of the Online version. After reading “Evolution of SharePoint”: http://blogs.office.com/2015/02/02/evolution-sharepoint, this now makes sense. Dan Holme did a great job explaining the news in detail on his post “The Evolution of Microsoft, SharePoint & Office 365”: http://www.itunity.com/article/evolution-sharepoint-office-365-856
Now if you do start with the SharePoint Online Client Component SDK and you want to target your solution to SharePoint 2013 (or vice versa), then you can follow “How do I run the Office 365 Developer Patterns and Practices against SharePoint 2013 On Premises”: https://github.com/OfficeDev/PnP/wiki/How-do-I-run-the-Office-365-Developer-Patterns-and-Practices-against-SharePoint-2013-On-Premises.
Microsoft is recommending that developers stop using SharePoint’s Feature framework and list, web, and site templates in their solutions. Now, instead of defining SharePoint content in CAML, Microsoft wants everyone to start creating content programmatically using the remote provisioning pattern.
PowerView vs. PowerPivot vs. Power BI…not to mention PowerPivot Models, Power BI Sites, Power Query, Power Map, Pivot Tables, Pivot Charts, Data Analysis Expressions (DAX) Language, Natural Language Search…
OK, I am lost!
Then I find out that some of these are in Excel 2010/2013, some are Add-Ins to Excel 2010/2013, some are in SQL Server Reporting Services 2012, some are in SharePoint 2010/2013, some will only work in SharePoint 2013, some are only in Office 365…ahh
What the hell Microsoft!!!
Finally an article that explains this in understandable terms…