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=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL” could not be resolved because it has a dependency on “System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” which is not in the currently targeted framework “.NETFramework,Version=v4.0,Profile=Client”.

Formatted:

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.