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.
.Net core 3 with Entity Framework 6.3 or EF Core 3.0? for SQL Server
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.
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.
(answered the wrong question, deleted)
BTW, André’s answer is correct.
EF6.3 also supports classic .net 4.x
Dose EF 6.3 with .Net core 3 support transcationscope with msdtc?
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.
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 ?
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.
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?
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...
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?
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...
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...
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.
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.
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...
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...
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...
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’.
It is still not possible to do it. We are using https://github.com/aspnet/EntityFramework6/issues/823 to track enabling it.
Class Person o People?…
Good catch! Apparently the way I published the article caused generics to be removed (normally they are escaped automatically when they are in a code block in Markdown). I will fix the formatting, but in the meantime, People is of type DbSet of Person.
Fixed.
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?
To do this, you can create a library project that targets both .NET 4.5 and .NET Standard 2.1.
Is there documentation somewhere on how to do this?
Edit
Here is the documentation in case anyone else comes across this: https://docs.microsoft.com/en-us/nuget/create-packages/multiple-target-frameworks-project-file