TLDR: Setup steps to get WCFDS 5.4 up and running

JULBS (Julie’s Usual Lengthy Back Story):

WCF Data Services (aka WCFDS) updates are being released at a rapid pace. I think they are on a hoped-for 6-week release schedule and they just released 5.4 a few days ago.

One of the reasons is that they are adding in more and more support for features of OData v3. But rather than waiting until ALL of the features are in (by which time OData v4 may already be out! :)) they are pushing out updates as they get another chunk of features in.

Be sure to watch the http://blogs.msdn.com/astoriateam blog for announcements about release candidates (where you can provide feedback) and then the releases. Here for example is the blog post announcing the newest version: WCF Data Services 5.4.0 Release.

I wanted to move to this version so I could play with some of the new features and some of the features we’ve gotten starting with v 5.1 – for example the support for the streamlined JSON output (aka “JSON light”) and Actions & Functions.

As there are a number of steps involved for getting your WCFDS to use v 5.4, I somehow performed them in an order that left me in the cold. I couldn’t even get JSON light output.

So after scratching my head for way too long, I finally started the service from scratch and this time it worked.

1. Create a new project to host your service. I recommend a WCF Services Application project
2. Delete the IService1.cs and Service1.cs files created in the new project.
3. Add a new WCF Data Service item
4. Remove the references to the following WCFDS 5.0  assemblies:
   1. Microsoft.Data.Edm
   2. Microsoft.Data.OData
   3. Microsoft.Data.Services
   4. Microsoft.Data.Services.Client
   5. System.Spatial
5. Using Nuget, install WCF Data Services Server. The current version available on Nuget is 5.4.
   When you install this, Nuget will also install the other 4 assemblies (Edm, OData, Services.Client and System.Spatial)
6. UPDATE! Mark Stafford (from the WCFDS team) let me in on a “secret”. The WCFDS template uses Nuget to pull in WCFDS5 APIs, so you can just use Nuget to UPDATE those assemblies! (this is for VS2012. For VS2010, use the crossed out steps 4 & 5 :))

1. Install Entity Framework 5 from Nuget

That should be everything you need to do to have the proper version of WCFDS.

Now you can follow a normal path for creating a data service.

In case you’re not familiar with that the basic steps (just getting a service running, not doing anything fancy here)

1. Add reference(s) to any projects that contain your data layer (in my case a data layer with EF’s DbContext) and domain classes.
2. Modify the WCFDataService class that the Add New Item wizard created so that it uses your context. My context is called CoursesContext, so here I’ve specified that context and simply exposed all of my entity sets to be available as read-only data using the SetEntityDataAccessRule. That is not a best practice for production apps but good enough to get me started.

 public class MyDataService : DataService<CoursesContext>
    {
    public MyDataService()
      {
        Database.SetInitializer(new CoursesInitializer());
      }

        public static void InitializeService(DataServiceConfiguration config)
        {
            config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
            config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3;
            config.UseVerboseErrors = true;
        }
    }

My data layer includes a custom initializer with a seed method so in the class constructor, I’ve told EF to use that initializer. My database will be created with some seed data.

Notice the MaxProtocolVersion. The WCFDS item template inserted that. It’s just saying that it’s okay to use OData v3.

I added the UseVerboseErrors because it helps me debug problems with my service.

Now to ensure that I’m truly getting access to OData v3 behavior, I can open up a browser or fiddler and see if I can get JSON light. JSON light is the default JSON output now.

WCFDS now lets me leverage OData’s format parameter to request JSON directly in the URL. I can even do this in a browser.

Chrome displays it directly in the browser:

Internet Explorer’s default behavior for handling a JSON response is to download the response as text file and open it in notepad.

In Fiddler, I have to specify the Accept header when composing the request. Since JSON light is the default, I only have to tell it I want JSON (application/json).

Fiddler outputs the format nicely for us to view:

If I want the old JSON with more detail, I can tell it to spit out the odata as “verbose” (odata=verbose). Note that it’s a semi-colon in between, not a comma.

(I’m only showing the JSON for the first course object, the second is collapsed)

Checking for the existence of the JSON Light format and that it’s even the new JSON default, helps me verify that I’m definitely using the new WCFDS APIs and getting access to the OData v3 features that it supports. Now I can go play with some of the other new features! 🙂

Brian Sullivan was having a weird query performance problem with one particular EF query and asked about it here on Stackoverflow. Some very knowledgeable people asked all the right questions. It made no sense.

He finally discovered the source of the problem himself.

His code first model defined a string property which SQL Server automatically presumes is an nvarchar. But his database had an varchar. Since these are coercible, Entity Framework decided to coerce the type under the covers. And it was very expensive. Brian fixed the problem by applying a mapping that just said “hey EF, that’s an varchar by the way” and all was well again.

This is one of those awful problems that will be hard to solve and hard to do a web search for. But hopefully the SO question or this blog post will help the next dev coming down the pipe.

Brian has written his own, more detailed blog post about this here -> Entity Framework Code-First Performance Issue with String Queries