So what exactly is SPMeta2 doing? Fiddler comes to the rescue.

It’s definitely possible to understand XML in requests send by CSOM to the server. But in this example I’ll use CSOM inspector fiddler extension that makes it a bit easier.

Just to remind what we try to accomplish:

  • create site column SPMeta2_field,
  • create content type SPMeta2 content type,
  • create list SPMeta2 list,
  • add SPMeta2_field to SPMeta2 content type,
  • add SPMeta2 content type to SPMeta2 list.

Executed requests

  1. Loads Site.ServerRelativeUrl and Web.ServerRelativeUrl.
  2. Loads field by GUID (it was required) using ExceptionHandlingScope.
  3. Loads field by internal name using ExceptionHandlingScope. I must say it’s clever to fallback to internal name. Still no need to use 2 separate calls for that.
  4. Creates field and set its properties.
  5. Load content type by CTID using LoadQuery. I don’t even need to look at the code to see how inconsistent it is.
  6. Creates content type and set its properties.
  7. Sets some more content type properties and update. Could’ve been done in previous call.
  8. This is where fun begins. It gets content type by CTID (again), but doesn’t actually call Load method. This call is completely pointless.
  9. Gets the same content type AGAIN. This time Load is executed, but it doesn’t change the fact, it was just created, so there’s no need to load it at all.
  10. Gets the field by ID without calling Load.
  11. Gets the same field AGAIN, with Load this time. Yeah the field that was created and doesn’t need to be loaded.
  12. Adds field link to content type and calls Update() on it.
  13. Calls update on the same content type AGAIN. Because reasons.
  14. Loads Web.ServerRelativeUrl and Web.Url. One is already loaded, another could be in call 1.
  15. Loads Web.ServerRelativeUrl and Web.Url. Yes. AGAIN.
  16. Gets list by Url using ExceptionHandlingScope.
  17. Creates list and sets its properties.
  18. Gets root folder of the list.
  19. Loads all items form property bag of the root folder. This will not be used anywhere.
  20. Gets list by ID. Yes the list that was already loaded. Loads all properties, that will never be used.
  21. Sets properties of the list and updates. This could’ve been done in step 17.
  22. Gets root folder of the list again. Loads properties like ItemCount which is required for what exactly?
  23. Loads all items form property bag pf the root folder. AGAIN. Seriously? There is absolutely NOTHING relevant to provisioning there.
  24. Loads list and all it’s properties, again…
  25. Loads list and all it’s properties. Yes again. Only difference between those two is correlation id.
  26. Calls update on list and web. And it didn’t even use those list properties…

I’m glad it’s finally over. And I think I could stop there, but I feel like 26 deserves more attention.

Only thing happening here is Update on list and web. This shows that SPMeta2 developers lack knowledge of how CSOM works. SPWeb and SPList objects on the server are not cached or in any way persevered between calls. That means fresh instances of those objects are actually retrieved from the database, no changes are applied and empty Update is executed. It’s not only pointless, it’s a waste of every resource along the way.

How to do it better

Knowing what went wrong we can do better. That’s the subject of next post.