The official source of information on Managed Providers, DataSet & Entity Framework from Microsoft
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.
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:
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.
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.
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.