EF 4.1 Is Coming (DbContext API & Code First RTW)
The information in this post is out of date.
Visit msdn.com/data/ef for the latest information on current and past releases of EF.
Our latest EF Feature Community Technology Preview (CTP5) has been out for a few months now. Since releasing CTP5 our team has been working hard on tidying up the API surface, implementing changes based on your feedback and getting the quality up to production ready standards. At the time CTP5 was released we also announced that we would be releasing a production ready go-live in Q1 of 2011 and we are on track to deliver on the commitment.
Our plan is to deliver a Go-Live Release Candidate version of the DbContext API and Code First in mid to late March. This Release Candidate will be titled ADO.NET Entity Framework 4.1. Approximately a month after the RC ships we plan to release the final Release to Web (RTW). We are not planning any changes to the API surface or behavior between RC and RTW, the release is purely to allow any new bugs found in the RC build to be evaluated and potentially fixed.
Why ADO.NET Entity Framework 4.1?
This is the first time we’ve released part of the Entity Framework as a stand-alone release and we’re excited about the ability to get new features into your hands faster than waiting for the next full .NET Framework release. We plan to release more features like this in the future. We chose to name the release EF 4.1 because it builds on top of the work we did in version 4.0 of the .NET Framework.
Where is it Shipping?
EF 4.1 will be available as a stand-alone installer that will install the runtime DbContext API and Code First components, as well as the Visual Studio Item Templates that allow using the new DbContext API surface with Model First and Database First development. We also plan to make the bits available as a NuGet package.
What’s Coming in RC/RTW?
The majority of our work involves small API tweaks and improving quality but there are a few changes coming in the RC that we want to give you a heads up about.
- Rename of DbDatabase
We heard you, admittedly the name was a little strange. It is going back to ‘Database’ for RC/RTW. - Rename of ModelBuilder
To align with the other core classes ModelBuilder will become DbModelBuilder. - Validation in Model First and Database First
The new validation feature was only supported in Code First in CTP5. In RC the validation feature will work with all three development workflows (Model First, Database First, and Code First). - Intellisense and online docs
We’ve held off on extensively documenting the CTPs because the API surface has been changing so much. RC will have intellisense and online documentation. - Removing Code First Pluggable Conventions
This was a very painful decision but we have decided to remove the ability to add custom conventions for our first RC/RTW. It has become apparent we need to do some work to improve the usability of this feature and unfortunately we couldn’t find time in the schedule to do this and get quality up the required level. You will still be able to remove our default conventions in RC/RTW.
There are also a few common requests that are not going to be available in the RC/RTW, we really want to address these scenarios and plan to do so in coming releases. We’ve had overwhelming feedback asking for a go-live release though and have decided to finish our current feature set and ship it.
- Code First bulk column renaming not supported
On a few forum threads we had discussed possibly re-enabling the ability to rename columns when specifying properties to be mapped, i.e. modelBuilder.Entity<Person>().Map(m => m.Properties(p => new { person_id = i.Id, person_name = p.Name }));
This is not going to be supported in our first RC/RTW. - No compiled query support from DbContext
Unfortunately due to some technical limitations in the compiled query functionality we shipped in .NET Framework 4.0 we are unable to support compiled queries via the DbContext API. We realize this is a painful limitation and will work to enable this for the next release. - No stored procedure support in Code First
The ability to map to stored procedures is a common request but is not going to be available in our first RC/RTW of Code First. We realize this is an important scenario and plan to enable it in the future but didn’t want to hold up a go-live release for it.
Database Schema Evolution (Migrations)
One of the most common requests we get is for a solution that will evolve the database schema as your Code First model changes over time. We are working on this at the moment but we’ve also heard strong feedback that this shouldn’t hold up the RTW of Code First. In light of this our team has been focusing on getting the current feature set production ready. Hence a schema evolution solution will not be available for our first RTW. You’ll start to see more on this feature once we have RTW released.
Thank You
It has been great to have so much community involvement helping us drive these features, we thank you for giving us your valuable input.
ADO.NET Entity Framework Team
Comments
Anonymous
March 02, 2011
This is great news. Will any of the commonly request items like enum support, bulk update operations or a built-in 2nd level cache be added?Anonymous
March 02, 2011
Darn it!! No SP support?? Cached queies?? Very dissapointing. Guess we'll have to wait a bit longer to use this. Please just make sure that when you do implement you do it right. Needs SPs to map to POCO objects or maybe even dynamic objects. Same goes for an ad-hoc SQL query. Looking forward to the release.Anonymous
March 02, 2011
I think that is very important that the Entity Framework was released in the same way that ASP.NET MVC, regardless. NETAnonymous
March 02, 2011
I'll echo Ron's ask for type conversion - not just enums.Anonymous
March 02, 2011
Really great news, I'm excited, but oh yeah, Enum Support, Bulk Update and anothers greats features... there's a prevision?Anonymous
March 02, 2011
Do you have any plans on when will you release next version of EF after this one (4.2.) and what will be inside it, especially concerning migrations, enum support etc.?Anonymous
March 02, 2011
No pluggable conventions? That's going to make things hard for working with the Devart DotConnect for Oracle provider. Devart came up with a DefaultSchemaConvention to allow a different default schema name to be used instead of dbo. See www.devart.com/.../viewtopic.php What is the roadmap after 4.1? When will we see a 4.2? Will there be a possibility to vote for features as on dotnet.uservoice.com? Now that 4.1 is announced I am desperate for an announcement from the WCF RIA Services team on how they will be able to support EF Code First. Specifically will WCF RIA Services be able to read the EF metadata to automatically add Key and Association attributes to your POCO classes as required by WCF RIA Services. Otherwise it would be silly having to add these attributes manually for the sake of WCF RIA Services, when EF can use conventions to derive these automatically. See social.msdn.microsoft.com/.../57793bec-abc6-4520-ac1d-a63e40239aedAnonymous
March 02, 2011
The comment has been removedAnonymous
March 02, 2011
I'll Echo Darius. Sp Support and compiles queries is required. Compiled queries has a tremendous performance benefit in application. Ofcourse SP support is available in Database first, so we expected that would be available with Ef 4.1 also.Anonymous
March 02, 2011
Will Azure work well with ADO.NET Entity Framework 4.1 (RC)?Anonymous
March 02, 2011
No mention of T4 templates built in?Anonymous
March 02, 2011
No stored procedures, are you kidding me )-: I have been working with NH for some years now and you do need SP sometimes. So I hope that SP is #1 one the backlog Any how I love the direction code first is moving to, very easy to use and very clean. in fact we are starting a major redesign of our DAL layer and porting it to Code first.Anonymous
March 02, 2011
Does it mean that Validation will be also available when working with "old" approach using ObjectContext and EDMX?Anonymous
March 02, 2011
This is great news , but when you say "no SP support" do you mean that we will not be able to call sprocs using Context.Database.SqlQuery, Context.Database.SqlCommand and Context.MyDbSet.SqlQuery?Anonymous
March 03, 2011
Great job, guys!Anonymous
March 03, 2011
We will still be able to get at ObjectContext using something like: var objectContext = ((IObjectContextAdapter)_ctx).ObjectContext; So we can still have access to Translate<T> for binding data from SP's???Anonymous
March 03, 2011
Super news. CTP5 is awesome, looking forward to the RC.Anonymous
March 03, 2011
Any news on whether it will work in Medium Trust sites ??Anonymous
March 03, 2011
What were the complaints about the Pluggable Conventions? I was happily using them, and now the carpet has been pulled from under my feet!Anonymous
March 03, 2011
Yeah, no sp support and still no global::class for enums. This ef thing is big from start but after a long time from release it still suffer details making linqcontext more flexible. I will check again in next release.Anonymous
March 03, 2011
The lack of stored procedure support is staggeringAnonymous
March 03, 2011
I'm very happy with the base features that are planned for RC and RTW. The productivity benefits of Code First are very welcome.Anonymous
March 03, 2011
The lack of stored procedures support is pretty much a deal-breaker. Can't believe after waiting sooooo long for this Code First release you guys still can't get the features that people want in there. I was really looking forward to moving or EF stuff to Code First, but guess we won't be now. Hopefully you guys listen to the community for the next release and get Code First caught up with every other ORM out there.Anonymous
March 03, 2011
Without SP your just wasting my time.Anonymous
March 04, 2011
No query compilation probably makes Code First difficult to impossible for our organization to implement which is super sad for me personally. Having to rely on query compilation caching at all is very weak in my opinion, one of the Entity Framework's largest technical incompetencies, but at least there was a way to deal with it. Now even that's not provided for us with this improved workflow. Seems like the ADO.Net team is always two or three steps behind (or four or five sometimes). Such a sharp contrast to the Anders' C# team.Anonymous
March 04, 2011
Any chance that KB 2390624 will be included in this release or the upcoming .NET 4.0 update?Anonymous
March 04, 2011
Will this come with a new membership / registration database model?Anonymous
March 04, 2011
@Seth, ORM is a very complex piece of software. Just see the size of assemblies and all classes are related, its very complex.Anonymous
March 05, 2011
Still no word from the team on what exactly is meant by no stored procedure support. Is this the CRUD for the entities or does it also include adhoc ones called using Context.Database.SqlQuery, Context.Database.SqlCommand and Context.MyDbSet.SqlQuery? Come on guys, there are quite a few people who are upset by this so we could do with full details and a rationale.Anonymous
March 05, 2011
I hoped for enum support & database migrations in RTW :(Anonymous
March 06, 2011
Great News and waiting for the RTW releaseAnonymous
March 06, 2011
No compiled query support, no stored procedures. I recommend you guys skipping the time you will spend on going through the release process and go straight to version 4.2. Many applications will not scale without compiled queries! Who the heck is in charge over there! You guys get our hopes up, and then burst the bubble with absolutely essential feature gaps. By the way, here is a new car but the engine will not come out until the next release.Anonymous
March 06, 2011
Already using code first for a couple new projects. Really looking forward to the RC/RTW. I hope you guys keep up with the independent updates. Thanks for all the hard work!Anonymous
March 06, 2011
What about Stores Procedures / Functions support for Model First?Anonymous
March 06, 2011
What about support for binary types as primary key columns?Anonymous
March 06, 2011
echoing 2nd level cache, enum support in addition to spatial type support... if you are targeting real enterprise apps, these are the must-haves... till then ef can not be a mature orm alternative imho :(Anonymous
March 07, 2011
The comment has been removedAnonymous
March 07, 2011
Stored proc support ASAP... and please make sure you also support the user defined table types for parameters. This is the only thing that gripes me about Linq to Sql stored procs support.Anonymous
March 07, 2011
Seriously, if you're still using SPROCS, then EF Code First is not for you. Stick to older frameworks please.Anonymous
March 07, 2011
I think it is great you are making the tough choices to get a release out. I can understand pulling out conventions to make sure you get them right. But I cannot understand releasing without migrations. I am still just shocked at how long all the data teams have decided to put off supporting migrations. You need to priorize this feature!Anonymous
March 07, 2011
Could someone answer these questions please:
- Does ADO EF 4.1 replace LINQ to SQL and or LINQ period?
- Will EF 4.1 become part of .NET Framework or will it be just another random MS product that will become obsolete after a year?
Anonymous
March 08, 2011
This is fantastic news. I love working with EF Code First; I've been waiting for it to be released in a license that lets me use it in production. I'm a little disappointed that you didn't follow Scott Hanselman's lead and rename it EF Magic Unicorn Edition, but I guess I can learn to live with the boring name.Anonymous
March 08, 2011
good news. waiting for release, good to know partial support for stored procedure .Anonymous
March 08, 2011
Good work! I must be missing something. If anyone goes production what are the plans (or lack of) for migrations?Anonymous
March 09, 2011
This is great work but we are unfortunately forced to use the EDMX approach because the start up time without pregenerated views is in the minutes with our 400 table database and we can't split the model. I am surprised no one else has made this comment - unless there is a way round it with code-only that I don't know about. If not, are pregenerated views impossible with code only or something that might be included in a future release?Anonymous
March 09, 2011
Will EF 4.1 have support sql_variant type?Anonymous
March 10, 2011
We love code first but also vote for the pregenerated views feature. We have about 300 tables, and it takes about 40 seconds to startup, this is realy a pain.Anonymous
March 11, 2011
@Arthur - Regarding the pluggable conventions: I have close to 20 tables in my database, and many column names are like the following: ShortDescription, LongDescription, RetailPrice, WholesalePrice, PostalCode, PhoneNumber, etc. This is a perfect scenario for conventions, and has nothing to do with the really tricky stuff such as mapping of keys. I am very deeply disappointed about this, as I will now have to have repeated code all over the place.Anonymous
March 12, 2011
The comment has been removedAnonymous
March 14, 2011
Will this social.msdn.microsoft.com/.../44ff344d-729b-4f4c-934a-e17f82be2709 bug be fixed in EF 4.1?Anonymous
March 16, 2011
Guys, relax! I was happy to see this post where they've agreed to release it without everything. If they waited for all the features that everyone wanted, it would never go live. You'll be no worse off when EF4.1 comes out than you are currently using model- or database- first; if EF4.1 isn't fit for purpose for you, don't use it - simple as that. At least the ADO .NET team are trying to be a bit more agile and get chunks of work out there, listening to the community. That said, I'd love to see some integration between EF and VS Database Projects :-)Anonymous
March 17, 2011
Thanks for the info on the post, I really appreciate knowing what's coming soon to a website near me. There's a couple of minor tweaks I'd like to see at some point in the designer that would make it tremendously more productive:
- Being able to change he default type for ID fields (i.e., Int64 instead of Int32)
- Being able to set up naming convention patterns for ID fields partially based on entity name
- Being able to type "PropertyName:PropertyType" in the editor and have both the name and the property type assigned at the same time when inserting a new property (this one is huge)
- Corollary to #3: Being able to edit the type for the property from the entity diagram. Even just have the scalar type dropdown in the designer would really save a lot of time.
Anonymous
March 20, 2011
Are you going to support hierarchyid type ?Anonymous
March 22, 2011
For those of you still using Stored Procs, learn to code using a strongly typed language already. I put you folks in the same space as PHP developers. This is the Magic Unicorn of greatness. If you really must use T-SQL then add a ref to ADO.NET and put it in your DAL.....Anonymous
March 23, 2011
The comment has been removedAnonymous
March 24, 2011
@Code Jammr Get into the real world, there are things such as legacy applications that can't be ripped up and have 100s of man hours and business logic in stored procedure , they simply cannot be re-engineered from scratch and other decent ORM's out there account for this......already. Already indeed.Anonymous
April 04, 2011
@Anon 11 Mar 2011 9:20 PM @Arthur - Regarding the pluggable conventions: I have close to 20 tables in my database, and many column names are like the following: ShortDescription, LongDescription, RetailPrice, WholesalePrice, PostalCode, PhoneNumber, etc. This is a perfect scenario for conventions, and has nothing to do with the really tricky stuff such as mapping of keys. I am very deeply disappointed about this, as I will now have to have repeated code all over the place. It Seems you need to use a Complex Type please see and refer to classic Address type example or Name complex type at the end of this article: blogs.msdn.com/.../conventions-for-code-first.aspxAnonymous
April 19, 2011
Is there a timeline for Data Migrations... When can we expect it?