Is it possible to deploy / install Entity Framework Core 2.0 alongside traditional Entity Framework 6? Is it fully possible, or possible but with some hang-ups, or not possible? Is this documented somewhere? I think I've seen they said they designed it to be side-by-side, but I'm having a hard time fully confirming this. Thanks.
The official documentation says the following:
It is possible to use EF Core and EF6 in the same application. EF
Core and EF6 have the same type names that differ only by namespace,
so this may complicate code that attempts to use both EF Core and EF6
in the same code file.
If you are porting an existing application that has multiple EF
models, then you can selectively port some of them to EF Core, and
continue using EF6 for the others.
This means of course that you can install both EF6 and EF Core in the same project. I have done this in a few simple cases myself and it was working ok.
Related
I have created a new application, using the SPA templare of .netcore, to this solution i want to add another project to handle the database connection(DAL).
When i am adding ASP.net core Web Application to this solution, i then want to add to id an ADO.net entityframework template, but in the data section, it dont appear:
So I end-up adding a class Library(.net framework)
and to it i can add an ADO.net Entity Data Model
So now in the solution, i have 2 projects, 1 is .net core 2.1 for the API's, models and views(by angular).
The second project is a .net framework 4.6.1, class library project.
My question is, is it suppose to be like that?
is it a good thing to mix different frameworks
Please see this article regarding what each framework is, and what each is specifically designed for.
https://learn.microsoft.com/en-us/dotnet/standard/frameworks
In a nutshell, your requirements drive which framework you choose.
I would recommend sticking with EF Core (just my personal opinion, take it or leave it) The EF Core method of database first is only recommended if you require a 1 time migration from a source database. Microsoft Doc
If you need to CONTINUE working with an entity model past the first migration, it would be in your best interest to use Entity Framework 6, on a .NET Framework library like you have. But that doesn't stop you from using EF Core as your OR/M, because you can indeed have .NET Core reference .NET Framework.
I have a database that I created using EF6. I have a VS project (library) that includes only my models and DbContext. Whenever I need to use my database I just reference that library DLL.
I have a few questions about that:
What happens if I lose this DLL somehow, but still have my models? Am I able to recreate my library?
What if I want to start using .NET Core? As far as I understand, I would have to use EF Core, right?. How can I get the same experience as I had with my DLL (same models).
When you still have the Code of your Models you can simply recreate the DLL. It gets recreated as you rebuild anyway.
You can also use the full entity framework together with .Net Core but that would make your application depending on classic .Net again.
The entity framework core works similar in many ways and also a lot of the old annotations work. You should be able to port you Model easily from EF6 to EF Core if it is not to complicated. Just be aware of some limitations regarding group by that will be resolved in 2.1
Because .Net Core is independent of the OS you won't be shuffeling around DLL's for you dependencys. One way is to use independet projects and release them as packages. So you can consume them in other projects with the package manager.
Can anyone share their experience and insights on upgrading from EF6 to EF7?
Was it straight forward? Did you discover any major benefits or drawbacks from this upgrade?
Thank you
Read this Side-by-side comparison between EF-6 and EF Core 1.0.
https://learn.microsoft.com/en-us/ef/efcore-and-ef6/features
if you need any feature which is still not done then use EF 6 because maybe you have to wait a long time.
My recommendation, if it is really not possible to use EF 6 because you have .NET Core on UWP etc, then use it, otherwise currently you can prefer to use EF 6 over EF Core this is also a recommendation from EF team you can find it on the Announcing Entity Framework Core 1.0.
When to use EF Core
We now have a Comparing EF Core and EF6.x section in our documentation. It includes guidance on when to use EF Core, feature comparisons, and information on porting to EF Core.
These are the types of applications we would recommend using EF Core for. For all other applications, you should consider using EF6.x.
New applications that do not require features that are not yet implemented in EF Core.
Applications that target .NET Core, such as Universal Windows Platform (UWP) and ASP.NET Core applications.
https://blogs.msdn.microsoft.com/dotnet/2016/06/27/entity-framework-core-1-0-0-available/
Is it possible to use Entity Framework Core 1 (formerly Entity Framework 7) in XAF (eXpress Application Framework)?
Yes.
Does XAF support Microsoft’s Entity Framework?
Yes. XAF provides support for Entity Framework. You can use your existing EF data models in order to generate an XAF application. Please review the Business Model Design page to learn more.
From https://www.devexpress.com/Products/NET/Application_Framework/presales-faq.xml
UPDATE
To clarify, it is possible to use EF Core because XAF runs on .NET. If what you are asking is "does XAF work out-of-box with EF Core?" the answer is no. XAF's baked-in class EFObjectSpace is for EF6 and older because it relies on the ObjectContext API. EF Core does not support the ObjectContext API.
In v20.1, we have published GitHub examples illustrating how to access data protected by the DevExpress XAF Security System with Entity Framework Core 3 in non-XAF apps (they use the new EFCoreObjectSpaceProvider and SecuredEFCoreObjectSpaceProvider API).
For more information, please review Frequently Asked Questions and this feature and architecture overview.
XAF 22.2.3 supports EFCore 6.0.3
Note when upgrading old projects the primary keys in the security system have changed to GUIDS.
I managed to do the migration by creating a new .net core5 project from the wizard and then moving my classes into the new project.
Unfortunately The .Net5 security tables are different to those that the framework project uses so I wont be able to do a staged roll out.
I am developing a (free, open-source) Entity Framework tool, it is basicaly an ADO.NET provider, but it uses some higher abstractions too (e.g. ObjectContext, EntityConnection). I want it to support almost all the legacy version of EF (EF4=<). Until EF5 came out it was quite easy, because I had been able to develop it by targeting only .NET40.
EF5 made the things more complicated, because some of the new features requires the .NET45 framework. On the other hand, EF5 supports .NET40 too. An on the top of that, EF is now developed independently from the .NET framework.
For now, It is obvious that targeting both .NET40 and .NET45 is inevitable. But currently I have no idea what is the best way to setup a multi-target environment that can comply with the independently developed EF. I also haven't found any good document about this problem.
Should I use multiple solution files? Multiple project files? Multiple solution configurations? Reference all version of EF somehow? Create an universal build script? If yes, how? How to run my unit test against different configurations? How to indicate that a test can/should fail in a specific configuration? What about the changed namespaces (e.g. ObjectContext)? Should I use #if directive to solve this conflict? What if a new EF release requires to implement a feature that will break the compatibilty with previous versions? I am really uncertain at this point.
Take a look at the EF6 code base at http://entityframework.codeplex.com/. We build EF6 for .NET 4 and .NET 4.5 in essentially the way you are suggesting--using multiple build configurations.
Some other points to consider:
If you don't make use of any .NET 4.5 APIs or behaviors, then you may be able to just target the .NET 4 version. If you are using anything from EntityFramework.dll, then this may require a binding redirect to use the 5.0 version, but in a lot of cases if you ship as a NuGet package then NuGet will handle this for you.
If you plan to support EF6, then keep in mind that the core types have been moved out of the .NET Framework. This means, for example, that the EF5 ObjectContext is a different type from the EF6 ObjectContext. You will likely have to compile your provider code twice to create EF6 and EF5 versions in order to handle this. More information can be found here: http://entityframework.codeplex.com/wikipage?title=Rebuilding%20EF%20providers%20for%20EF6