Announcing Entity Framework 6.3 Preview with .NET Core Support

Avatar

Diego

The first preview of the EF 6.3 runtime is now available in NuGet.

Note that the package is versioned as 6.3.0-preview5. We plan to continue releasing previews of EF 6.3 every month in alignment with the .NET Core 3.0 previews, until we ship the final version.

What is new in EF 6.3?

While Entity Framework Core was built from the ground up to work on .NET Core, 6.3 will be the first version of EF 6 that can run on .NET Core and work cross-platform. In fact, the main goal of this release is to facilitate migrating existing applications that use EF 6 to .NET Core 3.0.

When completed, EF 6.3 will also have support for:

  • NuGet PackageReferences (this implies working smoothly without any EF entries in application config files)
  • Migration commands running on projects using the the new .NET project system

Besides these improvements, around 10 other bug fixes and community contributions are included in this preview that apply when running on both .NET Core and .NET Framework. You can see a list of fixed issues in our issue tracker.

Known limitations

Although this preview makes it possible to start using the EF 6 runtime on .NET Core 3.0, it still has major limitations. For example:

  • Migration commands cannot be executed on projects not targeting .NET Framework.
  • There is no EF designer support for projects not targeting .NET Framework.
  • There is no support for building and running with models based on EDMX files on .NET Core. On .NET Framework, this depends on a build task that splits and embeds the contents of the EDMX file into the final executable file, and that task is not available for .NET Core.
  • Running code first projects in .NET Core is easier but still requires additional steps, like registering DbProviderFactories programmatically, and either passing the connection string explicitly, or setting up a DbConnectionFactory in a DbConfiguration.
  • Only the SQL Server provider, based on System.Data.SqlClient, works on .NET Core. Other EF6 providers with support for .NET Core haven’t been released yet.

Besides these temporary limitations, there will be some longer term limitations on .NET Core:

  • We have no plans to support the SQL Server Compact provider on .NET Core. There is no ADO.NET provider for SQL Server Compact on .NET Core.
  • SQL Server spatial types and HierarchyID aren’t available on .NET Core.

Getting started using EF 6.3 on .NET Core 3.0

You will need to download and install the .NET Core 3.0 preview 5 SDK. Once you have done that, you can use Visual Studio to create a Console .NET Core 3.0 application and install the EF 6.3 preview package from NuGet:

PM> Install-Package EntityFramework -pre

Next, edit the Program.cs file in the application to look like this:

using System;
using System.Linq;
using System.Data.Entity;
using System.Data.Common;
using System.Data.SqlClient;

namespace TryEF6OnCore
{
    class Program
    {
        static void Main(string[] args)
        {
            var cs = @"server=(localdb)\mssqllocaldb; database=MyContext; Integrated Security=true";

            // workaround:
            DbProviderFactories.RegisterFactory("System.Data.SqlClient", SqlClientFactory.Instance);

            using (var db = new MyContext(cs))
            {

                db.Database.CreateIfNotExists();
                db.People.Add(new Person { Name = "Diego" });
                db.SaveChanges();
            }

            using (var db = new MyContext(cs))
            {
                Console.WriteLine($"{db.People.First()?.Name} wrote this sample");
            }
        }
    }

    public class MyContext : DbContext
    {
        public MyContext(string nameOrConnectionString) : base(nameOrConnectionString)
        {
        }

        public DbSet People<Person> { get; set; }
    }

    public class Person
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }

}

Closing

We would like to encourage you to download the preview package and try the code first experience on .NET Core and the complete set of scenarios on .NET Framework. Please, report any issues you find to our issue tracker.

Avatar
Diego Vega

Program Manager , .NET Data Access

Follow Diego   

51 comments

  • Avatar
    Damien Dennehy

    There is no support for building and running with models based on EDMX files on .NET Core.
    Is there a plan to support this in 6.3 final? Our main data access layer uses a Database first EDMX. I accept that it might not be possible at all but if we have a definitive statement on this at least we can move forward with a migration plan.

    • Avatar
      Diego Vega

      We plan to address this before RTM. It is one of the temporary limitations we expect to remove.

      Right now it should be possible to achieve by programmatically splitting the EDMX model into CSDL, MSL and SSDL, and then feeding those into a MetadataWorkspace. It is just so far from the automatic experience available in .NET Framework that I decided not to even mention it.

    • Avatar
      Ri Scott

      Yeah, could someone speak to the spatial data type roadmap? I have an application that I would really like to port to .NET Core, but spatial data types are a requirement.

      • Avatar
        Diego Vega

        We are still discussing this with the SQL Server team that owns spatial types, to help them prioritize .NET Core support. What can help the most at this stage is concrete examples of applications that you plan to build or port if this functionality becomes available on .NET Core.

        I will soon be able to share a GitHub issue in which you can provide this additional information.

  • Avatar
    Robert McLaws

    Regarding the EDMX issue, I built a T4 generator to solve this problem for SDK projects targeting the .NET Framework about a year ago. I’ve open-sourced it at https://github.com/CloudNimble/EF6.3MetadataGenerator. Hopefully it helps fill in the gap.
    I’ve opened an issue on GitHub (https://github.com/aspnet/EntityFramework6/issues/828) to discuss if this would be useful in the final product, or what other alternatives are possible.
    Please let me know if there is any way I can help.

    • Avatar
      Diego Vega

      Do you mean an EF6-based provider for ASP.NET Core Identity? I am not aware of any plans but it may be a good idea to ask in the ASP.NET Core repository on GitHub. Even if the ASP.NET team doesn’t plant to do it you may find other likeminded developers that are may want to do this or perhaps already have it.

      • Avatar
        Stilgar Naib

        No, I mean the old one without Core in the name. EF6 based provider for ASP.NET Core Identity would be even more useful but obviously requires a lot more work. Porting the old Identity once you have EF6 should be relatively straight-forward and will provide painless upgrade path for people who have built apps using it. Using the new Identity Core (in the absence of EF6 provider) would mean using both EF Core and EF6 together and having two separate User objects so we can manage relations to other objects from the user table. Of course we can use the old Identity without any port but then we have to deal with the warnings that the package is not .NET Standard complient and in addition it would be nice if the required changes are made to make it cross-platform (I think there are a couple of cryptography API calls in it that are Windows specific).

        • Avatar
          Diego Vega

          There are no plans to do that. In fact, the port of ASP.NET Identity to .NET Core is ASP.NET Core Identity. If you are hitting any specific difficulties adopting the latter, I would recommend posting feedback or questions to the ASP.NET Core repo on GitHub.

          • Tom Wilson
            Tom Wilson

            We are using nuget package Install-Package Microsoft.AspNet.Identity.EntityFramework -Version 2.2.2 
            Will this be available to be used with EF 6.3 and .net core 3?

  • Avatar
    Ben Hayat

    Diego, I’m a bit confused.Is 6.3 for the developers who are using .Net and EF 6 to move to .Net Core or 6.3 the new version # for those who are building .Net Core apps?As of april 18th it was called “Entity Framework Core 3.0 Preview 4”. Now it suddenly became “Entity Framework 6.3 Preview”?I think this blog needs a bit more clarification.Thanks!..Ben

    • Avatar
      Diego Vega

      This post is about the next minor version of EF6, that now happens to also run on .NET Core. 

      EF Core and EF6 remain two different products, and nothing else has changed.

      • Avatar
        Ben Hayat

        >>EF Core and EF6 remain two different products, and nothing else has changed<<

        Thanks for the clarification Diego. So many new news coming out this week and want to make sure I’m clear on them.

  • Avatar
    Weijie JIN

    Thanks Diego for the update.
    I know it maybe duplicated, but just want to mention that please put Database first in priority because a lot of big and complex projects are using DB first approach.

    Thanks!

    • Avatar
      Diego Vega

      Thanks for the feedback. Should I assume that you mean specificically reverse engineering of a database into an edmx file, as opposed to reverse engineering into a “code first” model?

  • Avatar
    Philip Gruebele

    Lack of support for SQL Server spatial types will prevent our app (and I am sure many others) from migrating to EF 6.3/.Net Core 3.
    This seems like a grave oversight to me.

  • Avatar
    Werner Kellens

    With the limitations for EF 6.3 is it better to write a datalayer in .NET Framework? So that your .NET Core/Stardard can communicate with the datalayer. And then in the future migrate to .NET Core en .NET Core EF

  • Avatar
    tom.wilson

    I would like to adopt this by sharing my “Model” project which contain by DBContext and is currently being used by .net 4.6 with a .net core v3 app.  Would I need to uprgade my “Model” project to be on .net standard, so that both my new .net core v3 projects and my .net 4 projects can co-exist?

  • Avatar
    Mike Wink

    How do I use the new Microsoft.Data.SqlClient provider with EF 6.3?When I change the reference to the new namespace and tty registering the factory like this..DbProviderFactories.RegisterFactory(“Microsoft.Data.SqlClient”, Microsoft.Data.SqlClient.SqlClientFactory.Instance);when I then try to access the context I get the following error!’Unable to determine the provider name for provider factory of type ‘System.Data.SqlClient.SqlClientFactory’.

  • Avatar
    Oleg Mikhailov

    These are really good news, I hope that full EF 6 will be available on UWP. The lack of database first approach is one of the limitations forcing me to write WPF applications when it is required to work with database server from local network.

    • Avatar
      Diego Vega

      Oleg, EF Core does support database first, but it doesn’t do everything in the same way as EF6. In any case, I would like to understand what are you actually refering to by “lack of databse first approach”. Is it the ability to use a designer in Visual Studio to tweak the model, the ability to reverse engineer complex types from stored procedures, or the (somewhat limited) ability to update the model from changes in the database schema that the EF6 designer provides? Something else?

      • Avatar
        Oleg Mikhailov

        I mean visual designer: as a freelancer I can take either projects with fixed price or hourly paid jobs. When client pays for hours, slow EF Core development process is not a problem, but on fixed price projects you must be as productive as possible and clasic EF 6 with visual designer is order of magnitude better from this point of view.
        Besides, I generally don’t like the idea of ​​having a model defined in code instead of XML, manual editing of attributes is not the thing I need. This approach is often used in NHibernate, but just because the XML schema is poorly documented there, IMHO it was not worth copying this approach to EF.

      • Avatar
        Julien.Panisset

        Hi Diego, our team also regrets the “code first” approach that is pushed by ef core, leaving the database first approach on the side. Most, if not all operations are more time consuming with EF core. 
        Things like adding a single table, using Enums, adding Views, … are now less intuitive and integrated in the framework than it used to be. Is the database first approach going to be improved ? Why was EFCore designed with the code first approach ? 

  • Donovan Edye
    Donovan Edye

    So unless you need to bring EF 6 “with you” to .NET Core 3.0 and ultimately .NET 5, is it preferable to rather use EF .Net Core when starting a new project that is .NET Core 3 / .NET Standard 2 and ultimately .NET 5?

    • Avatar
      Diego Vega

      Both will work with .NET Standard 2.1, actually. But you are correct on everything else: The goal of porting EF6 to .NET Core is just to make it as easy as possible to port existing apps to .NET Core. While EF6 is a supported product, we are not investing in new feature development for it. Only fixing bugs and processing open source contributions.

      EF Core is the modern alternative, is receiving all of the investment in new features, and should be the first choice for new apps.

      • Avatar
        Greg Veres

        Thanks Diego. Your last statement makes it quite clear. 
        We have an ASP.Net app using WebAPI 2.0 and EF 6. I have been sort of keeping an eye on .Net Core, but we haven’t had time to think about porting. It sounds like we need to get on to EF Core if we want our code base to last as long as possible and be able to keep improving. 
        Porting over to .Net Core at the same time as jumping to to EF Core seems like a big jump. Given that EF 6.3 will support .Net core, is it suggested that we port our code to .Net Core first, while still using EF 6. Then, when we have successfully ported to .Net Core, we look at migrating from EF 6 to EF Core? 
        Or is there a way to jump to EF Core first, while still on .Net 4 (MVC 5) and then move over to .Net Core after that? 

        • Avatar
          Pete Wilson

          I would say EF Core is a long way from ready for production, and considering they are totally re-writing the translation engine in EF Core 3.0 and taking production lessons (learned long ago in EF) to heart for it, that is the first version worth considering. Because of that, using EF 6 on .Net Core seems wisest to me.

  • Avatar
    Bubi

    About the providers, what could be the best way for the update? Start from 6.2 provider or start from sql server 6.3 provider?
    Should the providers backward compatible with Ef 6.2?

    • Avatar
      Diego Vega

      Hi Bubi, 

      I think the best way would be to start from your 6.2 provider and apply the few changes that we made on the SQL Server provider in 6.3. It is mostly about adding an additional target framework for .NET Standrd 2.1 (this is assumign that you have an ADO.NET provider that supports this), and some logic to resolve the default ADO.NET provider to use then there is on configuration available in DbProviderFactories. Feel free to create an issue in https://github.com/aspnet/entityframework6 asking for details if you need some guidance. 

    • Avatar
      Diego Vega

      Ivan,

      No, this is not a limitation of EF per se, but there is currently no distributed transaction support in the .NET Core version of System.Transactions, so if your application code does anything that requires 2-phase commit support, you should get an exception. This is something we may consider improving in the future, at least on Windows. There is an issue tracking at https://github.com/dotnet/corefx/issues/13532.

      • Ivan Lee
        Ivan Lee

        Thanks for your reply.
        Actually, some existing applications do need a distributed transaction. So hope it will support in coming release.
        i love EF core because it is better to support DDD development. 
        p.s. About the first sentence, May I know what “se” stand for ?

        • Avatar
          Diego Vega

          With “per se” I just meant the limitation is not intrinsic to EF. By the way, feel free to vote in the GitHub issue and comment on how your application still needs distributed transactions, whether a solution for Windows only would suffice, etc.

  • Dan Glass
    Dan Glass

    Why is EF6.3 targeting .NET standard 2.1, which does not work with .NET framework? This means forces an “all-or-nothing” upgrade. Why not instead target .NET standard 2.0 and maxiumize prtability and a gradual migration path? The alternitive is to upgrade to EF Core, which runs on .NET Framework, which allows a gradual upgrade.

  • Avatar
    Marcin Szynkowski

    Are you planning to introduce designer for DB models in a nearest future?
    Code First is not a solution for me, because my apps using working db and designer is qute good option to see what tables we have and easily update it or find things we have to change, use cmd commands or something is not really comfortable.

Leave a comment