Announcing Entity Framework Core 3.0 Preview 4

Diego Vega

Today, we are making the fourth preview of Entity Framework Core 3.0 available on NuGet, alongside .NET Core 3.0 Preview 4 and ASP.NET Core 3.0 Preview 4. We encourage you to install this preview to test the new functionality and assess the impact of the included breaking changes.

What’s new in EF Core 3.0 Preview 4?

This preview includes more than 50 bug fixes and functional enhancements. You can query our issue tracker for the full list of issues fixed in Preview 4, as well as for the issues fixed in Preview 3, and Preview 2.

Some of the most important changes are:

LINQ queries are no longer evaluated on the client

The new LINQ implementation that we will introduce in an upcoming preview will not support automatic client evaluation except on the last select operator on your query. In preparation for this change, in preview 4 we have switched the existing client evaluation behavior to throw by default.

Although it should still be possible to restore the old behavior by re-configuring client evaluation to only cause a warning, we recommend that you test your application with the new default. If you see client evaluation exceptions, you can try modifying your queries to avoid client evaluation. If that doesn’t work, you can introduce calls to AsEnumerable() or ToList() to explicitly switch the processing of the query to the client in places where this is acceptable. You can use raw SQL queries instead of LINQ if none of these options work for you.

See the breaking change details to learn more about why we are making this change.

If you hit any case in which a LINQ expression isn’t translated to SQL and you get a client evaluation exception instead, but you know exactly what SQL translation you expect to get, we ask you to create an issue to help us improve EF Core.

The EF Core runtime is no longer part of the ASP.NET Core shared framework

Note that this change was actually introduced in Preview 1 but was not previously announced in this blog.

The main consequence of this change is that no matter what type of application you are building or what database your application uses, you always obtain EF Core by installing the NuGet package for the EF Core provider of your choice.

In any operating system supported for .NET Core development, you can install the preview bits by installing a provider for EF Core 3.0 Preview 4. For example, to install the SQLite provider, type this in the command line:

$ dotnet add package Microsoft.EntityFrameworkCore.Sqlite -v 3.0.0-preview4.19216.3

Or from the Package Manager Console in Visual Studio:

PM> Install-Package Microsoft.EntityFrameworkCore.Sqlite -Version 3.0.0-preview4.19216.3

See the breaking change details for more information.

The dotnet ef tool is no longer part of the .NET Core SDK

This change allows us to ship dotnet ef as a regular .NET CLI tool that can be installed as either a global or local tool.For example, to be able to manage migrations or scaffold a DbContext, install dotnet ef as a global tool typing the following command:

$ dotnet tool install --global dotnet-ef --version 3.0.0-preview4.19216.3

For more information, see this breaking change’s details.

Dependent entities sharing tables with their principal entities can now be optional

This enables for example, owned entities mapped to the same table as the owner to be optional, which is a frequently requested improvement.

See issue #9005 for more details.

Key generation improvements for in-memory database

We have made several improvements to simplify using in-memory database for unit testing. For example, each generated property now gets incremented independently. Also, when the database is deleted, key generation is reset and starts at 1. Finally, if a property in an entity contains a value larger than the last value returned by the generator, the latter is bumped to start on the next available value.

For more details, see issue #6872.

Separate methods for working with raw SQL queries as plain strings or interpolated strings

The existence of method overloads accepting SQL as plain strings or interpolated strings made it very hard to predict which version would be used and how parameters would be processed. To eliminate this source of confusion, we added the new methods FromSqlRawFromSqlInterpolatedExecuteSqlRaw, and ExecuteSqlInterpolated. The existing FromSql and ExecuteSqlCommand methods are now obsolete.

See issue #10996 for more details.

Database connection no longer remains open until a TransactionScope is disposed

This makes EF Core work better with database providers that are optimized to work with System.Transactions, like SqlClient and Npgsql.

See this breaking change’s details for more information.

Code Analyzer that detects usage of EF Core internal APIs

EF Core exposes some of its internal APIs in public types. For example, all types under nested EF Core namespaces named Internal are considered internal APIs even if they are technically public types. In the past, this made it easy for application developers and provider writers to unintentionally use internal APIs in their code. With this new analyzer, using EF Core internal APIs produces a warning by default. For example:

EF1001: Microsoft.EntityFrameworkCore.Internal.MethodInfoExtensions is an internal API that supports the Entity Framework Core infrastructure and not subject to the same compatibility standards as public APIs. It may be changed or removed without notice in any release.

If the usage is intentional, the warning can be suppressed like any code analysis warning.

See issue #12104 for more details.

Improved performance of iterating over tracked entities using .Local

We have improved the implementation so that iterating over the contents of .Local is around three times faster. If you are going to iterate multiple times, you should still consider calling ToObservableCollection() first.

See issue #14231 for more details.

The concept of query types has been renamed to entities without keys

Note that this change was included in preview 3 but wasn’t previously announced in this blog.

Query types were introduced in EF Core 2.1 to enable reading data from database tables and views that didn’t contain unique keys. Having query types as a separate concept from entity types has proven to obscure their purpose and what makes them different. It also led us to have to introduce some undesired redundancy and unintended inconsistencies in our APIs. We believe the consolidation of the concepts and eventual removal of the query types API will help reduce the confusion.

See the breaking change details for more information.

New preview of the Cosmos DB provider for EF Core

Although the work is still far from complete, we have been making progress on the provider in successive previews of EF Core 3.0. For example, the new version takes advantage of the new Cosmos DB SDK, enables customizing the names of properties used in the storage, handles value conversions, uses a deterministic approach for key generation, and allows specifying the Azure region to use.

For full details, see the Cosmos DB provider task list on our issue tracker.

What’s next?

As detailed in our list of new features, in 3.0 we plan to deliver an improved LINQ implementation, Cosmos DB support, support for C# 8.0 features like nullable reference types and async collections, reverse engineering of database views, property bag entities, and a new version of EF6 that can run on .NET Core.

In the first 4 previews, we focused most of our efforts on the improvements that we believed could have the highest impact on existing applications and database providers tying to upgrade from previous versions. Implementing these “breaking changes” and architectural improvements early on gives us more time to gather feedback and react to unanticipated issues. But it also means that many of those important features have had to wait until later previews. At this point, you can expect initial support for most of the 3.0 features to arrive within the next couple of preview cycles.

In order to make it easier for you to track our progress, from now on, we will be posting weekly status updates on GitHub. You can subscribe to notifications to get an email every time we post an update.

We would also like to take this opportunity to talk about important adjustments we are making moving forward:

EF Core 3.0 will target .NET Standard 2.1

After investigating several options, we have concluded that making EF Core 3.0 target .NET Standard 2.1 is the best path to take advantage of new features in .NET and C#, like integration with IAsyncEnumerable<T>. This is consistent with similar decisions announced last year for ASP.NET Core 3.0 and C# 8.0, and enables us to move forward without introducing compatibility adapters that could hinder our ability to deliver great new functionality on .NET Core down the road.

Although Preview 4 still targets .NET Standard 2.0, the RTM version will require 2.1 and therefore will not be compatible with .NET implementations that only support .NET Standard 2.0, like .NET Framework. Customers that need to run EF Core on .NET Framework, should plan to continue using EF Core 2.1 or 2.2.

EF 6.3 will target .NET Standard 2.1, in addition to already supported .NET Framework versions

We found that the API surface offered by .NET Standard 2.1 is adequate for supporting EF6 without removing any runtime features. In addition to .NET Standard 2.1, the EF 6.3 NuGet package will as usual support .NET Framework 4.0 (without async support) and .NET Framework 4.5 and newer. For the time being, we are only going to test and support EF 6.3 running on .NET Framework and .NET Core 3.0. But targeting .NET Standard 2.1 opens the possibility to have EF 6.3 working on other .NET implementations, as long as they fully implement the standard and don’t have other runtime limitations.


The EF team would like to thank everyone for their feedback and their contributions to this preview. Once more, we encourage you to try out the latest bits and submit any new feedback to our issue tracker.


Discussion is closed. Login to edit/delete existing comments.

  • Julie Lerman 0

    I’m happy to read about the many things fixed….making existing features even better. THanks for all the great work. Let’s just copy & paste this blog post into my MSDN Mag Data Points column! 🙂

    • Diego VegaMicrosoft employee 0

      Oh, I am sure you can do a much better job than this, but I am happy to collaborate!

  • Anton Goretsky 0

    Am I right that it will be possible to use EF6 with .NET Core 3 on Linux?

    • Diego VegaMicrosoft employee 0

      Yes, that is the plan.

  • Neil Walker 0

    Does it support lazy loading yet and have decent integration into visual studio like ef6, eg using the gui to create a code first from database… 

    • Diego VegaMicrosoft employee 0

      We do support lazy loading since EF Core 2.1. See what’s new in EF Core 2.1 for more details.

      We don’t build GUI tooling for EF Core in Visual Studio, but there are Visual Studio tools that call into our code to reverse engineer a database into a code first model, like EF Core PowerTools. This tool is maintained by ErikEJ who is one of our great open source contributors. 

      • Paulo Pinto 0

        Buying a third party GUI tool just because Microsoft decided EF6 isn’t good enough to keep developing isn’t an option to us.
        If we are forced to migrate and live without proper support from Microsoft, we rather invest in third party ORMs, who knows when you will change your mind regarding EF Core also not being good enough.

        • Diego VegaMicrosoft employee 0

          I hear you. And I am interested in knowing what kind of functionality exactly you feel blocked with without having it in a GUI tool. Also, to clarify, EF Core Power Tools is a free tool.

          • Paulo Pinto 0

            Not being able to keep our EF6 workflows.
            Apparently Microsoft is too eager to please UNIX devs nowadays, dropping everything that requires plain old Visual Studio.

          • Jon Miller 0

            Can’t believe this new massively slow blog software doesn’t even allow thumbs upping comments…

          • Pete Wilson 0


  • Vitor Correia 0

    Sad not to hear anything about stored procedure fields mapping 🙁

    • Diego VegaMicrosoft employee 0

      Victor, can you explain what you mean by “stored procedure fields mapping”? For what it’s worth, reading data from calls to stored procedures can easily be done with our FromSqlRaw()/FromSqlInterpolated() APIs.

      • Dickens, Terry 0

        With EF 6, you can select “Update Model from Database”.  Select a Stored Procedure.  Then you can easily call the SP.  Can you explain why you took away the ability to “Update Model from Database”?  And the ability to easily call stored procedures?  
        What I really liked about EF 6 was that it was so easy to use.  Having the ability to easily add tables and stored procedures was huge.  Using a command line with EF Core seems like several steps backward.  And then having to call stored procedures by executing a SQL command is another big step backward.
        It sounds like EF core is better behind the scenes.  Meaning that it runs faster.  But you’ve really hurt this developers productivitiy by removing the ability to easily add tables and stored procedures to my model.  And by not supporting stored procedure calls as easily as you did in the past.

        • Diego VegaMicrosoft employee 0

          Thanks for the feedback. I understand that this can be significan gaps. The explanation is that we haven’t had the opportunity to address this experience because we have been busy working on other features, and also porting EF6 to work on .NET Core. 

          BTW, update model from database has historically been a very problematic and limited feature in the EF designer. I understand that for this particular scenario, it satisfied your needs, though. We have been working on a design for this in EF Core, and I believe it is much more solid and comprehensive, but unfrotunately it is still sitting in our backlog at

          Scaffolding of stored procedures in the model is also in our backlog at Currently we don’t do this for the initial reverse engineering either, so we should consider it as orthogonal to update model from database. 

    • Zach Painter 0

      Yes, I agree… I think there should be a better way to implement stored procedures as a method on your context.
      The workaround is to create a model type to represent the result set shape and create a DbQuery<T> property on the context.Then define a method on the context that calls the FromSqlRaw / FromSqlInterpolated methods.
      public DbQuery<ResultType> NameOfDbQueryProperty { get; set; }
      public List<ResultType> GetStoreProcedureResults(string parameter){    return this.NameOfDbQueryProperty.FromSqlInterpolated($”MyStoredProcedure {parameter}”).ToList();}
      I feel like there should be a cleaner way of achieving this. Maybe like declaring a DbStoredProcedure<T> property with configuration options for acceptable parameters or something… Not sure how you would achive this… 
      Or maybe a return type interface that will generate the dummy, on the fly DbQuery<T> property so that the raw sql methods can be called to execute the stored procedure.
      Just ideas.. 🙂

  • Kalil Armstrong 0

    I imagine the full justification for why .NET Core 2.1 is being targeted over 2.0 is probably too extensive to condense into a blog post, but is there going to be a functional process for these updates to .NET Core that indicate to businesses when and why they should audit their code bases to migrate for future functionality?
    I’m personally fine with the change, but with the number of frameworks (including Angular 2/3/4/5/6/7) out, it’d be nice to see Microsoft being proactive in this area.
    Lastly – is there a section listing the major differences between what’s in 2.0 and what’s planned for 3.0, or should I just check out each of the weekly status updates?
    Thanks for your work.

    • Diego VegaMicrosoft employee 0

      > the full justification for why .NET Core 2.1 is being targeted over 2.0

      I assume you are referring to .NET Standard. 

      > is there going to be a functional process for these updates to .NET Core that indicate to businesses when and why they should audit their code bases to migrate for future functionality?

      I am not sure I understand the question. Do you mean making sure you are not using APIs that are deprecated? Or having an easy way to track if you have dependencies that support .NET Standard 2.0 today, but the next version may not? 

      > is there a section listing the major differences between what’s in 2.0 and what’s planned for 3.0

      If you are referring to EF Core, the best place to look at the list of the big features we have planned is What’s new in EF Core 3.0 in the documentation. If you want to look into the full, including smaller enhancements and bug fixes, you can query our issue tracker. In this blog, I included several queries for issues already fixed in the previews, under the title What’s new in EF Core 3.0 Preview 4. You can also look at the active issues for the 3.0 milestone.

  • Renan Lopes 0

    Any word on many-to -many relationship without exposing the linking table? (As is in EF6). I think many ppl are waiting for this to finnaly migrate to EF Core.

    • Diego VegaMicrosoft employee 0

      Many-to-many without a link entity is not part of the 3.0 release, but it continues to e something we want to support in the future. In fact, the property bag entities feature that is planeed for this release is a stepping stone to get many-to-many later.

      As you know, EF Core can work with databases that have link tables (with or without additional columns besides the keys), but you have to map it to an actual entity, and then write a additional code to traverse two navigation properties instead of one. Some customers wanting to migrate from EF6 to EF Core are able to make this change. If you cannot, for example because you have a very large number of many-to-many associations, another option will give you in the 3.0 timeframe is to keep using EF6, but migrate from .NET Framework to .NET Core.

    • Diego VegaMicrosoft employee 0

      By the way, it may be worth reading about Relase Planing Process to better understand how we decide which features go into each release. 

  • Nadav Beno 0

    When I run the old command for example:
    await dbContext.Posts.FirstOrDefaultAsync(e=>e.Id==1)
    I get this error:
    Error generated for warning ‘Microsoft.EntityFrameworkCore.Query.QueryClientEvaluationWarning: The LINQ expression ‘where…’ could not be translated and will be evaluated locally.’. This exception can be suppressed or logged by passing event ID ‘RelationalEventId.QueryClientEvaluationWarning’ to the ‘ConfigureWarnings’ method in ‘DbContext.OnConfiguring’ or ‘AddDbContext’.”

    What can I do about that?
    I’ve tried in the startup class:
    .ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning))
    Didn’t help….
    What should I do?

      • Nadav Beno 0

        Yeah, did it

        • Diego VegaMicrosoft employee 0

          Thank you! I responded there.

  • Rob Perry 0

    Still no mention of Always Encrypted? Disappointing..

    • Diego VegaMicrosoft employee 0

      In case you haven’t heard, Always Encrypted is coming on .NET Core 3.0. It just wasn’t ready for this preview and it wasn’t mentioned in the EF Core 3.0 plans much because it is fundamentally a feature of the database server and ADO.NET provider. Anyway, we do plan to conduct some testing on EF Core to make sure the feature lights up correctly and the experience is good. 

      • Diego VegaMicrosoft employee 0

        FYI, Always Encrypted support for .NET Core is included in the new Microsoft.Data.SqlClient provider announced this week. See this post for more information. 

  • Mahdi Hosseini 0

    tnx for your great works,
    what is difference between ef core 3 and new ef 6?
    why we need new ef6 while ef core 3 can run on linux?

    • Diego VegaMicrosoft employee 0

      Aside from cross-platform, the other differences called out in this comparison still apply. Most importantly, EF Core is a modern codebase that is more lightweight and is allowing us to add new features more rapidly, and is the one we recommend for new applications. EF6 is an older codebase that at this stage we are trying to keep as stable as possible, while still accepting small improvements and bug fixes.

  • Guilherme Battista 0

    After upgrading from Preview3 to Preview4, the “IPluralizer” interface disapeared from the Microsoft.EntityFrameworkCore.Design namespace. Where is it?

    • Guilherme Battista 0

      So after some research, I discovered that the Assembly “Microsoft.EntityFrameworkCore.Design” was not being referenced, even after installing the package “Microsoft.EntityFrameworkCore.Design” with nuget. The issue is resolved after referencing the Microsoft.EntityFrameworkCore.Design.dll assembly directly.

      • Alex Nguyen 0

        For me, the breaking difference between Preview3 and Preview4 was the fact that it adds PrivateAssets and IncludeAssets:
        <PackageReference Include=”Microsoft.EntityFrameworkCore.Design” Version=”3.0.0-preview4.19216.3″>
        <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
        </PackageReference>If I remove it, it works, even in Preview7.
        <PackageReference Include=”Microsoft.EntityFrameworkCore.Design” Version=”3.0.0-preview7.19362.6″/>
        I have no idea what the ramifications of removing those XML elements are.

      • Alex Nguyen 0

        For me, the fact that it added the PrivateAssets and IncludeAssets elements was the breaking issue.
        <PackageReference Include=”Microsoft.EntityFrameworkCore.Design” Version=”3.0.0-preview4.19216.3″>
        <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
        </PackageReference>If I remove it, it works, even in Preview7.
        <PackageReference Include=”Microsoft.EntityFrameworkCore.Design” Version=”3.0.0-preview7.19362.6″/>
        I have no idea what the ramifications of removing those XML elements are.

      • Alex Nguyen 0

        For me, the fact that it added the PrivateAssets and IncludeAssets elements was the breaking issue.
        “`<PackageReference Include=”Microsoft.EntityFrameworkCore.Design” Version=”3.0.0-preview4.19216.3″>
        <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
        </PackageReference>“`If I remove it, it works, even in Preview7.
        “`<PackageReference Include=”Microsoft.EntityFrameworkCore.Design” Version=”3.0.0-preview7.19362.6″/>“`
        I have no idea what the ramifications of removing those XML elements are.

Feedback usabilla icon