Announcing the Plan for EF7

Jeremy

Today we are excited to share with you the plan for Entity Framework Core 7. This plan brings together input from many stakeholders and outlines where and how we intend to invest in Entity Framework Core 7 (EF Core 7). For brevity, EF Core 7.0 is also referred to as just EF7.

The plan is being tracked through GitHub dotnet/efcore repo issue #26994 and any updates will be posted there.

IMPORTANT This plan is not a commitment; it will evolve as we continue to learn throughout the release. Some things not currently planned for EF7 may get pulled in. Some things currently planned for EF7 may get punted out.

To review the plans for other products, areas, and .NET 7 overall, visit and read the ThemesOf.Net.

General information

EF Core 7 is the next release after EF Core 6 and is currently scheduled for release in November 2022 at the same time as .NET 7. There are no plans for an EF Core 6.1 release.

EF7 will align with the .NET support policy and will therefore will not be a long-term support (LTS) release.

EF7 currently targets .NET 6. This may be updated to .NET 7 as we near the release. EF7 does not target any .NET Standard version; for more information see the future of .NET Standard. EF7 will not run on .NET Framework.

Themes

The large investments in EF7 will fall mainly under the following themes.

Highly requested features

As always, a major input into the planning process comes from votes (👍) for features on GitHub.

.NET platforms and ecosystem

Much of the work planned for EF7 involves improving the data access experience for .NET across different platforms and domains. This involves work in EF Core where needed, but also work in other areas to ensure a great experience across .NET technologies.

Clear path forward from EF6

EF Core has always supported many scenarios not covered by the legacy EF6 stack, as well as being generally much higher performing. However, EF6 has likewise supported scenarios not covered by EF Core. EF7 will add support for many of these scenarios, allowing more applications to port from legacy EF6 to EF7. At the same time, we are planning a comprehensive porting guide for applications moving from legacy EF6 to EF Core.

Performance

Great performance is a fundamental tenet of EF Core, lower-level data access, and indeed all of .NET. Every release includes significant work on improving performance.

Find out more and give feedback

This post is a brief summary of the full EF7 plan. Please see the full plan for more information.

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

In addition, please comment on the plan issue (#26994) if you believe we are missing something that is critical for EF7, or are focusing on the wrong areas.

10 comments

Leave a comment

  • Harold Harkema

    Please focus on stability. EF core has big issues with SqlClient. For example huge performance issues when ToListAsync is used with nvarchar(max) colmns.

  • Daniel Smith

    The renaming of .NET Core 5 to simply .NET 5 was a very welcome simplification.

    Can’t the unnecessary “core” part of the product name also be dropped for EF7 since it finally moves passed the EF6 numbering?

    • Kalle Niemitalo

      If new virtual methods that minimize memory allocations are added to types like System.Data.Common.DbDataReader, they can then be overridden in Microsoft.Data.SqlClient and other providers, and libraries can use them without depending directly on Microsoft.Data.SqlClient. I expect they won’t be overridden in System.Data.SqlClient, though.

    • Asad Mehmood

      Hi @james, this syntax might interest you. This will result in simple left outer join query. If you remove DefaultIfEmpty(), the resultant query will be inner join

      var query = (from a in context.Alpha
      from b in context.Beta.Where(x=>x.Id == a.Id).DefaultIfEmpty()
      select new {
      a.Field1,
      b.Field2
      })
  • hitesh davey

    Suggestion: Pl, add the “BeforeExecute” event to trap and analyze all SQL/DDL/DML statements. This will also help us make changes to generated source statement(s) on the fly. VB6 ADO connection object had this event exposed and was very handy in many challenging scenarios.