Announcing Entity Framework Core 3.0 Preview 9 and Entity Framework 6.3 Preview 9

Diego Vega

The Preview 9 versions of the EF Core 3.0 package and the EF 6.3 package are now available for download from

These are the last planned previews before we release the final versions later this month. We have almost completely stopped making changes to the product code, but we are still actively monitoring feedback for any important bugs that may be reported. So please install the previews to validate that all the functionality required by your applications is available and works correctly, and report any issues you find to either the EF Core issue tracker or the EF 6 issue tracker on GitHub. Even if we may not be able to fix many more issues in EF Core 3.0 at this point, we’ll consider important bugs and regressions for the upcoming 3.1 release.

What’s new in EF Core 3.0 Preview 9

Besides all the other improvements in EF Core 3.0, preview 9 includes fixes for more than 100 issues that we resolved since Preview 8. Here are a few highlights:

  • Support for translating queries that project a single result form a collection using window functions (issue #10001)
  • Support for translating queries with constants or parameters in the GROUP BY key (issue #14152).
  • Improvements to our thread concurrency detection logic to reduce false positives (issue #14534).

Consider installing daily builds

In Preview 9 the functionality of the in-memory provider is still very limited, but this is already fixed in our daily builds. In fact, we have already fixed more than 20 issues that aren’t included in Preview 9, and we may still fix a few more before RTM. 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. For this reason, 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 AsEnumerable()AsAsyncEnumerable()ToList(), or 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 FromSqlRaw() or FromSqlInterpolated() methods. Also make sure an issue exists in our issue tracker on GitHub to support the translation of the specific expression.

Breaking changes

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 9 packages

EF Core 3.0 is distributed exclusively as NuGet packages. As usual, add or upgrade the runtime to Preview 9 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 9 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 9

All of the work planned for the EF 6.3 package has been completed. We are now focused on monitoring your feedback and fixing any important bugs that may be reported. As with EF Core, any bug fixes that happened after we branched for Preview 9 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 as linked files to a .NET Core 3.0 or .NET Standard 2.1 project in the same solution. For example, the project file for the .NET Core project can include the linked files like this:

    <EntityDeploy Include="..\EdmxDesignHost\Entities.edmx" Link="Model\Entities.edmx" />
    <Compile Include="..\EdmxDesignHost\Entities.Context.cs" Link="Model\Entities.Context.cs" />
    <Compile Include="..\EdmxDesignHost\Thing.cs" Link="Model\Thing.cs" />
    <Compile Include="..\EdmxDesignHost\Person.cs" Link="Model\Person.cs" />

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.

Thank you

Once more, 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.


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

  • Marcel 0

    We are getting some strange errors on some of the migration files after updating to EF 6.3.
    Microsoft.CSharp.CurrentVersion.targets(100, 9): [MSB3041] Unable to create a manifest resource name for “Migrations\201806250240525_MigrationName1.resx”. Could not find a part of the path ‘C:\…PathToProject…\Migrations\Migrations\###############_MigrationName1.cs’.’C:\…PathToProject…\Migrations\Migrations\###############_MigrationName2.cs’.’C:\…PathToProject…\Migrations\Migrations\###############_MigrationName3.cs’.’C:\…PathToProject…\Migrations\Migrations\###############_MigrationName4.cs’.’C:\…PathToProject…\Migrations\Migrations\###############_MigrationName5.cs’.
    It seems the ‘Migrations’ path is added in twice in there. Not sure if it’s a bug or if there’s a way to configure what the default path of these migrations is?
    Tried in both Mac and Windows and same issues happens.

    • Diego VegaMicrosoft employee 0

      Hi Marcel, thank you! Since you mention Mac and Windows, is it right to assume you are testing on both with .NET Core? I will forward your comment to the entire team, but we may need a bit more information, so it would be great if you could create a bug on GitHub.

      • Peter Petrov 0

        Same errors here: Error MSB3041 Unable to create a manifest resource name for “Shapes\CustomShape\OldShapeEditor\CustomShapeEditorControl.resx”. Could not find a part of the path…..

      • Marcel 0

        Thanks Deigo, filed the bug for it ( tested the latest daily build (6.3.0-rc1-19455-01) and same issue is still happening there.

        As for our environment, indeed the whole reason we are testing the 3.0 update is so that we can access EF 6 from .NET Core, which our database-touching projects are all still stuck on .NET Framework / ‘net472’ target frameworks. Our non-DB projects have long been migrated to .NET Core / ‘netstandard2.x’ – though it’s actually the minority of them since most of our projects access our domain layer which forces them to be .NET Framework). Basically our web devs work on Mac / touch the web app only – while remainder of API/jobs/back-end runs in a Parallels Windows VM (slow, machine-intensive, unproductive).

          • Diego VegaMicrosoft employee 0

            Thanks Marcel and Peter. Adding more details and the workarounds directly here in case it can help others reading the blog. The issue mentioned by Marcel above was only partially fixed, so if resource files are under a folder, the build will still fail. Issue tracks fixing it for folders, and it is currently being considered by the MSBuild team for a fix.

            There are two known workarounds:

            – Move migration files from a folder into the root of the project 

            – Add resource files explicitly with `DependUpon`attributes in the project file. For example:

                <EmbeddedResource Update="Migrations\###############_MigrationName1.resx">
                <EmbeddedResource Update="Migrations\###############_MigrationName5.resx">
  • PandaSharp 0

    when will be possible to use EF core 3.0 in UWP? UWP currently doesn’t support .net standard 2.1

    • Diego VegaMicrosoft employee 0

      Emiliano, I don’t know the answer to this question right now. I will try come back to you on this. In the meantime I would recommend using a previous version of EF Core, like 2.2 or 2.1.

      • Oleg Mikhailov 0

        Thank you for your efforts, guys, this release is most important thing EF team made since 2012. I guess, if Entity Framework will be independend .Net Standard library, it will be available on every platform including UWP. Anyway, it just doesn’t makes sense to stick with .Net Core doomed to be deprecated in 2020.

        • Diego VegaMicrosoft employee 0

          Oleg, I am curious, what do you mean with .NET Core doomed to be deprecated in 2020?

          • Oleg Mikhailov 0

            I mean, it will be replaced by .Net 5 next year.

        • Diego VegaMicrosoft employee 0

          Oleg, I recommend that you read the post .NET Core is the future of .NET by Scott Hunter, to better understand what’s happening.

          • Oleg Mikhailov 0

            Diego, I recommend that you read the post Introducing .Net 5, to better understand what will happen next year 🙂

      • PandaSharp 0

        Thanks for your reply, I got finally one at least 🙂

    • Jon Miller 0

      They aren’t going to support it. Just like they aren’t supporting ASP.NET Web Forms.

  • J. Portelli 0

    This LINQ statement (and other similar statements) was being translated properly till Preview 8:

    var queryYearly =
        from h in context.Histories.AsNoTracking() group h by h.HistoryDate.Year into yearGroup
        orderby yearGroup.Key descending
        let Total = yearGroup.Sum(m => m.Fee)
        where Total > 0
        select new
                Year = yearGroup.Key,

    Updated to preview 9 this morning and I am getting the following error: 
    System.InvalidOperationException  HResult=0x80131509  Message=Processing of the LINQ expression ‘GroupBy(KeySelector: DATEPART(year, h.HistoryDate), ElementSelector:EntityShaperExpression:     EntityType: Histories    ValueBufferExpression:         ProjectionBindingExpression: EmptyProjectionMember    IsNullable: False)’ by ‘RelationalProjectionBindingExpressionVisitor’ failed…..

      • J. Portelli 0

        Thank you Diego. Meanwhile I altered the LINQ statament removing the “let” statements and moving the aggregate function “Sum” into the anonymous type and everything worked without problems. I’ll try to open a report. Thanks.

    • Aaron Amm Theeranit 0

      @James Portelli

      I found the same issue like you.
      To use let it cleaner for me but it does not work.
      This is my query.

                  var query =
                      from t in db.Tags
                      join pt in db.PostTags on t.Id equals pt.TagId
                      join p in db.Posts on pt.PostId equals p.ParentId
                      join v in db.Votes on new { PostId = p.Id, VoteTypeId = voteType }
                      equals new { v.PostId, v.VoteTypeId }
                      where p.OwnerUserId == userId
                      group t by t.TagName into g
                      let count = g.Count()
                      orderby count
                      select new { g.Key, Upvotes = count };
  • Joseph Rufft 0

    Please get with Scott Hunter about putting Web Forms in .Net 5.

    • Wil Wilder Apaza Bustamante 0

      this comment has been deleted.

  • Marcel 0

    The execution strategy needed to run without errors in Azure doesn’t port over since remoting isn’t supported on .NET Core 3.0. Notably the ‘Workaround: Suspend Execution Strategy’ mentioned in the EF docs Connection Resiliency :: Retry Logic section references ‘CallContext::LogicalGetData/LogicalSetData’ which dont’ exist in .NET Core 3.0. How can we implement the connection resilience retry strategy in EF 6.3?

    • Diego VegaMicrosoft employee 0

      Hi Marcel, the ability to suspend the excution strategy is built-in in the execution strategy included in our our product code, but not publically accessible. In EF 6.3 the implementation has been updated to use Asynclocal<bool> instead of call context logical data for .NET Standard based targets.

      You can choose to copy this pattern into your own strategy. Another option that may lead to better results if you want to suspend the execution strategy because you are going to start your own transaction is to is to create an instance of the execution strategy and do all the re-tryable work (including starting your own transactions) in a delegate that you pass to the execute method. This is also found in the documentation

      • Marcel 0

        Wonderful Diego, that did it! I am extremely happy to say for the first time since the start of the .NET Core journey (1.0 time-frame) we have our entire .NET stack running on OSX, and unblocked from VMs/unproductiveness/slowness  =) !!! A huge congrats and thanks to the team for the mamoth milestones that it took to get here !!!
        UPDATE: Actually the missing ‘dotnet ef6’ command-line tool is blocking us from finishing the .NET Core 3.0 adoption. Runtime everything is fine… but we can’t iterate on our models/DB without it (kind of a deal-breaker!)

  • Marcel 0

    FEEDBACK: ‘dotnet ef6’ migration tool needed
    The last missing piece to the vision of running .NET Core everywhere, which EF 6 has been a huge blocker for the majority of our cloud stack for, is the command line migrations. I noticed that the team rhetoric went to ‘gather feedback’ on this feature instead of rightfully identifying it as a blocking gap and scheduling it. Without it we cannot move our dev processes over to .NET Core and it blocks our adoption of .NET Core 3.0 (in otherwords a show-stopping deal-breaker that will keep us on 2.2 until it is addressed).
    These things tend to be this way – one deal-breaker can stop the entire initiative from being adopted – so please do the right thing and define it as critical for the 3.0 release, despite the obvious fact that it will miss the RTM timeline.

    PS: We gave a quick try at upgrading @mrahal’s Migrator.EF6 project to .NET Core 3.0 but it threw multiple internal/cryptic errors. Perhaps the team could start by assessing Migrator.EF6’s approach and deciding if it makes sense to adopt/extend it or build a first-party Microsoft version afresh (here is the start of an upgrade attempt: Much thanks guys!

  • Brian Roos 0

    First off thanks for all the updates and work on both EF Core and EF6.3 for core.  The only reason I really need EF6 is EF Core’s lack of database first approach in the inability to use a designer in Visual Studio to reverse engineer complex types from stored procedures, and the (somewhat limited) ability to update the model from changes in the database schema that the EF6 designer provides.  I use those for a way to quickly build complex types and hook into stored procedures.  If EF Core had these features I wouldn’t need EF6.  Its the fastest way I have found to use stored procedures in my code and its very performant when used in a repository pattern.  I’m eagerly waiting for the Visual Studio change for full edmx support but thatnks a lot of the example project to get around it.

  • Marcel 0

    The migrations commands don’t work in Visual Studio 2019 16.3.0 Preview 3, when issued against EF 6.3 / .NET Core 3.0.
    I thought this was supposed to work?

    PM> get-migrations
    Project ‘Libraries\World.NET.Data’ targets framework ‘.NETStandard’. The Entity Framework Package Manager Console Tools don’t support this framework.

  • Mark Gilbert 0

    Please can you confirm if support for CosmosDB will be included in the full EF Core 3.0 release?

    • Diego Vega 0

      Yes, the Cosmos DB provider is included in our 3.0 release, and a few know limitations planned to be addressed in 3.1.

Feedback usabilla icon