Second Life of a Hungarian SharePoint Geek

May 25, 2011

Using Visual Studio Watch window to discover managed client object model internals

Filed under: Managed Client OM, SP 2010, Visual Studio — Tags: , , — Peter Holpar @ 18:01

In my former post I wrote about using Fiddler to analyze the network traffic generated by the client object model. Although personally I think it is a great way to discover the object model internal working, there are tools that many of .NET developers are more familiar with, for example, Visual Studio itself.

The Watch window in Visual Studio a useful tool to look into the details of objects, especially as it allows you to check the values of non-public class members as well as public ones.

In this post I show you some of the objects / properties I suggest you to watch when you would like to have a deeper knowledge about the client OM.

For the example I use one of the simple codes used in the previous post (of course, you should replace the URL before running the code):

  1. ClientContext clientContext =
  2.   new ClientContext("http://pholparlaptop");
  3. Web web = clientContext.Web;
  4. ListCollection lists = web.Lists;
  5. List list = lists.GetByTitle("Links");
  6. clientContext.ExecuteQuery();

Put a breakpoint to the first line, then start debugging the application.

When the execution is stopped at the breakpoint, add the following items to the Watch window:

  • clientContext
  • clientContext.ObjectPaths
  • clientContext.PendingRequest.Actions
  • list.Path

Then step through the code line by line and see how the values are changing.

In the clientContext you can see (among others) the version on the OM, the application name, the timeout value (in milliseconds), and a single static object, that is the RequestContext (Microsoft.SharePoint.SPContext). As we have learnt that is sent as a standard part of each request.


As you step through the code you can see how the number of items in the clientContext.ObjectPaths generic Dictionary and clientContext.PendingRequest.Actions generic List changes. Usually as you refer new objects in the code, a new item is created for both. This way the context aggregates what it should do and with which objects on execution. The figures below show the state just before calling the ExecuteQuery method.



After ExecuteQuery has finished, the clientContext.PendingRequest.Actions list is reset, as there are no more pending actions for the current context.

There is an other change either after query execution (see below), that the last item of the ObjectPaths is changed from ObjectPathMethod to ObjectPathIdentity. Remember, that in Fiddler it was an action of ObjectIdentityQuery (it is Microsoft.SharePoint.Client.ObjectIdentityQuery as shown in the Watch window above for the last item of clientContext.PendingRequest.Actions) that referred to a Method subnode of ObjectPaths (related .NET class is Microsoft.SharePoint.Client.ObjectPathMethod as displayed in the Watch window above for the last item of clientContext.ObjectPaths).


The next screenshot illustrates that the relation between the actions and object paths we observed in Fiddler is reflected in the object hierarchy as well. The key for the relation is the Path property of the action that refers to the object path.


The image bellow shows some useful information observable in the Watch window. This time the static root object (m_parentId = –1, Parent = null) is displayed. Note the non-public m_propertyName and m_typeId properties having the same values we saw in the former post.


And the next one is for a standard ObjectPathProperty. See the non-public m_PropertyName with value “Web”, and the m_ParentId = 1. It means the object path refers to the Web property of the root context.


The next two figures show the response, the “standalone” ObjectPathIdentity object (m_parentId = –1, Parent = null)created on successful query execution. Note the Identity property that refers the list using the canonical ID.

The first screenshot has been taken from clientContext.ObjectPaths dictionary (note the item has an index of 3), while the second one is from a direct “addressing” the same item from the Dictionary by adding clientContext.ObjectPaths[3] to the watched names.

In fact, if you happen to use an index that refers to an ID that does not exist in the object paths (like clientContext.ObjectPaths[2]), an exception of type ‘System.Collections.Generic.KeyNotFoundException’   is thrown, although there is an item having index 2 in the clientContext.ObjectPaths watch. It is due to a general Dictionary behavior, not a client OM specific one, but you should be aware of this. The reason for it is that the Key of the dictionary is the Id property of the Value.



Now compare this values to the ones you can see for list.Path. The Path property is the same as above. It means the result is loaded to the list object.


In the next post I plan to dig even deeper describing the internal working of the client OM (both client and server side). This knowledge will help us to do some really fancy things using the framework provided by the managed client object model infrastructure.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: