Looking for these lifecycle dates for Entity Framework 4.0.
End of Life Date
End of Support Date
End of Extended Support Date
Checked Microsoft page for Proucts lifecycle, however, EF 4.0 isn't listed there - https://support.microsoft.com/en-us/lifecycle/search
EF 4.0 is part of the .NET Framework version 4.X, which is still a current shipping product. It ships as part of Windows and follows the Windows support lifecycle.
See Lifecycle FAQ—.NET Framework
So, so long as you keep Windows updated and supported, your .NET 4 applications (including EF 4.0) will remain in support.
After EF 4.0, later versions were delivered as separate packages that relied on less and less of the .NET Framework components, so ironically EF 4.0 has a longer support lifecycle than any later version. So if you need any of the features that came in 4.1 (DbContext and Code First) and later, you must go all the way to EF 6.2 and keep current to retain support.
Related
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/
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
It seems from the MSDN overview that the only change to ADO.Net in .Net 4 is the addition of Entity Framework.
I'm working on refactoring some legacy database access to use ADO.Net and one of the things I'd like to document as project issues is any benefit from moving to .Net 4 from the .Net 3.5sp1 we're currently targeting (we have a WPF GUI - it's a pure desktop app).
There have been a lot of improvement on linq-to-SQL as well see here, and that was for beta2, don't know if more stuff made it in the Release:
http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
Has anybody tried to use EF provider (.NET 3.5 SP1) for Firebird (embedded server in my case) in production?
Can it be considered stable enough for commercial development?
I can't say about the Entity Framework but I do use the Firebird .net Data Provider on production and it's rock solid.
It's work fine. I hadn't got bugs in work with this firebird and entity framework. I develope huge application now and use that products very active. I didn't see bugs in firebird .NET provider, but i saw little bug in entity framework. I have only one problem - to install firebird for using in Entity Framework and make settings. It can take about one working day. So after it you can use this product quietly.
I currently enjoy working with NHibernate + Fluent NHibernate. I considered Entity Framework v1 because of its mature Linq support but I do not like working with clicky designers; and it did not support POCO, anyway. Now EF v4 does support POCOs; however, does it still require to use designers? Well, maybe I can edit those XML files but it cannot be considered a programming activity (unless you're doing J2EE I think).
So, would I be able to use Entity Framework only from the C# code, including model definition, etc?
Yes,
There is an add-on to .NET 4.0 that allows you to do this without a designer, it is called Code-Only you can find it here: In the CTP for Beta 2
The current version works against EF / .NET 4.0 Beta 2.
Check out this post on the EF design blog more on how to use Code-Only.
Also check on this post on my blog.
Hope this Helps.
Alex