Archive | Client Object Model RSS for this section

Why WPF makes sense using the ClientOM where SilverLight might not

First off, I’m not jumping to conculsions. Sometimes WPF will make more sense that SilverLight.

While WPF can run on the server and use the SharePoint DLLs and full OM, it can also be delivered to the desktop. Desktop WPF apps cannot use the SharePoint DLLs. Thus, bring in the SharePoint Client Object Model. So, you can have Silverlight pretty, but WinForms functionality, all in one.

So here are some advantages of using a WPF client.

  • It’s synchronous programming
  • No cross site scripting (XSS) issues

So how about a quick example?

Here’s the xaml

Here’s the most basic code. Notice how much less code there is in the WPF example than in the Silverlight example!

Here’s the output on my sample site


The referenced assembly “Microsoft.SharePoint.Client.Runtime, …” could not be resolved…

You may see this error when you compile

The referenced assembly “Microsoft.SharePoint.Client.Runtime, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL” could not be resolved because it has a dependency on “System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” which is not in the currently targeted framework “.NETFramework,Version=v4.0,Profile=Client”.


Go into the project settings. They are probably set to .NET 4.0 Framework. In order to use the ClientOM, set them the Framework to 3.5. The project will be unloaded and reloaded, so be sure to save your work before going into the properties canvas.

Next time you build an application intending to use the ClientOM, set the .NET Framework to 3.5 when creating the project.

Using the SharePoint ClientOM for Silverlight to populate SP list data into a SL DataGrid

We’ll go over the code/projecct in a future post.

So this one is a bit complicated. I set out to do display an entire list in a data grid. But not a fixed list. Not a subset of data. It was the WHOLE list. ANY list.

First, we want to create a grid that will display all lists, and all columns within those lists. That way the user can see all the lists and get an idea as to what columns are in each one, without loading the whole list.

Here’s what we’re after.

Notice the size of that horizontal scrollbar? It’s small (thus the list is wide) and the only column on the right is “fields”. These lists have a lot of hidden fields. For the first round, we’ll show all of them. You’ll see how to show just the visible ones if you wish to do so.

Next, we want to show all items in any particular list, with the content data in a grid form.

This is difficult, because each list has a different schema. We’re not out to show just the fields they all have in common or just a subset like Title and Author. We’re out to show all of the data for each list! And we want it all in a nice grid with scrollbars.

To use the DataGrid, we need to set its ItemSource property. To do so, we must have an object that implements IEnumerable. The best way to do this is to use a ListArray. We can iterate thru each list, grab the data, and stuff it into an object. We’ll then add our object to the ListArray.

Do you see the problem we have? To implement IEnumerable, we need a class. But each list has a different structure. Now, we could go thru each field of every list and try to come up with an uber class. Chances are, we’d miss something. And that’s not to mention custom lists. We’d like to have everything.

So, the first thing I tried was a class with two properties, a Title and an array. The array contained the lists’ fields. No luck. When I set the ItemSource, it treated the Array as an object and gave me “garbage.”

So the second thing I tried was a class where I dynamically add properties. I couldn’t figure that out. Maybe someone smarter than I could figure that out. As far as I can tell, you can’t modify a class that was compiled at design-time.

So finally I thought I might be able to dynamically create an entire class, and obviously creating the properties for each type of list. Creating a class at run-time wasn’t that difficult. And it worked!

So we now have a grid that changes with each list schema. Beautiful!!

So here is the result.

Notice the Style Library view is different than the tasks view.

Style Library:


A very basic SilverLight app using SharePoint ClientOM (Client Object Model)

First off, you are going to create a XAP file, just like any other SilverLight project. In doing so, you’ll be using the SP ClientOM (Client Object Model). As such, you’ll need a SharePoint context from which to run your SL app. In other words, you have to deploy this to your SharePoint site. If you want to run it from a space outside a SharePoint context, then good luck with XSS (Cross-Site Scripting).

OK. Let’s get started. First off, we crank out Visual Studio and create a new SilverLight application. We’ll also let it create a Web site for us, but we’re not going to use it in this sample.

Next, we’ll add references to our SharePoint ClientOM. We need to find the DLLs in the SharePoint Root under Bin (that is “14/bin”).

On our new cancas, we’ll add a stack panel so we can easily line up a button and a textbox. We’ll let the textbox wordwrap, too.

On our code-behind file, we’ll add a using directive. 

 “Wait. Only 1?” you ask. “Didn’t we reference two DLLs.”

Yes, only one even though we did reference two files. Let’s take a look at their names spaces using the Object Browser. You’ll notice the Runtime uses the same namespace.

The next three images show the entire class.

In the second image, you’ll see we’re handling the button event and calling a method. That method sets the context, creates a query, and then sends the query off to the server. Because the SP ClientOM for Silverlight ONLY works asynchronously, the app needs to know which method to call for a success and which to call for a failure. Either way, execution will return on a behind-the-scenes thread.

Because we need to update the GUI, yet the execution returns on a seperate thread, we need to jump back onto the primary thread. To do so, we have to call Dispatcher.BeginInvoke() and give it a delegate. And we have to do this for success and fail. Imagine if we have a bunch of queries to run on the server. We wind up with several methods. To keep things simple, I use a common method for failures. This is somewhat limiting in functionality. If we need a custom error message for each point of failure, then we’ll need a unique fail method for each query, too.

Here is the bin directory. Keep this handy. You’ll upload the .xap from here into SharePoint.

In SharePoint, I’ve created a new page. However, any page will do.

In this page, we Insert a SilverLight WebPart.

The SilverLight webpart needs a url. Enter the url from the xap file loaded into a document library above.

And here we have our webpart on the page.

Finally, the fruit of our labor.

So we now have a XAP file that will query SharePoint for all lists in the site. Next, we’ll attempt to display the lists in a grid, allowing the user to select any list. Upon doing so, the app will display all items from that selected list.