With EF6, Microsoft (and the community that is helping with this OSS project) is pulling the Entity Framework Designer tools out of the Visual Studio install and making them a part of EF6. While you can add EF6 into a project via NuGet, tooling is a different story. That gets installed via an MSI (maybe eventually via Extensions in visual studio gallery?).

The recent blog post that announced the availability of EF6 Beta 1 and the first pass at the out of band tooling [EF6 Beta 1 Available] said :

• The EF tooling is included in this preview for the first time for the EF6 release. Our focus with the tooling has been on enabling EF6 support and enabling us to easily ship out-of-band between releases of Visual Studio. The tooling does not included any new features.

My assumption from reading “The tooling does not included any new features” is that what’s in this MSI will only replace the built in VS designer.

Don’t forget that we also have the Entity Framework Power Tools. I recently wrote about my favorite feature of the Power Tools here:

Entity Framework Power Tool Tips to View Model (A Feature I Depend On!). The plan is to incorporate them into the designer so that there is one consolidated tool.

Based on the blog post, I didn’t expect to see any of the Power Tool features in the EF6 Beta 1 Tools.

But someone asked about one of the power tool features on twitter, and even though my confidence was high, I didn’t want to reply with “well I’m pretty sure that the blog post means no”, so I spun up a new virtual machine with VS2012 and installed the new tools.

And as the blog post says: no new features. In other words, the Beta1 is just the same designer that is in Visual Studio.

They have so far performed that task of separating the designer and now they can start adding the new features which will be something like what they’ve laid out in the the Tooling Consolidation Feature Specs on codeplex.

When defining models with Entity Framework’s Code First and a DbContext class, I find the “View Model” feature of the Entity Framework Power Tool completely indispensable. Without it, I only *think* I know what I’ve told EF my model should be but I don’t really know how Code First will interpret the information I’ve provided (class structures, DbSets, configurations).

For example, I may have a set of classes but a DbContext that only specifies a single DbSet:

    public class CustomerServiceContext : DbContext
    {
        public DbSet<Customer> Customers { get; set; }
    }

But because of relationships from Customer to other types and their relationships to even other types, using it’s base rules (convention) Code First interprets your entire model as

Another common point of mapping confusion is with relationships. Being able to visualize how Code First interprets the model can show me where, for example, I’ve attempted to define a 1:1 relationship but in fact, I’ve defined a 1:0..1 which will really create problems down the road in my application.

I use the tool to show me where I haven’t configured things properly and fix my mappings (via convention or configurations) until the visual model aligns with my intention.

So I really can’t live without this tool and I show it to everyone I can.

Currently the tool is something you install as an extension to Visual Studio. It’s called Entity Framework Power Tools Beta 3 and it works even wtih the latest update to VS (Visual Studio 2012 Update 2).

While there are other features, with the tool installed, you can point to any class that inherits from DbContext, right click and see “Entity Framework” on the context menu. Select Entity Framework and you’ll see four options. My focus is on the first of these “View Entity Data Model (Read-only).

But half the time I show it, it doesn’t work and it’s always something I’ve done wrong and forgotten about.

Designer Problems != Modeling Problems

If there is a problem with your model, you’ll get a helpful error message in the output window. This is about what’s wrong with your mappings. One common one is you tried to create a one to one mapping but haven’t given code first enough detail (e.g. it needs to know which is the principal and which is the dependent).

The focus of this blog post however is problems I encounter with getting the tool to perform it’s task.

Most Common Reason that the Designer Fails: Can’t Find the Connection String

Even though the designer is not going to touch the database to generate the view, it still needs to have access to a connection string.

But when it can’t find it, it doesn’t always tell you that it can’t find the connection string.

Typically I get an error message that says: “sequence contains no matching element”.

Another is “Exception has been thrown by the target of an invocation”.

Designer Looks for  the Connection String in the Startup Project of a Solution

This is the A#1 reason that the designer won’t work. It’s a bit of a pain because you don’t really want to set things up for the designer, but for debug mode. It doesn’t matter if the startup project is executable. It just has to be some project with a config file and in the config file, valid connection information ( a connection string or connection info in the Entity Framework section) that EF will look for.

Designer Will Not Look Inside Solution or Project Folders

This is my A#2 reason the designer won’t work. I like to organize my solutions. I organize projects into solution folders and I organize code into project folders. If you config file is in a folder, the designer won’t find it.

My Typical Setup for Success

So I have a separate project in my solution that is NOT inside a folder just to help me use this critical designer tool. Thanks to Vaughn Vernon for helping me find a better name for the project than I had been using that makes it very clear that this has nothing to do with my application at all.

So when I need to view a model, as long as I remember to set that project as the startup project in my solution, the designer is able to do it’s job. Here is an example of using this for a context that doesn’t even inherit DbContext directly. It inherits from my own class “BaseContext” which inherits from DbContext. The designer is able show me the visual model even with this extra abstraction.

Another Weird Error that Is Not About the Connection String: “A constructible type …”

Thanks to Ethan in comments for pointing out this one. I actually had it the day *before* I wrote this post and had forgotten (short term memory issues…old age…excuses excuses 🙂 ).

‘A constructible type deriving from DbContext could not be found in the selected file’.

This was misleading because like Ethan, the fact that I was deriving from BaseContext led me to believe that *this* was the cause for not being able to find the DbContext type. But changing CustomerServiceContext to inherit DbContext directly did not fix my problem.

I found this StackOverflow thread about this error message with a response from Brice Lambson of the EF team that suggested an Visual Studio extension was the issue. I had just added two extensions for spell checking my code and comments. One was HTML Spell Checker (from Microsoft), the other was Multi Language Spell Checker (also from someone at Microsoft). So I thought I would disable one at a time to see if one was the culprit. I happened to pick HTML Spell Checker to disable first and voila, the View Entity Data Model tool worked again (after a VS restart). Fortunately the second extension is the one I had really wanted anyway.  I believe that this problem will be resolved by the time we get the tools integration in EF6.

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! 🙂