Entity Framework Core 1.1 Plans

July 29th, 2016

Now that Entity Framework Core (EF Core) 1.0 is released, our team is beginning work on bug fixes and new features for the 1.1 release. Keep in mind that it’s early days for this release, we’re sharing our plans in order to be open, but there is a high chance things will evolve as we go.

High level goals

Our goal with 1.1 release is to make progress on the items that are blocking folks from using EF Core.

Fix a lot of the bugs reported on the 1.0 release in order to improve stability

Tackle a number of critical O/RM features that are currently not implemented in EF Core

Timeframe

EF Core 1.1 is scheduled for Q4 2016 / Q1 2017. We’ll have a more exact date as we get closer to the release and decide where to draw the line on features to be included.

What features are we working on

Over the next couple of months we are beginning work on a number of features. Some we expect to include in 1.1, others we expect to deliver in a future release.

Features we expect to ship in 1.1

Following is the list of features that our team is expecting to include in the 1.1 release.

LINQ improvements Improved translation to enable more queries to successfully execute, with more logic being evaluated in the database (rather than in-memory). Queries for non-model types allows a raw SQL query to be used to populate types that are not part of the model (typically for denormalized view-model data).

DbSet.Find provides an easy way to fetch an entity based on its primary key value.

provides an easy way to fetch an entity based on its primary key value. Explicit Loading allows you to trigger population of a navigation property on an entity that was previously loaded from the database.

allows you to trigger population of a navigation property on an entity that was previously loaded from the database. Additional EntityEntry APIs from EF6.x such as Reload, GetModifiedProperties, GetDatabaseValues etc.

such as Reload, GetModifiedProperties, GetDatabaseValues etc. Connection resiliency automatically retries failed database commands. This is especially useful when connection to SQL Azure, where transient failures are common.

automatically retries failed database commands. This is especially useful when connection to SQL Azure, where transient failures are common. Pluralization support for reverse engineering will result in singularized type names and pluralized DbSet property names, regardless of whether the table name is singular or plural.

will result in singularized type names and pluralized DbSet property names, regardless of whether the table name is singular or plural. Stable release of tools – whilst the runtime has reached RTM, the tooling for EF Core (plus .NET Core and ASP.NET Core) is still pre-release.

Other features we’re starting on

We’re also planning to start work on the following features, but do not expect them to be ready in time for inclusion in the 1.1 release. These features will require a longer time to implement, stabilize, and gather feedback from the community and therefore they will have a longer pre-release cycle.

Complex/value types are types that do not have a primary key and are used to represent a set of properties on an entity type.

are types that do not have a primary key and are used to represent a set of properties on an entity type. Simple type conversions such as string => xml.

such as string => xml. Visual Studio wizard for reverse engineering a model from an existing database.

Will EF Core replace EF6.x after the 1.1 release

The short answer is no. EF6.x is still the mature, stable data access stack and will continue to be the right choice for many applications when EF Core 1.1 is available. Along with EF Core 1.1, we are also starting work on the EF6.2 release – we’ll share our plans on that shortly. That said, EF Core will be a viable choice for more applications once 1.1 is released. Our documentation has guidance on choosing between EF6.x and EF Core, and this same guidance will apply when 1.1 is released.

Notable exclusions

The full backlog of features that we want to add to EF Core is too long to list here, but we wanted to call out a few features that we know are critical to a lot of applications and will not be worked on in the 1.1 timeframe. This is purely a matter of not being able to work on every feature at the same time, and the order in which things must be implemented. As an example, Lazy Loading will build on top of some of the feature work we are doing in the 1.1 timeframe (such as Explicit Loading).

While we realize this list will cause frustration for some folks, we want to be as transparent as possible so that you all have the information required to make an informed decision about when EF Core would be the right choice for you.