Announcing Entity Framework Core 3.0 Preview 4
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.3Or from the Package Manager Console in Visual Studio:
PM> Install-Package Microsoft.EntityFrameworkCore.Sqlite -Version 3.0.0-preview4.19216.3See 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.3For 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 FromSqlRaw, FromSqlInterpolated, ExecuteSqlRaw, 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.
Closing
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.
Light
Dark
51 comments
I was running Preview 3 for a WPF application, which was working perfectly. After installing Preview 4, the tooling no longer works, an several things are now broken in both Visual Studio 2017 and 2019. Even after removing Preview 4, and performing repairs on both versions of Visual Studio, everything is still broken.
What is broken:
– It is now impossible to open the WPF designer in Visual Studio 2017. It will show, “Invalid Markup”, “Check the Error List for more information.” Every single element is tagged as, “<Element> is not supported in a Windows Presentation Foundation (WPF) project.”
– Project properties windows are broken when the instance of Visual Studio is on a monitor that is using anything other than a Scale of 100%.
I have installed and uninstalled it several times, including Update 3, in hopes that the older tools would reinstall. This has not happened. How can I force the pre-Preview 4 tools to install?
What you are describing seems to be a problem with Visual Studio tooling. The best way forward is to report it as a problem. Follow the guidance at https://docs.microsoft.com/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019
When you say that EF Core 3.0 will require .NET Standard 2.1. Does this means that we cannot use it in ASP.NET WebForms?
That is correct. Web Forms only runs on the full .NET Framework and .NET Framework doesn’t support .NET Standard 2.1 and won’t support it in the future. You are now stuck using the old version of EF Core from here on out.
Thanks for leaving Web Forms developers high and dry Microsoft by not porting it to .NET Core. Now, I will be stuck on an old version of EF Core as well. Not porting Web Forms is a very poor decision IMHO. Especially, when you ported Windows Forms and WPF. Maybe this is why everyone is switching to Python. If you weren’t busy claiming IE was an integral part of the OS, maybe you could have made .NET Framework multi-platform to begin with and wouldn’t have to screw your customers over with a bunch of half baked changes.
Am I correct in understanding the most imporant difference of EF core vs EF 6+ is that EF core is more like using LINQ syntax/usability with Ef functionality?
I am not sure what you mean. Both versions of EF support LINQ. I recommend you look at our documentation.
thank you for the article. to clarify what i was saying previously, I had read that one of the downsides of using ef6 was that, like hibranate, it is overly complicated and difficult to work with such as joins and what not. In contrast, linq to sql had a more favorible opinion but perhaps not as robust as ef. EF core was supposed to marry the 2 worlds together in a positive way i.e. ease of use, powerful capabilities. This comes from what I am seeking to learn and get used to in the .net / core world.
Если устранить эту ошибку то будет намного лучше. Could not load file or assembly ‘Microsoft.Extensions.DependencyInjection.Abstractions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60’. Не удается найти указанный файл.
If you can reproduce this, please create an issue on https://github.com/aspnet/entityframeworkcore/issues/new with a repro project attached.
Are there preview builds available of EF 6.3? I would love these to release alongside the Core 3.0 previews. This is the last major piece preventing our organization from migrating several products.Information about this has been spotty at best. Where is the best place to get up to date information? (The GitHub release page is stagnant)
Now there are! Read this post for more details.
Great to see those improvements around InMemory database and unit testing. I was just struggling with auto-incremented IDs for entities created under test clashing with IDs of initial seed assigned with HasData calls. Gonna try the preview later today. Will make my day if it starts incrementing from last seeded id.
Thanks. Hope to hear from you how it worked and please report any issues.
Another nail in the .Net Framework coffin with EF Core 3.0 (possibly the first production ready version) dropping support. Hopefully it won’t be the nail in the EF Core coffin as serious and legacy enterprise developers decide against even trying EF Core 3.0.