Announcing Entity Framework Core 3.0 Preview 8 and Entity Framework 6.3 Preview 8
The Preview 8 versions of the EF Core 3.0 package and the EF 6.3 package are now available for download from nuget.org.
New previews of .NET Core 3.0 and ASP.NET Core 3.0 are also available today.
Please install these previews to validate that all the functionality required by your applications is available and works correctly.
Please report any issues you find as soon as possible to either the EF Core issue tracker or the EF 6 issue tracker on GitHub.
At this point, we are especially interested in hearing about any unexpected issues blocking you from upgrading to the new releases, but you are also welcome to try new functionality and provide general feedback.
What’s new in EF Core 3.0
Preview 8 includes fixes for 68 issues that we resolved since Preview 7. Here are a few highlights:
- Some functionality that we had temporarily disabled while working on our new LINQ implementation is now restored. For example, compiling queries explicitly is now possible, and owned entity types are once again automatically included in query results.
- Several existing and new APIs across EF Core have been tweaked as a result of API reviews.
- Numerous APIs required by providers have been made public.
- The new interception feature has been enhanced to allow intercepting
KeyAttributeis now scaffolded even if EF Core won’t use it, for example for composite keys (contributed by Erik Ejlskov Jensen).
- Various improvements were made to the scaffolding of comments from SQL Server database objects (also contributed by Erik Ejlskov Jensen).
- Support for scaffolding of views was extended to SQLite (also contributed by Erik Ejlskov Jensen).
EF.Functions.IsDate()was added for SQL Server (contributed by Rafael Almeida).
- The Cosmos DB provider was upgraded to use the 3.0 RTM version of the Azure Cosmos SDK.
- The SQL Server provider was upgraded to a newer preview version of Microsoft.Data.SqlClient.
Most of the major pieces of the new EF Core LINQ implementation are now in place. However, in Preview 8 the functionality of the in-memory provider is still very limited, and global query filters are still not correctly applied to navigation properties. The fix for the latter is available in daily builds, as well as fixes for many other issues.
Consider installing daily builds
In fact, we have already fixed more than 50 issues that aren’t included in Preview 8, and we are tracking several more to be fixed before RTM.
Given that we are fixing issues very rapidly, we recommend switching to a daily build to verify the latest fixes.
Detailed instructions to install daily builds, including the necessary NuGet feeds, can be found in the How to get daily builds of ASP.NET Core article.
Common workarounds for LINQ queries
The LINQ implementation in EF Core 3.0 is designed to work very differently from the one used in previous versions of EF Core, and in some areas, it’s still a work in progress. For these reasons, you are likely to run into issues with LINQ queries, especially when upgrading existing applications. Here are some workarounds that might help you get things working:
- Try a daily build (as previously mentioned) to confirm that you aren’t hitting an issue that has already been fixed.
- Switch to client evaluation explicitly: If your query filters data based on an expression that cannot be translated to SQL, you may need to switch to client evaluation explicitly by inserting a call to either
ToListAsync()in the middle of the query. 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 reasonable to process part of the filter on the client, you can rewrite the query as:
var specialCustomers = context.Customers .Where(c => c.Name.StartsWith(n)) .AsEnumerable() // Start using LINQ to Objects (switch to client evaluation) .Where(c => IsSpecialCustomer(c));
Remember that this is by-design: In EF Core 3.0, LINQ operations that cannot be translated to SQL are no longer automatically evaluated on the client.
- Use raw SQL queries: If some expression in your LINQ query is not translated correctly (or at all) to SQL, but you know what translation you would want to have generated, you may be able to work around the issue by executing your own SQL statement using the
FromSqlInterpolated()methods.Also make sure an issue exists in our issue tracker on GitHub to support the translation of the specific expression.
All breaking changes in this release are listed in the Breaking Changes in EF Core 3.0 article. We keep the list up to date on every preview, with the most impactful changes near the top of the list, to make it easier for you to react.
Obtaining the Preview 8 packages
EF Core 3.0 is distributed exclusively as NuGet packages. As usual, add or upgrade the runtime to preview 8 via the NuGet user interface, the Package Manager Console in Visual Studio, or via the
dotnet add package command. In all cases, include the option to allow installing pre-release versions. For example, you can execute the following command to install the SQL Server provider:
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 3.0.0-*
With .NET Core 3.0, the
dotnet ef command-line tool is no longer included in the .NET Core SDK. Before you can execute EF Core migration or scaffolding commands, you’ll have to install it as either a global or local tool. Due to limitations in
dotnet tool install, installing preview tools requires specifying at least part of the preview version on the installation command. For example, to install the 3.0 Preview 8 version of
dotnet ef as a global tool, execute the following command:
dotnet tool install --global dotnet-ef --version 3.0.0-*
What’s new in EF 6.3 Preview 8
With the added ability to execute migration commands against .NET Core projects in Visual Studio, most of the work planned for the EF 6.3 package has been completed. We are now focused on fixing any bugs that arise.
As with EF Core, any bug fixes that happened after we branched for Preview 8 are available in our daily builds.
How to work with EDMX files in .NET Core projects
On the tooling side, we plan to release an updated EF6 designer in an upcoming update of Visual Studio 2019 which will work with projects that target .NET Core (tracked in issue #883).
Until this new version of the designer is available, we recommend that you work with your EDMX files inside projects that target .NET Framework. You can then add the EDMX file and the generated classes for the entities and the
DbContext to the .NET Core 3.0 or .NET Standard 2.1 project as linked files. For example, the project file for the .NET Core project can include the linked files like this:
Note that the EDMX file is linked with the
EntityDeploy build action. This is a special MSBuild task (now included in the EF 6.3 package) that takes care of adding the EF model into the target assembly as embedded resources (or copying it as files in the output folder, depending on the setting on the Metadata Artifact Processing setting in the EDMX). For more details on how to get this set up, see our EDMX .NET Core sample.
You can choose to copy the files instead of linking them, but keep in mind that due to a bug in current builds of Visual Studio, copying the files from the .NET Framework project to the .NET Core project within Solution Explorer may cause hangs, so it is better to copy the files from the command line.
Feedback requested: Should we build a dotnet ef6 tool?
We are also seeking feedback and possible contributions to enable a cross-platform command line experience for migrations commands, similar to
dotnet ef but for EF6 (tracked in issue #1053). If you would like to see this happen, or if you would like to contribute to it, please vote or comment on the issue.
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 usual, thank you for trying our preview bits, and for all the bug reports and contributions that will help make EF Core 3.0 and EF 6.3 much better releases.
Please don’t encourage users to use ToList() while a final collections, such as the data from a database, are methodologically are more correctly represented by an array, what means the usage of ToArray() is preferred in this case. Lists are for adding stuff though.
Don’t use ToArray() just for philosophical reasons. ToList() is likely to be more efficient (unless specifically optimized by the queryable type), shorter to type, and frankly, since the array/list is then under your control, whether adding to it makes sense or not to the database model is completely irrelevant.
When will be possible to use EF Core 3.0 in UWP? UWP currently doesn’t support .Net standard 2.1
What”s the roadmap for EF and EF Core? Since .Net Framework and .Net Core will merge into a single platform .Net 5 in next year (2020), what will EF and EF Core do in that time frame? co-exists or merge into one?
There will for sure not be any merging, since they are entirely different codebases built on different internal architectures/models.
The plan has and always will be that EF6 will retire (ie: remain stable but stop innovating) while EF Core can overtake and take over. The only problem is that EF Core has been ‘not ready’ for many years, and as can be seen by the massive volume of active bugs and issues, still not near that point.
My guess is that within the next year this will change, and in time for .NET 5 the full official (and hopefully also practical) answer will be EF Core for everything.
Will you need SqlRaw for the Graph (node -> edge) tables in SQL server?
For now the feature doesn’t have first-class support in the EF Core provider for SQL Server. A very good PR was started with this, but it hasn’t been finished in time for 3.0. We can take it in a future release once it is ready: https://github.com/aspnet/EntityFrameworkCore/pull/13804.
In the meantime I think it should be possible to query an existing database with nodes and edges by boostrapping queries with raw SQL as you said, although with no support for modeling nodes and edges in EF Core and no support for migrations creating and mantaining the database objects.
Big game stopper for us is the lack of the MariaDb ,mysql driver for the core 3. Pomelo foundation says that they are waiting for an stable release and until then we cant use ef core 3 at all
We plan to help with updating one of the existing EF Core provider to 3.0: See the thread at https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/issues/797.
For “then copy the final version of your EDMX and related files to your .NET Core project.”
Could you please list the files/directories to copy? Where exactly should these be copied to?
Any necessary changes to csproj, App.Config?
Guy, sorry for not answering before, but I wanted to come up with a good example and in the process I found what I think is a better approach than copying the files, using linked files. I have uptdated the post with a new section on this, and created a sample.
I hope to try this later this week.