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!

From my book (Programming Entity Framework, 2nd Edition, p.590)

While it’s specific to performance with Entity Framework, I think that it is great advice in general.

From the Horse’s Mouth: Performance Tuning Guidance for Entity Framework

Danny Simmons, who is an architect on the Entity Framework team, gave this great advice on a Channel 9 MSDN podcast he and I participated in together as we were interviewed by Microsoft Sweden’s Dag Konig (http://channel9.msdn.com/posts/buzzfrog/MSDN-Radio-31-Maj–Entity-Framework ):

I give the same recommendation about performance optimization with Entity Framework that I give with any code. Which is: write your code the simplest,
easiest to maintain, most efficient possible way.

And then profile it; find where the problems are and start applying optimizations. And when you do that, you typically will find that there are a set of things you can do to improve performance still using the Entity Framework, and eventually some very small set of cases you may find that the performance is very critical and even after you apply your tricks with entity framework, you need to do something faster than that.

And then you can go to some of the extensibility mechanisms, like writing a stored procedure with hand written sql or those kinds of things to really
optimize those few cases.

And that mix allows you to have very rapid development,  easy to maintain code using the entity framework and then in a very few places have very highly tuned code.

FIrst, be sure to read my post “When is EF5 not EF5” so you understand the basis for this post.

When you use EF5, regardless of targeting .NET 4 or .NET 4.5, you’ll find the special EF related data annotations (such as MaxLength and NotMapped) in the System.ComponentModel.DataAnnotations.Schema namespace.

In EF4, they were in System.ComponentModel.DataAnnotations namespace

Installing EntityFramework 5 to my project.

EF5 has been successfully installed.

But I installed it to a project targeting .NET 4, not .NET 4.5. Check out the version of Entity Framework that got installed. It’s not 5.0.0.0. It’s 4.4.0.0.

So what’s with that version number? Here is the folder created when I installed the EF5 package. (EntityFramework.5.0.0.-rc).

There are two folders in the lib folder – net40 and net45. Inside net40 there’s an EntityFramework.dll that has the product version name “5.0.0-4c.net40” and its File version is 4.4.20502.0.

In the net45 folder is the EntityFramework.dll file that is version 5.0.0.0.

The 4.4 version understands what’s in System.Data.Entity.dll in .NET 4.

The 5.0 version understands what’s in System.Data.Entity.dll in .NET 4.5. .NET 4.5 is where enum support lives, where System.ComponentModel.DataAnnotations.Schema lives, where System.Data.Spatial lives, etc.

We have two versions of EntityFramework coming via a single NuGet so that YOU don’t have to worry about downloading the correct version to align with the version of .NET that your project is targeting.

This makes a lot of sense, but there are a lot of people who ask me “I just downloaded EF5 but where are the enums”.

Hope this clears things up for some of you.

I get a lot of Entity Framework questions in email. Some from friends, some from people I don’t know. I like to help & answer when I can but this format means that nobody else gets to learn from the question. That’s one of the benefits of asking (or first researching) on the forums, stackoverflow.com and other community forums are so great…others can learn from your questions. Or you can learn from theirs!

Here is one of the 10 or so questions I got over the weekend. I was happy to answer because it was an easy one for me. (They aren’t all so easy for me… )

The developers was hitting a very common point of confusion about setting Entry.State with graphs.

Question:

Hi julia!

what am I missing…

I have code first entities:

MaritalStatus

{

int id {get;set}

string Description {get;set}

}

Person

{

int Id {get;set;}

string FirstName {get;set;}

string LastName {get;set;}

MaritalStatus MaritalStatus {get;set}

}

I am binding control DataContext to a selected person

I have text boxes bound to the name parts, I have a combo box bound to a list of marital status.

the bindings all work – I change the combo, I can see in the debugger that is putting the selected marital status on my bound object

I execute this code to save the person:

using (var context = new PersonnelContext())

{

context.Entry(Person).State = System.Data.EntityState.Modified;

context.SaveChanges();

}

the name parts persist, but the marital status doesn’t.

Any ideas????

Answer:

Setting the State of an Entry to modified affects ONLY the object whose state you are setting. I t will have no affect whatsoever on other objects in the graph.

By passing Person into context.Entry, the full graph attached to Person will also get attached to the context. But initially, everything will be marked as Unchanged. Then the code changes the state of the Person object to Modified. The rest of the objects in that graph remain Unchanged.

SaveChanges will only send an UPDATE command to the database for the Person object.

Hope it helps.

P.S. This same information is in Chapter 4 of Programming Entity Framework: DbContext, starting on page 88.

In case you missed it, yesterday (that’s July 19, 2012), the EF team announced that starting with EF6, Entity Framework will be open source. They’ve already got the development moved to CodePlex.

In this case, open source does not mean everyone and their sister will be committing *their* changes. The team will continue to control the code base and commits so in that regard, you should not think of this as anything new. It’s still a very important piece of Microsoft technology.

I’m really happy about this change for a number of reasons.

1. #1 is about community involvement that’s become more and more important to how EF has evolved in it’s more recent iterations. While the team will continue to ultimately control the code base, the fact that they are doing this openly on CodePlex means that we developers can see what’s going on, provide feedback not just on ideas and features but on their code. This is a even more transparent than what they were doing on the EFDesign blog (which was retired recently, btw).

   More importantly, we can submit contributions as well.  

   Here’s how it’s explained on the CodePlex site:

   There are lots of ways to contribute to the project.

   You can contribute by reviewing and sending feedback on code checkins, suggesting and trying out new features as they are implemented, submit bugs and help us verify fixes as they are checked in, as well as submit code fixes or code contributions of your own. Note that all code submissions will be rigorously reviewed and tested by the Entity Framework team, and only those that meet an extremely high bar for both quality and design/roadmap appropriateness will be merged into the source.

      You may have    a feature in mind that you want to add into EF or you can go work on one of the bugs listed in the Issues page. Or you can go look at ideas submitted on UserVoice. Or you may know a better way to implement something that they are working on. Or you might just want to know what’s going on so you can plan ahead for your own development schedule.

   One of the things I have seen people misunderstand and therefore they worry about, is that OSS equates to Microsoft throwing EF over the wall. That is just not true. The team remains committed to taking EF forward. This is just what’s happened with ASP.NET MVC + when those went open source in March.

   I think the EF team was very clear in their announcement post:   

   Same Support, Same Developers, More Investment

   Very importantly – Microsoft will continue to ship official builds of Entity Framework as a fully supported Microsoft product both standalone as well as part of Visual Studio (the same as today). It will continue to be staffed by the same Microsoft developers that build it today, and will be supported through the same Microsoft support mechanisms. Our goal with today’s announcement is to increase the development feedback loop even more, allowing us to deliver an even better product. 

 

2. It provides the ability to fork EF for your own needs. We’ve been complaining for years that EF is not extensible enough. So, download it, extend it where you want and use it in your apps. Okay, that’s not going to be for everyone, but it will be incredible for many.
3. The CORE part of EF that currently lives in .NET will no longer be tied to .NET releases. Since the release of EF 4.1 on NuGet, we’re starting to get into the rhythm of how the EF team is bringing us new features when they are ready– Code First, DbContext API, Code First migrations –without waiting for a .NET release. Up through EF5, this stuff sits on top of the CORE entity framework APIs (System.Data.Entity) that live in .NET. Big changes to how EF works need to be made in the core and so we had to wait for the next version of .NET (e.g. .NET 4.5) to get those bigger changes. For example, enum support required changes to the core. I’m guessing that the hold up for stored procedure support for code first is because maybe there’s something in the core that is a show stopper (honestly it’s a completely wild guess). Those core APIs are being lifted out of .NET and will become part of EF6 (and beyond) and part of the OSS package. So *all* of EF will now be more fluid.

On the codeplex site, you’ll find that the development has transitioned over from their internal development. For example, while the site became public on July 19th, here’s an item that was added and modified by team members (Diego and Rowan) in April:

And so…

While EF is now open source,

• it still reigns as Microsoft’s primary .NET API for accessing relational databases.
• it is still fully supported by Microsoft
• the EF team is still in place with the same power-devs that brought us code first, dbcontext and more
• it continues to move forward and the team has already begun work on
  • task-based async support
  • Stored Proc support for code first (yay)
  • finishing up the customizable code first conventions that didn’t make it into EF4.1 (double yay).
• we won’t have to wait for the next version of .NET for modifications that need to be made in the core

Stuff to read about this move:

Team Blog Post Announcement: Entity Framework and Open Source

Scott Guthrie’s Announcement (same title, different blog post): Entity Framework and Open Source

Series of posts by Arthur Vickers who is one of the key folks on the EF team:

• Why open sourcing Entity Framework is a great move

• 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

Of course, the Entity Framework CodePlex Site->http://entityframework.codeplex.com/

Rowan Miller’s blog

Diego Vega’s blog

I moved a small EF 4.3 solution to EF5 (and to .NET 4.5) so I can add the new enum support to it. Then I started the process all over again and captured it as a screencast.

Pluralsight is hosting it on their blog here: Video: Entity Framework 5 New Features Sneak Peek. It’s 14 minutes long. I learned a whole bunch of tricks along with way which I’ve shared here.

• Moving a solution from EF4.3 +.NET 4 to EF5 +.NET 4.5
• Using the new SQL Server Object Explorer in Visual Studio 11
• Working with the new DbLocal database
• Seeing the enum support in action : how it impacts the database, inserting and querying data with enums.