Creating Office 2010 Add-Ins using SharePoint as a data source

There are new extensibility in Office 2010 that supports SharePoint 2010.

Office Business Applications – Extend the capabilities of Office

Why use them?

  • Cost and redundancy reduction through task automation
  • Reduces repetitive busy-work
  • Surfacing and re-purposing data and making it available in more areas

Agenda

  • How to build a Word Add-in
  • How to retrieve data from a SharePoint list
  • Some common deployment scenarios

Once again there's a template in Visual Studio 2010 for creating a Word Add-In Project

It's using WPF to build this add-in, he's adding a stack panel with a button list box and some text blocks that will be bound to data.

He's adding this WPF to the task pane and it's all done through code with about 8 lines, pretty nice.

What's new in accessing lists in SharePoint?

Client OM is new

Unified object model across all clients

  • JavaScript, .Net CLR, Silverlight CLR

Subset of the Server OM

  • Web, Lists, ListItems, Content Types, Fields, etc (pretty much what you need on the client anyway)
  • Limited to Site Collections, Site Level and below (of course because of the BCS I know how to work this J )

He's set up tow lists category and course, and the courses list has a relationship to the category list.

Adds a new class called course, this will be used for data binding. Once again it just has properties with getters and setters. Add references to the SharePoint Client Object Model, the client.dll and runtime.dll. In the original WPF add in, wire up the control to SharePoint. Adding a property to store all the courses using course class. Sheesh, he had a snippet with only 5 lines of code, I thought 'Wow, that's pretty lightweight'. It looks like the typical (for SharePoint 2010) you get a context, loading it first, then executing the query to retrieve the information. Load the Lists on the site, and retrieve the data again. Then find the list we want to access and again load and retrieve the data. Then it binds it to the list box.

Now he's going to do the same thing with ADO.NET Services. Thought this was about retrieving SharePoint data??? He's using the same user control, ahhh, and he's using the ADO.NET Services to access data from the SharePoint list by just using the URL for the REST. Nice wizard, it shows you all the lists that are available to use.

This looks to me like a much better method, a lot less code compared to the Client Object Model with the same results. Basically it only needs to use 3 lines of code, compared to probably around 20-25.

He adds a drop down to the control, and he's going to allow the user to filter the courses by category. Adds another data context to access the category list, then populate the drop down. Pretty standard fare, just getting the data very loosely coupled using REST. Using some LINQ to filter the data as well, yeah, yeah, I can hear Ryan already telling me about how useful LINQ is. J

It is running just a bit slow, so now he's going to improve the performance by bringing back the courses and their categories instead of making separate round trips.

That's it for the integration, now he's going over Deployments

Aspects of a good deployment

Simple Installation process

  • Simple upgrade process
  • Requires little or no user interaction
  • Requires minimal administrator interaction

Two ways

  • Click Once deployment
  • WSP deployment

Click Once deployment are your standard ones, nothing really special about it.

Ok, the WSP was pretty cool, you push it out to the site as the default document, then when a user creates the document it installs the Add-in. It does require setting a trusted location in Word to allow it to install though.

Wow, that was short, 30 minutes short exactly. Surprising considering the other ones had to rush and still had trouble finishing.