A Comparison of the Core CSOM Classes and Microsoft.SharePoint in the Sandbox

The Gaps in the Apps

 

I’m already starting to see conversations here and there about sandboxed solutions versus the new Apps model in terms of capability. I spent today drilling into both the core Microsoft.SharePoint namespace in sandboxed mode and the CSOM equivalent, Microsoft.SharePoint.Client. I started by writing a simple console application that used reflection to give me the public types and their members in both namespaces. Then I pulled that data into a database and started crunching it to see what I could learn.

In the server-side namespace there are 214 public classes and enums. In this portion of the CSOM namespace there are 289 public classes and enums. As I looked a little closer I realized that the organization of the two models is different. One reason the CSOM namespace has more members is because some of the members are located in other namespaces in the server-side object model. Also, CSOM includes many classes intended for use by apps and sandbox naturally lacks these.

Before I go any further I want to make sure I point out that I am only comparing the core namespaces in this post. CSOM is far larger than sandbox because it supports most of the SharePoint Server features whereas sandbox only supports SharePoint Foundation. Furthermore, CSOM has much UI functionality and the sandbox has very little.

Since the namespaces are organized a bit differently, I decided to focus only on those classes that exist in both namespaces. It turns out that there is much less overlap than I expected. There are only 96 classes and enums in common between the two models. However, those 96 classes include those for webs, lists, list items, content types, fields, and queries.

In the SharePoint 2013 Preview – Apps or Crapps? post I asserted that a key factor in a developer’s decision to use CSOM will be the ability to rewrite traditional server-side code with CSOM. To this end, I believe it is critical that there be parity between the server side OM and CSOM for the core classes. Therefore my next step was to compare the members of the overlapping classes to identify properties and methods. In the server OM the 96 classes I analyzed contained a total of 6,856 public properties and methods. In CSOM the corresponding classes have a total of 5,086 public properties and methods. The server side implementation of these classes contains 1,770 more public properties and methods than the CSOM equivalents. Of course CSOM has many properties and methods not found in the server OM. Unfortunately, for the analyzed classes I found 3,984 members in the server OM without analogs in CSOM.

Note: If a property is missing in CSOM it typically counts as two members in my analysis because reflection emits a get_property and a set_property. The doubling of properties in the count makes the gap look bigger than it really is.

It’s what’s behind the numbers that matters

Some of the gaps I identified in the core objects are simply a result of different conventions between the two models. I also assume that they took the opportunity to remove deprecated or out of date members. Unfortunately, for the most part the difference is because the core CSOM classes as they exist in the preview are far less powerful than they must be if Microsoft expects corporate developers to adopt this model.

Microsoft has a lot of work to do between this preview and the final release.

Download the findings and see for yourself

You can download a spreadsheet with the final data from here: http://www.elumenotion.com/Downloads/CSOM%20Gaps.xlsx. The workbook contains two spreadsheets. The first shows my mapping between the two namespaces and the second lists the members that don’t have obvious equivalents in CSOM.

Why this is important

It seems unsurprising to me that the gaps I have identified exist as most of them are related to provisioning and configuration. This is the oldest portion of CSOM and it was developed during a cycle when Microsoft was encouraging the use of sandboxed solutions. Sandboxed (and farm) solutions can execute feature event receivers to do this work. Apps require the use of remote event receivers to do the setup you can’t pull off with CAML. Remote event receivers can only use CSOM and these gaps must be narrowed if not closed completely for Apps to be viable for a broad range of typical corporate SharePoint solutions.

I still believe CSOM is awesome

… but it is clearly incomplete. When you look at the spreadsheet you might be inclined to reject the model, but I think that would be a mistake. This is the last post I plan to write for this build concerning the gaps in the apps. From here on out I will be covering JavaScript and CSOM on the UI side. I believe the story there is much more satisfying and is extremely compelling.

 

Author: Doug Ware