There’s a known problem with EDMX code generation in VS2012. I’ve tested this a number of ways in VS2010 and can’t reproduce the problem there so it seems to be specific to VS2012.

The problem occurs when you have your model inside of a project folder such as in this screen shot:

When you make changes to your model, normally, saving the model will trigger the code generator to regenerate the classes.

But when the model is inside a folder, this won’t happen. (It’s not intentional…just a bug.) And you may not realize that this is the problem that’s causing you to have problems during development. Instead you won’t be able to use new (or modified) entities or properties when you are coding against the model because the generated classes weren’t updated.

So, for example, if you change an entity from Contact to Person, (and the EntitySet name will then change from Contacts to People), when you try to write a query against context.People, “People” will not exist as an option. Or if you try to write code related to Person, there will be no such class available.

This is a known issue and has been logged as an item for Entity Framework on the CodePlex site. You can vote for it to raise it’s priority level here: http://entityframework.codeplex.com/workitem/453.

In the meantime, if you want to keep your edmx file inside a project folder, you can still force the code generation to happen by selecting Run Custom Tool from the context menu of the Context.tt file and the model.tt file. Be sure to update BOTH files so that any entity name changes will get picked up by the context as well.

Thanks to Cori Drew who brought this problem to my attention and to Pawel Kadluczka from the EF team for pointing me to the work item when I had given up on a web search.

Many devs have been waiting for a toolkit so they can consume OData from [Metro] “Windows Store” apps they are building. The Release Candidate of these tools is now on the download center:

WCF Data Services Tools for Windows Store Apps RC:

“The WCF Data Services Tools for Windows Store Apps installer extends the Add Service Reference experience with client-side OData support for Windows Store Apps in Visual Studio 2012.”

 http://www.microsoft.com/en-us/download/details.aspx?id=30714

Mark Stafford from the OData team has written two blog posts that walk you through using the tooling and creating a WinRT (aka Windows Store) app

OData 101: Building our first OData-based Windows Store app (Part 1)

OData 101: Building our first OData-based Windows Store app (Part 2)

I’ve been wanting to do this for a while and I make no promises that I will do this periodically, but here goes.

These are blog posts I’ve linked to twitter, but that’s ancient history after a few hours.

Code First Stored Procedures With Multiple Results  Posted on August 15, 2012. (Rowan Miller from the EF Team)

5 part series on Contributing to newly open-sourced EF by Arthur Vickers (another EF team member)

So you want to contribute to EF? Part 1: Introduction

So you want to contribute to EF? Part 2: The code

So you want to contribute to EF? Part 3: Testing

So you want to contribute to EF? Part 4: Developer experience

So you want to contribute to EF? Part 5: High-level architecture

A Troubleshooting Guide for Entity Framework Connections & Migrations

by K.Scott Allen. This one looks like a compilation of emails I have sent to people who ask me questions like this all the time. Kudos to Scott for putting this together.

Don’t forget that msdn.com/data/ef is the easy way to get to the Entity Framework Developer Center.

I’ve also written some posts on Entity Framework (they all go in my Data Access category). Since you are reading this post, I’ll assume you know how to find those so there’s no point in highlighting them here.

Visual Studio 2010 Defaults were defined Prior to DbContext Release

Visual Studio 2010 and .NET 4 were released before Entity Framework’s DbContext existed. DbContext was first released along with Code First in the Entity Framework 4.1 package.

By default, when you create and EDMX (whether Database First or Model First) in VS2010, the code generator will build classes that inherit from EntityObject and  the context created inherits from ObjectContext.

Back then there was also the option of switching to a T4 template that created lighter weight domain classes from your entities while still using ObjectContet as the base class for the generated context.

Please Generate DbContext, not ObjectContext

Along with DbContext, the team released a new T4 template that would generate even *simpler* domain classesa and a context class that inhertied from the newer, smarter and lighter weight DbContext.

The guidance from the team (and I am in full agreement) was to use this DbContext template for any new project, but stick with the older ones if you needed the backward compatibility. This mean downloading EntityFramework from NuGet and doing the special steps to switch to generating with the T4 template.

New Default Behavior for Visual Studio 2012

Now in Visual Studio 2012, the default behavior follows their guidance! Hooray.

When you create an EDMX, Visual Studio 2012 will automatically use the DbContext template to generate the classes and context *and* it will automatically add EntityFramework.dll to your project.

Here you can see the EntityFramework reference, the two new templates and the packages.config (a NuGet asset which tells the project about the downloaded EntityFramework.dll) that were added to the project when I added a new ADO.NET Entity Data Model item to my project.

#happiness

The EF Designer has undergone a little change since the Release Candidate of VS2012. It is now following the-visual-style-formerly-known-as-Metro

Entity Framework was recently open-sourced (here is my blog post take on that:Open Source Entity Framework).

Yesterday, a new version of Mono was released, 2.11.3, that now includes support for Entity Fraemwrok.

Head over to Miguel Icaza’s blog post, Mono 2.11.3 is out for a bit more information and links!