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 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. If none of these options work, you can use raw SQL queries instead.
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 highly 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, when the database is deleted, key generation is reset and starts at 1, and 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 to be three times faster. You should still consider calling ToObservableCollection() if you are going to iterate multiple times.
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 contained no 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 in 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?
So far, in this release we have focused most of our efforts on the improvements that we believe 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 in the release gives us more time to gather feedback and react to unanticipated issues. It also means that many important features will be completed in later previews.
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.
You can expect at least initial support for most of these features to arrive within the next couple of .NET Core 3.0 preview cycles.
We would like to take this opportunity to provide additional information on our progress towards those goals, and 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 of EF Core 3.0 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.
The post Announcing Entity Framework Core 3.0 Preview 4 appeared first on .NET Blog.