Plan for Entity Framework Core 5.0

As described in the planning process, we have gathered input from stakeholders into a tentative plan for the EF Core 5.0 release.

Important

This plan is still a work-in-progress. Nothing here is a commitment. This plan is a starting point that will evolve as we learn more. Some things not currently planned for 5.0 may get pulled in. Some things currently planned for 5.0 may get punted out.

Version number and release date.

EF Core 5.0 is currently scheduled for release at the same time as .NET 5.0. The version "5.0" was chosen to align with .NET 5.0.

Supported platforms

EF Core 5.0 is planned to run on any .NET 5.0 platform based on the convergence of these platforms to .NET Core. What this means in terms of .NET Standard and the actual TFM used is still TBD.

EF Core 5.0 will not run on .NET Framework.

Breaking changes

EF Core 5.0 will contain some breaking changes, but these will be much less severe than was the case for EF Core 3.0. Our goal is to allow the vast majority of applications to update without breaking.

It is expected that there will be some breaking changes for database providers, especially around TPT support. However, we expect the work to update a provider for 5.0 will be less than was required to update for 3.0.

Themes

We have extracted a few major areas or themes which will form the basis for the large investments in EF Core 5.0.

Many-to-many navigation properties (a.k.a "skip navigations")

Lead developers: @smitpatel and @AndriySvyryd

Tracked by #19003

T-shirt size: L

Status: In-progress

Many-to-many is the most requested feature (~407 votes) on the GitHub backlog. Support for many-to-many relationships can be broken down into three major areas:

  • Skip navigation properties. These allow the model to be used for queries, etc. without reference to the underlying join table entity.
  • Property-bag entity types. These allow a standard CLR type (e.g. Dictionary) to be used for entity instances such that an explicit CLR type is not needed for each entity type.
  • Sugar for easy configuration of many-to-many relationships.

We believe that the most significant blocker for those wanting many-to-many support is not being able to use the "natural" relationships, without referring to the join table, in business logic such as queries. The join table entity type may still exist, but it should not get in the way of business logic. This is why we have chosen to tackle skip navigation properties for 5.0.

At this time the other parts of many-to-many are being pursued as a stretch goal for EF Core 5.0. This means they are not currently in the plan for 5.0, but if things go well we hope to pull them in.

Table-per-type (TPT) inheritance mapping

Lead developer: @AndriySvyryd

Tracked by #2266

T-shirt size: XL

Status: Not started

We're doing TPT because it is both a highly requested feature (~254 votes; 3rd overall) and because it requires some low-level changes that we feel are appropriate for the foundational nature of the overall .NET 5 plan. We expect this to result in breaking changes for database providers, although these should be much less severe than the changes required for 3.0.

Filtered Include

Lead developer: @maumar

Tracked by #1833

T-shirt size: M

Status: Not started

Filtered Include is a highly-requested feature (~317 votes; 2nd overall) that isn't a huge amount of work, and that we believe will unblock or make easier many scenarios that currently require model-level filters or more complex queries.

Rationalize ToTable, ToQuery, ToView, FromSql, etc.

Lead developers: @maumar and @smitpatel

Tracked by #17270

T-shirt size: L

Status: Not started

We have made progress in previous releases towards supporting raw SQL, keyless types, and related areas. However, there are both gaps and inconsistencies in the way everything works together as a whole. The goal for 5.0 is to fix these and create a good experience for defining, migrating, and using different types of entities and their associated queries and database artifacts. This may also involve updates to the compiled query API.

Note that this item may result in some application-level breaking changes since some of the functionality we currently have is too permissive such that it can quickly lead people into pits of failure. We will likely end up blocking some of this functionality together with guidance on what to do instead.

General query enhancements

Lead developers: @smitpatel and @maumar

Tracked by issues labeled with area-query in the 5.0 milestone

T-shirt size: XL

Status: In-progress

The query translation code was extensively rewritten for EF Core 3.0. The query code is generally in a much more robust state because of this. For 5.0 we aren't planning on making major query changes, outside those needed to support TPT and skip navigation properties. However, there is still significant work needed to fix some technical debt left over from the 3.0 overhaul. We also plan to fix many bugs and implement small enhancements to further improve the overall query experience.

Migrations and deployment experience

Lead developers: @bricelam

Tracked by #19587

T-shirt size: L

Status: In-progress

Currently, many developers migrate their databases at application startup time. This is easy but is not recommended because:

  • Multiple threads/processes/servers may attempt to migrate the database concurrently
  • Applications may try to access inconsistent state while this is happening
  • Usually the database permissions to modify the schema should not be granted for application execution
  • Its hard to revert back to a clean state if something goes wrong

We want to deliver a better experience here that allows an easy way to migrate the database at deployment time. This should:

  • Work on Linux, Mac, and Windows
  • Be a good experience on the command line
  • Support scenarios with containers
  • Work with commonly used real-world deployment tools/flows
  • Integrate into at least Visual Studio

The result is likely to be many small improvements in EF Core (for example, better Migrations on SQLite), together with guidance and longer-term collaborations with other teams to improve end-to-end experiences that go beyond just EF.

EF Core platforms experience

Lead developers: @roji and @bricelam

Tracked by #19588

T-shirt size: L

Status: Not started

We have good guidance for using EF Core in traditional MVC-like web applications. Guidance for other platforms and application models is either missing or out-of-date. For EF Core 5.0 we plan to investigate, improve, and document the experience of using EF Core with:

  • Blazor
  • Xamarin, including using the AOT/linker story
  • WinForms/WPF/WinUI and possibly other U.I. frameworks

This is likely to be many small improvements in EF Core, together with guidance and longer-term collaborations with other teams to improve end-to-end experiences that go beyond just EF.

Specific areas we plan to look at are:

  • Deployment, including the experience for using EF tooling such as for Migrations
  • Application models, including Xamarin and Blazor, and probably others
  • SQLite experiences, including the spatial experience and table rebuilds
  • AOT and linking experiences
  • Diagnostics integration, including perf counters

Performance

Lead developer: @roji

Tracked by issues labeled with area-perf in the 5.0 milestone

T-shirt size: L

Status: In-progress

For EF Core we plan to improve our suite of performance benchmarks and make directed performance improvements to the runtime. In addition, we plan to complete the new ADO.NET batching API which was prototyped during the 3.0 release cycle. Also at the ADO.NET layer, we plan additional performance improvements to the Npgsql provider.

As part of this work we also plan to add ADO.NET/EF Core performance counters and other diagnostics as appropriate.

Architectural/contributor documentation

Lead documenter: @ajcvickers

Tracked by #1920

T-shirt size: L

Status: Not started

The idea here is to make it easier to understand what is going on in the internals of EF Core. This can be useful to anyone using EF Core, but the primary motivation is to make it easier for external people to:

  • Contribute to the EF Core code
  • Create database providers
  • Build other extensions

Microsoft.Data.Sqlite documentation

Lead documenter: @bricelam

Tracked by #1675

T-shirt size: M

Status: Completed. The new documentation is live on the Microsoft docs site.

The EF Team also owns the Microsoft.Data.Sqlite ADO.NET provider. We plan to fully document this provider as part of the 5.0 release.

General documentation

Lead documenter: @ajcvickers

Tracked by issues in the docs repo in the 5.0 milestone

T-shirt size: L

Status: In-progress

We are already in the process of updating documentation for the 3.0 and 3.1 releases. We are also working on:

  • An overhaul of the getting started docs to make them more approachable/easier to follow
  • Reorganization of docs to make things easier to find and to add cross-references
  • Adding more details and clarifications to existing docs
  • Updating the samples and adding more examples

Fixing bugs

Tracked by issues labeled with type-bug in the 5.0 milestone

Developers: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

T-shirt size: L

Status: In-progress

At the time of writing, we have 135 bugs triaged to be fixed in the 5.0 release (with 62 already fixed), but there is significant overlap with the General query enhancements section above.

The incoming rate (issues that end up as work in a milestone) was about 23 issues per month over the course of the 3.0 release. Not all of these will need to be fixed in 5.0. As a rough estimate we plan to fix an additional 150 issues in the 5.0 time frame.

Small enhancements

Tracked by issues labeled with type-enhancement in the 5.0 milestone

Developers: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

T-shirt size: L

Status: In-progress

In addition to the bigger features outlined above, we also have many smaller improvements scheduled for 5.0 to fix "paper-cuts". Note that many of these enhancements are also covered by the more general themes outlined above.

Below-the-line

Tracked by issues labeled with consider-for-next-release

These are bug fixes and enhancements that are not currently scheduled for the 5.0 release, but we will look at as stretch goals depending on the progress made on the work above.

In addition, we always consider the most voted issues when planning. Cutting any of these issues from a release is always painful, but we do need a realistic plan for the resources we have.

Feedback

Your feedback on planning is important. The best way to indicate the importance of an issue is to vote (thumbs-up) for that issue on GitHub. This data will then feed into the planning process for the next release.