How We Talk about EF and its Future Versions
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.
The EF team has been working to become more agile and get new features into your hands faster. Our first two releases shipped as part of the .NET Framework but, as the result of an effort to release more often, in recent times we have been shipping a slew of “out-of-band” features that build on top of the functionality included in .NET.
These out-of-band releases caused some confusion because we didn’t have a consistent way of talking about versions. To avoid generating more of this confusion in the future we recently decided to adopt semantic versioning principles.
While consistent versioning is great we still have quite a few EF related packages that ship independently of each other. We need to rationalize how we talk about them and define what we are actually referring to when we talk about “Entity Framework” and future versions of it.
The purpose of this post is to provide additional clarity about how we plan to talk about our releases in the future and to get your feedback on the approach we are taking.
The Confusion
In order to deliver features as quickly as possible, we want to keep as much as possible outside of the .NET Framework. With EF continuing to have features that ship both inside and outside the .NET Framework we need to rationalize how we talk about these.
All the EF related libraries, packages and downloads we have today are:
- Core EF libraries that ship in the .NET Framework (i.e. System.Data.Entity.dll, System.Data.Entity.Design.dll, System.Web.Entity.dll, etc.)
- EntityFramework NuGet package which includes the DbContext API and Code First (i.e. EntityFramework.dll)
- Entity Designer that ships in Visual Studio
- T4 Templates for using DbContext API with Model First & Database First that ship on Visual Studio Gallery
- EF Power Tools (still in Alpha stage) that ship on Visual Studio Gallery
- Code First Migrations (still in Alpha stage) which ships via NuGet
The Clarity
Obviously it’s going to get very confusing if we release different versions of those at different times. To avoid this we are going to focus on the EntityFramework NuGet package as the primary deliverable that we refer to as “The Entity Framework” or “EF”. The version number of this package will now define the current version of EF (currently EF 4.1 and soon to be EF 4.2). This is the main point that will govern how we talk about EF, all of our blog posts, how-to videos, whitepapers etc. will guide you toward using the EntityFramework NuGet package.
We will generally treat the core Entity Framework libraries in the .NET Framework as we do any other .NET libraries, such as System.dll, System.Data.dll etc. Therefore when the next release of the .NET Framework comes out we will release an updated version of EF that takes advantage of the new features in the Framework (including new functionality in System.Data.Entity.dll). In situations when we need to refer explicitly to the EF specific assemblies in the .NET Framework we will call them the EF Core Libraries.
The Entity Designer will continue to be installed with Visual Studio and will work with the latest version of EF.
In the future we hope to move the classes from System.Data.Entity.dll into the EntityFramework NuGet package so that we can release features such as Enums without having to wait for a .NET Framework update.
The T4 Templates for DbContext will be available under the “Online” tab when you select “Add New Code Generation Item…” from the EF designer. The templates are located on the Visual Studio Gallery but you don’t need to be aware of this or visit the gallery to use them. We are leaving the templates on VS Gallery so that we can quickly and easily respond to bug fixes, feature requests etc.
The EF Power Tools are still in preview mode and we haven’t really decided where they belong yet. For the moment they will remain as a stand-alone download on Visual Studio Gallery as this is the easiest place to distribute them.
Code First Migrations will remain as a separate NuGet package and when Code First detects that you need to migrate the database schema it will direct you to this NuGet package. Keeping Code First Migrations as a separate package allows us to quickly iterate on this new feature.
Some Features Waiting on .NET Framework 4.5
Since we shipped EF 4.0 as part of .NET 4.0, we started talking about upcoming features as “EF vNext” features. When we then released EF 4.1 and more recently published the EF 4.2 previews, many of you logically asked why those features weren’t included.
While the out-of-band approach has worked well for the DbContext API, Code First and Code First Migrations, the fact is that there are some other features, such as enum type support, that inherently require us to update the core libraries that we previously shipped as part of .NET.
The obvious solution to this is to ship the entire Entity Framework independent of the .NET Framework. The June 2011 CTP was our first attempt at doing this. While we are still pursuing this option it has become clear that from a technical standpoint we are not ready to achieve this immediately. Because of this our new features that require updates to our core libraries will need to wait for the next .NET Framework release. This includes support for Enum Types, Spatial Types, Table-Valued Functions, Stored Procedures with Multiple Results and Auto-Compiled LINQ Queries.
These features will reappear in a preview of Entity Framework that we will ship alongside the next public preview of .NET 4.5.
Summary
In summary, when we talk about “Entity Framework” we are now going to be talking mainly about the out-of-band features that we ship as the EntityFramework NuGet package. Entity Framework is built on the .NET Framework and will make use of the EF core libraries that ship with the .NET Framework, including System.Data.Entity. The EF specific tooling that ships with Visual Studio will always work with the latest version of EF.
Comments
Anonymous
October 18, 2011
I really like the focus on understandable version numbers and more frequent feature releases. Thanks!Anonymous
October 18, 2011
That's a shame that you can't ship it out of band from .NET. The .NET BCL should be a dependency of EF, not EF being a part of .NET. Oh well...Anonymous
October 18, 2011
You say: "In the future we hope to move the classes from System.Data.Entity.dll into the EntityFramework NuGet package so that we can release features such as Enums without having to wait for a .NET Framework update." An later: "Because of this our new features that require updates to our core libraries will need to wait for the next .NET Framework release. This includes support for Enum Types, Spatial Types, Table-Valued Functions, Stored Procedures with Multiple Results and Auto-Compiled LINQ Queries." Can we expect this new features on .NET 4.0 with NuGet package or not?Anonymous
October 18, 2011
@Felipe: The short answer to your question is no. The rest is explained in the blog post, but in case I can make it clearer: We wanted to go out of band of .NET so that we could be able to ship those features sooner and then to ship more of those kinds of features more frequently. The June CTP was an attempt to build the out of band solution but we hit several technical difficulties, including disruptions to the experience for developers using EF today, for ADO.NET provider writers, and users of ASP.NET. The decision was to keep the EF core libraries in the .NET framework where they live today, so we will update them again when .NET 4.5 comes out. When we say we would still want to take those classes out of the framework in the future, it means we still want to take the out-of-band approach for the whole EF, however we have several technical challenges to fix and we haven’t figured out the details yet, so this is not something we think we can do in the short term. I hope this answers your question.Anonymous
October 18, 2011
and ... apparently there is no .NET 4.5 for XP, so you mean no Enum etc for XP ? also, it takes ages for those web hosting sites to upgrade to .NET 4.5Anonymous
October 18, 2011
Please add support for ToString(). In L2S it's even possible to call any C# function in select section. Unfortunately, that's not the case with EF.Anonymous
October 18, 2011
Maybe you should provide more expansibility like it is in ASP.NET MVC. For example instead of focus on implementing spatial and enums you should provide ability to support custom types (enums, spatials, string arrays, etc. - this could resolve a lot of issues from data.uservocie.com) or provide interceptors for queries and navigation properties.Anonymous
October 18, 2011
Int.ToString() would be very handy!Anonymous
October 18, 2011
Semantic versioning: great! NuGet: great! Thanks for listening!Anonymous
October 18, 2011
@Diego B Vega, thanks for the answers! It was not what I wanted to hear, but I hope you get to this goal in the next release after v4.5. Maybe even release the source code as the ASP.NET MVC did =)Anonymous
October 18, 2011
The comment has been removedAnonymous
October 18, 2011
Shouldn't this article be renamed to "Architecture strikes back"? Because that is really what the second part of the article describes. You cannot add core features because EF architecture is not opened for extensibility and and every new feature requires changes in core libraries which are currently shipped only with .NET framework. What is even worse it looks like you are going to continue with this approach because enum and stored procedures with multiple result sets are just another exampled of features which should be refactored to more generic solution - namely Type conversions supporting conversions in mapping and batch queries supporting multiple result sets for any type of query (not only stored procedure) - that would open possibility to many new features.Anonymous
October 19, 2011
@m & Andy: Thanks for your feedback. Please add/vote for this feature in our uservoice site: http://ef.mswish.net.Anonymous
October 19, 2011
@Diego, I think that site is for voting "new" features! .ToString, this is something that L2S had 3 years before EF,. But EF didn't manage to get feature parity with L2S even after 3 versions and 4 years later. I mean really do you want us waste votes on that ? an not on bigger feature requests? This is something we should have got at V1 in the first place, and not something we should give our votes for. My 2cAnonymous
October 19, 2011
@Eric: We don't have a public backlog or roadmap document at the moment. I agree it would be a good idea to have something like that. I will check if there is a way to at least mark the features we are working on in the UserVoice site. In any case, we often don’t talk about everything we are doing mainly because we know the particular set of features we end up releasing is subject to changes and we want to avoid disappointing customers when we need to make cuts. I can assure you we build Entity Framework for customers to be able to use it, and therefore we give customer feedback the highest importance when deciding our priorities :-) We also like to think about this blog and our design blog (http://blogs.msdn.com/efdesign) as great places to have conversations with customers, what they need and what we can do. If you perceive a disconnect between what we are doing and what the community is asking, hopefully we will be able to close the gap. To give you some concrete numbers: from the top 15 feature requests in our UserVoice site, 9 are included in either the next version of .NET or of one of our out of band releases. If we are not doing all 15 of them at once is because we don’t have enough resources or time!Anonymous
October 19, 2011
@Catalin: Thanks for taking the time to provide your feedback. It is not always the case that because a particular feature was in LINQ to SQL v1 then it is automatically in the radar for EF. Feature parity with LINQ to SQL is among the criteria we use, but we need to prioritize features globally to our best understanding of customer needs and according to the engineering resources and time we have available, existence of workarounds, etc. In the particular case of ToString, we apparently have the basic capabilities to implement it but somehow it has never bubbled up to the top of the list. In fact, I looked at the UserVoice site and I couldn’t find a single mention to the ToString method, so I have just added it myself: data.uservoice.com/.../2327346-support-tostring-method-in-linq-to-entities Feel free to vote if this is important for you, and to add a comment if you can provide a more compelling scenario to the one I came up with.Anonymous
October 19, 2011
@Ladislav: You make valid points: First of all, we are not yet where we would like to be on extensibility. Also, I think we agree on the importance of type conversion and batch query support. However, when we looked at the priority of enums and multiple results support for stored procedures we decided that there was enough customer value in these features that we didn’t want to wait until we had fully implemented and tested the more general solutions. Also we had to face the reality that if we decided to wait there was a serious risk that we couldn’t deliver enum support and the stored procedure improvements in the next release of .NET. In the end, some parts of the implementation turned out to be orthogonal to the more general solution. That said, I think in the future it should still be possible to refactor things to incorporate type conversion and batch query support in such a way that enums and multiple results for stored procedures share some of the same code.Anonymous
October 19, 2011
@Slawek: I missed your comment before. The same thing I responded to Ladislav applies to spatial type support: it was important enough that we didn't want to wait to get it in. Also, it turns out that implementing the feature in a provider agnostic way and supporting rich spatial functionality in queries required more work than what doing type conversion support would have provided (although you could argue that sophisticated extensibility points could allow anyone to register translations for all sorts of operations over custom types).Anonymous
October 19, 2011
@Diego: If you believe that you can refactor current solution to more generic in future version, I'm satisfied with that. I agree that having some new features is of course better than none even if I would expect little bit more. I have a few more questions. I don't see unique keys listed in features expected in .NET 4.5. That feature was previewed in the article few months ago and I think many developers really look forward to it. Do you plan to include unique key support as well? Do you also plan to improve SQL query generations / performance in some way (like already presented improvements for TPT inheritance mapping)? My last question is more related to ADO.NET team. Can you share how many people (developers / QA engineers) are working on EF related features?Anonymous
October 20, 2011
So by .NET 4.5 we might almost have a viable 1.0 product that can support basic .NET types that have been in existence since .NET 1.0? Impressive guys. Building on the shoulders of giants. EF is like being able to watch a car accident in slow motion where, unfortunately, many of us are watching from inside the car.Anonymous
October 21, 2011
Sounds to me like this number scheme came from Scott Hanselman :)Anonymous
October 21, 2011
@Hector: Nice to hear from you! Indeed, Scott advocates a lot for semantic versioning :) Some time ago he wrote a blog post (www.hanselman.com/.../RequestForCommentsIssuesWithNETAndMicrosoftProductVersioning.aspx) asking for feedback on this and he also created a survey. The overwhelming a response from the developer community was that semantic versioning is a much better alternative than named versions like "EF 4.1 Update 1".Anonymous
October 24, 2011
@Ladislav - Unique keys is precisely one of those features that Diego was referring to when he said, "we want to avoid disappointing customers when we need to make cuts." Unique keys won't make it into this version of EF, although we really wanted it to and agree that it's very important. SQL query improvements are one of the items that are perpetually on our list. We do have some specific things we want to accomplish there but balancing performance of SQL versus feature set is always a difficult task. If you have a specific scenario where we generate particularly bad SQL, please tell us about it with the "E-mail blog author" link in the right nav bar. There's certainly potential for us to get some things in as bugs. @Kevin - I don't want this to come off as an excuse or anything else (we recognize that we have a long ways to go) but I will say that there are other really good ORM solutions out there and we certainly don't expect EF to be the right choice for everyone. If EF doesn't meet your needs I'd encourage you (honestly) to look at nHibernate, Dapper, Massive, Simple.Data or any one of the many other good solutions out there. On another note, I can understand your frustration with the perceived speed of progress - I felt the same way myself before I joined Microsoft four months ago. The difference now is not just the three weeks of brainwashing I received during orientation, but the fact that I see this team work every day. There is no doubt that this team is more intelligent and focused on meeting customer needs than any other team I've been a member of in my ~15 year career. You're still allowed to be frustrated, but try to recognize that this team is working really hard to prioritize and meet needs for developers who make software used by billions of people.Anonymous
October 31, 2011
Very good post. Loads of information. Also, read this post from msguy on What's new and expected in .NET Framework 4.5 www.msguy.com/.../whats-new-and-expected-in-net-framework.htmlAnonymous
November 02, 2011
Any instructions our guidelines on how to make codefirst work on vs2011 dev preview on windows 8? I tried nugget install-package EntityFramework and got "current env does not support solution pen"Anonymous
February 09, 2012
Could you please elaborate how NuGet should work in a real world environment where developers won't have direct internet access and permission to install software aquired from the internet in such a direct way ? I feel that the NuGet approach for the hobbyist world is very nice, but in an enterprise environment with different layers of security.Anonymous
February 10, 2012
@Peter Kellner - We will be releasing an "EF 5.0 Beta 1" version of our NuGet package alongside the next preview of Visual Studio. This will enable Code First for .NET 4.5 applications.Anonymous
February 10, 2012
@nojetlag – It seems to be less and less common for developers not to have internet access, and we are seeing NuGet being used by a wide range of developers (from hobbyists up to large enterprises). You can setup an internal NuGet feed, that just contains the packages your organization has approved to use; docs.nuget.org/.../hosting-your-own-nuget-feeds. A NuGet package is also just a zip file, so you can also just unzip it and get the assembly, they you are free to GAC etc.Anonymous
February 11, 2012
@nojetlag I just blogged with a few more details on why we're using NuGet: blog.oneunicorn.com/.../why-entity-framework-is-releasing-on-nuget-onlyAnonymous
July 29, 2012
When EF will suppurt FileTables in SQL Server 2012??Anonymous
July 30, 2012
@David - We don't have any plans to introduce File Table support at this stage. You can always open a feature request at entityframework.codeplex.com/.../Create.