Will work in Office365!!

Tonight I thought I’d post my latest personal project called SPDragon – its a pure HTML version of Xaptic (my Silverlight Widget Library). Its still in early development but its going very well and I’m learning and having lots of fun.

This version of my widget library can use SPServices http://spservices.codeplex.com/ by Marc Anderson or the client object model, or anything JavaScript and HTML. Because this is pure HTML I can also host Silverlight widgets as well as flash – so I’m much happier now SmileI added a little background music for dramatic effect.

Let me know if you like it or want to offer some suggestions – feedback welcome



I thought I’d show you how the data is being stored in SharePoint – adding components is as simple as adding HTML and an icon to lists behind the scenes

Page Definition (trivial)


Catalog of widgets (as many as you want)


The pages behind the scenes




On Building a Custom Service Application for SharePoint 2010


Added Part 9

I’ve begun a series of posts on building a custom Service Application for SharePoint 2010. For the most part I believe I have the process understood pretty well but I’m hoping if you see errors along the way you will feel free to point them out. As such, they should be considered a work in progress. I want these to ultimately be very comprehensive and reasonably detailed so I can use them as a reference myself.

For this series of posts I’m using the EMC public blogs. You can find the first two posts at the links below

Part 1: http://consultingblogs.emc.com/scottcurrier/archive/2011/08/16/on-building-a-custom-service-application-for-sharepoint-2010-part-1-background-and-decisions.aspx

Part 2: http://consultingblogs.emc.com/scottcurrier/archive/2011/09/12/on-building-a-custom-service-application-for-sharepoint-2010-part-2-service-application-hierarchy-and-sample.aspx

Part 3: http://consultingblogs.emc.com/scottcurrier/archive/2011/09/17/on-building-a-custom-service-application-for-sharepoint-2010-part-3-some-refactoring-and-administrative-tooling.aspx

Part 4: http://consultingblogs.emc.com/scottcurrier/archive/2012/01/01/on-building-a-custom-service-application-for-sharepoint-2010-part-4-adding-administrative-code.aspx

Part 5: http://consultingblogs.emc.com/scottcurrier/archive/2012/01/01/on-building-a-custom-service-application-for-sharepoint-2010-part-5-adding-administrative-code.aspx

Part 6: http://consultingblogs.emc.com/scottcurrier/archive/2012/01/02/on-building-a-custom-service-application-for-sharepoint-2010-part-6-adding-business-logic-and-client.aspx

Part 7: http://consultingblogs.emc.com/scottcurrier/archive/2012/01/02/on-building-a-custom-service-application-for-sharepoint-2010-part-7-better-engineering-with-proxy-classes.aspx

Part 8: http://consultingblogs.emc.com/scottcurrier/archive/2012/01/04/on-building-a-custom-service-application-for-sharepoint-2010-part-8-client-access-via-proxy-classes.aspx

Part 9: http://consultingblogs.emc.com/scottcurrier/archive/2012/01/06/on-building-a-custom-service-application-for-sharepoint-2010-part-9-provisioning-a-service-application-database.aspx



PS: check out my Silverlight project called XAPTIC, it’s a widget and tile library for SP 2010 and Office 365 at http://www.youtube.com/user/scottcurrier

XAPTIC: POST Complex Objects from Silverlight


In some of my previous posts I discussed a “beefy” project called XAPTIC which is a pure Silverlight web part framework. It’s a complex enough project to keep me interested and learning. Originally conceived as Silverlight “living” within an asp.net web application. This year I decided to move it into SharePoint 2010 as a full fledged environment with high end capability to construct SharePoint applications easily. It also makes great “source material” for my blog posts as well.

See, https://scottcurrier.wordpress.com/2011/06/25/silverlight-parts-framework-for-sharepoint-2010/


The roadmap for migrating XAPTIC to SharePoint 2010 includes creating a XAPTIC service application and exposing its functionality via custom SharePoint REST based services. I can report that the service application is nearly done and deploys properly to SharePoint but that will be the subject for later posts.

For this post I’ll discuss using REST to POST objects (including potentially complex objects) to SharePoint 2010. The information presented here is somewhat preliminary and not “production” ready as yet but serves me well during this phase of development and my understanding.

Assuming you’re sending data back to SharePoint as a REST style service you would need to be concerned with several things – remember, unlike SOAP, you have no proxy – its all hand rolled (at least using the basic OTB classes). Here are some considerations

  • How to represent your class and instance data
  • Maintaining a well formed request (fiddler helps here)
  • Code to properly create that REST style request
  • For Silverlight, you need to keep everything asynchronous

For XAPTIC, I know the classes and parameters I need and therefore I can make highly specific decisions that keep my code rather simple.

For a little more background on building REST based services in SharePoint 2010 see the following links


That being said, I’ll cut to the bottom line. In my experimenting I found the best way to represent your class is by simply convert to an XElement. See


I created a simple “converter” method to do just that (see code) ConvertUserFieldsToXElement(object) and used it as part of a method that POSTs back to SharePoint 2010. I won’t go into the details of the Converter method because its basic. More likely, if you’re understanding this post you would have little trouble designing one for a class of your own.

The following is the entire method used to POST back the data


You see I also pass two parameters called internalID and pageTitle as well. By the way, hard coding the URL is not recommended but good enough for a blog post. I felt converting my objects to XElement was by far the most flexible method of class representation and very easy to understand. I originally just serialized my object as text but had some difficulty with white space and related artifacts of the serialization in the body of the request message (but that’s your choice – it all works the same).

Here is the actual fiddler trace


This method is taken directly from XAPTIC’s Silverlight client – it’s job is to pass back data to SharePoint’s XAPTIC database and update parameters from a users web part placed within the canvas. It does this by first using the HttpWebRequest class forming a proper HTTP request but then adds fields (a LIST<> of field) to the body of the request. The internalID and pagetitle parameters are passed only as part of the URL. Note that I am using anonymous methods for both the request and response handling – that piece really simplifies the code.

The interface on SharePoint looks like this:


Of course, this is early code. I’m sure feedback could include comments about using WebClient and possibly more contemporary tools to accomplish the same goal – let me know

That’s it – it works well and brings me a step closer to XAPTIC in SharePoint 2010

Thanks – Scott

Return List<myobject> using REST from SharePoint 2010


I’m having a good time playing with WCF tonight. This is a quick post on the setup for returning lists of objects defined in a WCF REST service from within SharePoint 2010 – a common scenario. For related information see the following posts



Its actually very simple but please see my previous posts for more detail. Assuming you have a separate file for the interface you can return the sample List<Project> by defining a class that looks something like the following

   public class Project {

       public string Name;

       public DateTime StartDate;

       public DateTime EndDate;

Obviously, this is a simple demonstration – next I implement the actual method as follows

public List<Project> EnumProjects()

            List<Project> projects = new List<Project>();

            // add a new project sample data
                new Project {
                    Name = "Project 2",
                    StartDate = DateTime.Parse("3/3/2012"),
                    EndDate = DateTime.Parse("12/15/2012")

            return projects;

The service itself looks as follows (in fact the WebGet attribute can be further simplified)

[WebGet(UriTemplate = "/EnumProjects", BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Xml)]
List<Project> EnumProjects(string webUrl);

For XML the result looks as follows,

– <ArrayOfProject xmlns=”http://schemas.datacontract.org/2004/07/MyServices” xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
– <Project>
  <Name>Project 2</Name>

For Json the result looks as follows,

[{"EndDate":"\/Date(1355547600000-0500)\/","Name":"Project 2","StartDate":"\/Date(1330750800000-0500)\/"}]


Crazy Simple!

Simple WCF based REST service for SharePoint 2010, note to self


This is a follow-on post concerning the building of a simple WCF services in SharePoint 2010, my caveat for this style of post (notes to self) is that the information is intended truly as a “note to self” and so written that way. By now, this info is fully addressed within MSDN and several other folks around the “interwebs”. I’ll simply present the technical differences and some related bits and pieces I find useful – if you find this post useful then all the better.   For now I won’t dive into how the data would be directly returned from a class, perhaps leave that for another post.

Important: Constructing a complete WCF SOAP service is  outlined in an older post, refer to https://scottcurrier.wordpress.com/2010/07/28/simple-wcf-service-within-sp2010-note-to-self/ I’ll concentrate only on the differences for this post. The final result will be a simple WCF service consumable by JavaScript (as well as any other client that can utilize http)


Next, refer to http://msdn.microsoft.com/en-us/library/ff521586.aspx


The above link outlines the choices regarding WCF Dynamic Configuration for these style of services. The options are SOAP, REST, and ADO.NET Data Service Factories.

In this case we will use MultipleBaseAddressWebServiceHostFactory (REST)

1) So now referring back to my previous post, the first change is to switch the Service Factory to use REST instead of SOAP. Open MyService.svc and include

<% @ServiceHost Language="C#" Factory="Microsoft.SharePoint.Client.Services.MultipleBaseAddressWebServiceHostFactory,
                                                                    Microsoft.SharePoint.Client.ServerRuntime, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
                                                                    Service="SampleServices.Service1, $SharePoint.Project.AssemblyFullName$" %>


2) Because we using the REST Factory we need to “tell” WCF how to handle the Uri by creating a Uri pattern and configure the message format (XML, Json) – the interface will look like this

using System.ServiceModel.Web

namespace SampleServices
    public interface IServices

        // http://dev/_layouts/MyServices/MyService.svc/DoWork?name=Scott <== feel free to place the service in ISAPI or LAYOUTS
        [WebGet(UriTemplate = "/DoWork?name={name}", BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Json)]
        string DoWork(string name);





Note 1: The results can be returned as XML or JSON

see http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webgetattribute.aspx


Note 2: The actual Uri does not look very REST-like because of the pattern chosen in this example. This can be easily modified

See http://msdn.microsoft.com/en-us/library/bb675245.aspx


3) The implementation would look as follows


namespace SampleServices

    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
    public class MyService : IServices
        public string DoWork(string name)
            return "Hello " + name;



What’s left is implementation of a more complex SP 2010 objects that I leave for the reader – but also – don’t reinvent the wheel, SP 2010 comes with plenty of ways with regard to exposing data via services that are compatible with virtually any type of client. The steps outlined in this post allow for simple but truly custom services based on your requirements.  


That’s it – Enjoy!

Simple WCF service within SP2010, note to self

It’s been a busy year personally and professionally but even more is coming up in August and September. From a blog perspective I’ve lapsed a bit these past several months. The good news is that I’ve been lucky enough to have developed some SharePoint 2010 solutions including a Service Application, Features, simple WCF Services, and Silverlight web parts. Of course, the catch-22 is finding the time to blog so I can refer back to what I write – which is a real benefit for me.
This post is a “note to self” with regard to developing a simple WCF service from within SharePoint 2010. These notes refer to a basic farm-wide accessible service in the style of a “traditional” SP 2007 SOAP service originating from the ISAPI folder, or perhaps a SharePoint 2010 REST service like ListData.svc. These notes do not cover “Service Application” development in any way, which is a different animal. This material can, in some form or another, be found on the web already including MSDN, See – http://msdn.microsoft.com/en-us/library/ff521581.aspx. My intent here is to group this material with some other related material I found very useful.
Preliminary – your solution properties should be set to .net v3.5 / x64

Setting up Visual Studio 2010 and web.config:


  1. Setup token replacement, see http://msdn.microsoft.com/en-us/library/ee231545.aspx
Essentially, this minimizes the need to manually add things like a 4-part assembly name. After all, the solution already has that information so why not have VS2010 do the work for you. You can also use a tool like ReSharper – anywho – you can setup the basics by following this procedure.
Navigate to  Program files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SharePointTools
Open up the Microsoft.VisualStudio.SharePoint.targets file and locate the TokenReplacementFileExtensions node.
Add svc to the list of replacement extensions
2. Be sure your SharePoint web.config has debugging fully enabled, most of us know this drill by now.
Navigate to the SharePoint sites web.config, example, C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config and set the following

3. Another useful tool that I encourage you to use is described here via Sahil Malik – http://blah.winsmarts.com (a great SP resource)
Basically, setup Powershell within Tools ==> External Tools, resulting in this command line
Powershell.exe -command [System.Reflection.AssemblyName]::GetAssemblyName("$(TargetPath)").FullName
My own screenshot of Sahil’s utility appears as follows  – be sure the output window is visible <Ctrl>–<Alt>-O
When you run the utility via Tools ==> Strong Name you will see something like this screen shot

Setup your SharePoint solution

1. Create a generic SharePoint 2010 solution
2. Make this a farm solution
3. Add the ISAPI Mapped folder
4. Add a WCF service to the project
At this point you should see two additional files in your project, IService1.cs and Service1.cs. It’s really up to you on how your want to arrange the service code. For example, you could combine the code into a single file or place one or both in a folder – etc, etc
5. Add a descriptive folder under ISAPI, I call this one MyService. Next, add a file to be used as the service endpoint. For now, I use an empty text file called MyService.svc.
6. The solution should look as follows
7. Next we need to make a reference to Microsoft.SharePoint.Client.ServerRuntime this reference contains the service factories (plumbing) we need for the next step. This was found at the following path on my machine
8. At this point we need to pull in plumbing for WCF to use. This also means we need to decide exactly what kind of service endpoint we’re talking about. We have some choices now – see http://msdn.microsoft.com/en-us/library/ff521586.aspx. From the MSDN link we can see SOAP, REST, ADO.NET Data Services. In this case I am selecting SOAP as the endpoint – so the MultipleBaseAddressBasicHttpBindingServiceHostFactory will be used
9. Next we need to add this factory class to our empty MyService.svc text file we added earlier, as well as the 4-part name of the assembly and related code. This all goes in @ServiceHost and looks as follows
<% @ServiceHost
Microsoft.SharePoint.Client.ServerRuntime, Version=, Culture=neutral,
Service="SampleServices.Service1, $SharePoint.Project.AssemblyFullName$" %>

Note: SampleService is the assembly name, Service1 was auto-generated when I added the WCF service to the project.
10. Having selected the SOAP factory as our basic plumbing we need to do something useful with the service itself – oh, I know – how about “Hello World”. First we need to add these attributes to the Service1 class
using System.ServiceModel.Activation;
using Microsoft.SharePoint.Client.Services;
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

The service code changes as follows
11. Lets test this out by deploying to SharePoint as shown
Our service endpoint will look something like this – http://dev/_vti_bin/MyService/MyService.svc/MEX
I won’t go into invoking this from the client as I assume most of us can work through that piece rather well. In any event, the final result when hitting the URL appears as follows. I’ll spare you the entire response 🙂
This completes these notes – very cool indeed.