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 184.108.40.2060???”: 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.
A great article on where we are heading with Office 365 & SharePoint 2016…
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.
I was trying to create a failover cluster in Windows Server 2012 R2 (Creating a Windows Server 2012 R2 Failover Cluster using StarWind iSCSI SAN v8) and I ran the “Validate Configuration…”. Once validation was complete, the validation report gave me the Error:
Two disks have been found on node node1 that cannot be distinguished from one another. The disks involved have disk signature <Signature>, SCSI page 83h VPD descriptor <GUID>, SCSI page 80h VPD Serial Number <Serial Number>. Please verify the storage configuration. You must either mask (unpresent, detach) one of these LUNs at this node, or, run validation and specify a disk list that includes only one of these disks, for example by using the Test-Cluster cmdlet in Windows PowerShell
After searching all over, I finally found an article that pointed me in the right direction:
Windows Server 2012 / 2008R2 with iSCSI error 80 or 83 VPD[http://culmor.blogspot.com/2013/03/windows-server-2012-2008r2-with-iscsi.html]
This article didn’t have my fix, but it did state that “The error probably relates to your MPIO configuration”. That’s when I found two listings in my iSCSI Initiator’s Favorite Targets screen. I removed one of the listings and bam!…Error gone.
The issue for me turned out to be that I had multiple virtual adapters (vNICs) that pointed to the SAN provider. By removing one of them, it removed the duplicate SAN devices.