Announcing Entity Framework Core 3.0 Preview 6 and Entity Framework 6.3 Preview 6
New previews of the next versions of EF Core and EF 6 are now available on NuGet.Org.
What is new in EF Core 3.0 Preview 6
In recent months, a lot of our efforts have been focused on a new LINQ implementation for EF Core 3.0. Although the work isn’t complete and a lot of the intended functionality hasn’t been enabled, before preview 6 we reached a point in which we couldn’t make much more progress without integrating the new implementation into the codebase in the main branch.
IMPORTANT: Although as always, we want to encourage you to experiment with our preview bits in a controlled environment and to provide feedback, preview 6 has significant limitations in the LINQ implementation that we expect to affect any application that performs all but the most trivial queries. Given this, we want to explicitly recommend you against trying to update any applications you have in production to this preview.
While some of the limitations are caused by intentional breaking changes, a lot more are temporary issues we expect to fix before RTM.
These are some of the main things to know:
- Temporary limitation: In-memory database and Cosmos DB providers aren’t functional in this preview: In the initial phase of the switch to the new implementation, we have prioritized getting our relational providers working. Functionality with in-memory database and Cosmos DB providers is broken, and we recommend you skip preview 6 if you have code that depends on these providers. We expect to gradually restore functionality in subsequent previews.
- Temporary limitation: Several areas of query translation aren’t working with relational databases: Queries that use any of these constructs will very likely fail to translate correctly or execute:
- Owned types
- Collections reference on projections
- GroupBy operator
- Equality comparisons between entities
- Query tags
- Global query filters
- Intentional breaking change: LINQ queries are no longer evaluated on the client: This is actually one of the main motivations we had for building a new LINQ implementation into EF Core 3.0. Before this version of EF Core, expressions in the query that could not be translated for SQL would be automatically evaluated on the client, regardless of their location in the query. This contributed to hard to predict performance issues, especially when expressions used in predicates were not translated and large amounts of data ended up being filtered on the client, and also caused compatibility problems every time we introduced new translation capabilities. In the new implementation, we only support evaluating on the client expressions in the top-level projection of the query. Read the full description of this breaking change in our documentation.
- Intentional breaking change: Existing FromSql overloads has been renamed to FromSqlRaw and FromSqlInterpolated, and can only be used at the root of queries: Read more details about it in the breaking change documentation.
If you run into any issues that you don’t see in this list or in the list of bugs already tracked for 3.0, please report it on GitHub.
If you hit limitations only in a few queries, here are some workarounds that you might be able to use to get things working:
- Switch explicitly to client evaluation if you need to filter data based on an expression that cannot be translated to SQL, using the
ToList()extension methods. For example, the following query will no longer work in EF Core 3.0 because one of the predicates in the where clause requires client evaluation:
var specialCustomers = context.Customers .Where(c => c.Name.StartsWith(n) && IsSpecialCustomer(c));
But if you know it is ok to perform part of the filtering on the client, you can rewrite this as:
var specialCustomers = context.Customers .Where(c => c.Name.StartsWith(n)) .AsEnumerable() .Where(c => IsSpecialCustomer(c));
- Use the new
FromSqlInterpolated()methods to provide your own SQL translations for anything that isn’t yet supported.
- Skip preview 6 and stay on preview 5 until more issues are fixed, or try our nightly builds.
Switch to Microsoft.Data.SqlClient
As announced recently, development of the ADO.NET provider for SQL Server has moved to this new package. The EF Core provider for SQL Server now uses the new package to connect to SQL Server databases.
Please continue to create issues for the EF Core layer (for example SQL generation) on the EF Core issue tracker. Any issues related to SQL Server database connectivity are better reported to the SqlClient issue tracker.
DbContext scaffolding improvements
We now have support for:
- Scaffolding entities without keys.
- Scaffolding entities from database views.
DbContextfrom an Azure SQL Data Warehouse.
- A new
dotnet ef dbcontext scriptcommand to generate the SQL script equivalent to calling
- New Package Manager Console command functionality in
DbContexttypes available in an application.
Thank you very much @ErickEJ for all these contributions! You rock!
What’s new in EF 6.3 Preview 6
Here are some of the main changes since preview 5:
- We automatically locate System.Data.SqlClient when it isn’t registered with DbProviderFactories: This means it’s no longer necessary to register SqlClient as a workaround before you start using EF.
- EF 6 tests are passing on .NET Core: We made infrastructure updates necessary to get our existing tests running on .NET Core. This has allowed us to identify and fix problems in the product code as well as an issue that was fixed in .NET Core 3.0 Preview 6. There is a known issue with the translation of String methods like StartsWith, EndsWith and Contains that wasn’t fixed on time for Preview 6.
For upcoming previews and the rest of the EF Core 3.0 release, our main focus will be on restoring and improving the query functionality using our new LINQ implementation.
We are also working to enable more aspects of the experience you would expect from using EF 6.3 on .NET Core. For example, we are making additional changes to simplify working when an application .config file isn’t present, enabling embedding metadata from an EDMX into the compilation output on .NET Core, and reimplementing the EF migration commands in a way that is compatible with .NET Core.
Weekly status updates
If you’d like to track our progress more closely, we now publish weekly status updates to GitHub. We also post these status updates to our Twitter account, @efmagicunicorns.
As always, thank you for trying our preview bits, and thanks to all the contributors that helped in this preview!
The “full description of this breaking change” link is broken. I guess it should be https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/breaking-changes#linq-queries-are-no-longer-evaluated-on-the-client
Thank you! Fixed.
Hi Sir, Thank you and your team especially for your hard work. I am experimenting with EF 3.0. However some reason, every project that I use ef core 3.0, in order to get `dotnet ef …` to function correctly, the following has to be added to the csproj.
<DotNetCliToolReference Include=”Microsoft.EntityFrameworkCore.Tools.DotNet” Version=”2.1.0-preview1-final” />
Can you educate me where this is documented and get a better under standing why? Usually I do not have to do this.
Thank you Paul! The reason for this is that dotnet-ef is no longer included as a .NET Core SDK tool. You can install it as a global tool or as a local tool on your project. This information was mentioned in the preview 4 blog post and there are more details in the 3.0 breaking change documentation. I will make some edits this week to this blog post to point to the latter.
Now that you have decided to screw over .NET Framework developers, are you at least going to continue to patch EF Core 2.x? Or, should I downgrade back to EF classic?
What about the automatic migrations in Entity Framework Core 3.0?