Currently EF6 only supports standard 2.1 or core, or 4.7.2.
What would simply be so freaking amazing is if this ### had standard 2.0 support.
I think its absolute madness that MS team has missed this, in understanding what their customer were wanting when they made ef6 core compatible with core.
If you are bound to core you would of started with EF core.
seems completely backwards, in terms of helping customers migrate.
Im not sure what can been done here as, those namespace which were added to 2.1 ....
o wait the issue is they made std 2.1 NOT compatible with 4.7.2 so now anyone who was panning on migrating is suck in the some position they were.
This would be amazing! We have shared libraries that need to work in both Core and Framework during a (lengthy) transition period. We want those libraries to target .NET Standard 2.0 so as individual apps and services are migrated from Framework to Core, they can continue to reference these common libraries.
.NET Standard 2.0 is a bridge to move from Framework to Core. Without EF6 supporting 2.0, well, what good is a bridge if it only goes halfway across the river?
@JamesDSch exactly, when I read your comment yesterday, i completely miss-read, read way better this morning ;-)
To me it make little sense,
I mean I understand why they done/did it... really i do, the technical challenge, with data lib abstractions... but what i don't understand is making 2.1 with a requirement of basically core, What would of made more sense to me, is create std 2.1 with framework interfaces for data layers.
Yes would of been loads harder... and much more time, and maybe not possible, without a .net framework update, but the point was to help with the last few hurdles with regards to (lengthy) transition periods to migrate.
I think part of the migrate hurdles is doing "data layer" and "presentation layer" at the same time.
As both of these need to communicate through a layer(service) its almost 3 layers you have to completely re-engineer and learn.
Simply saying it would of been nice to have a stepping stone, to help with the migration process.
Which i am currently going through, converting 3 years of personal part time project.
I believe I'm correct in saying that 99..% of projects currently using .net framework and ef6 which are of size are simply just been started again from scratch instead of any type of migration process as simply there isn't one or am i missing something?
EF6 supports two targets: net45, and netstandard2.1. The migration path from Framework to Core is to use multi-targetting.
We are not going to build EF6 to target .NET Standard 2.0 because this is not 100% compatible with all the .NET Framework versions that EF6 can be used with. This would result in both build and runtime breaks in some situations for applications that currently work with .NET Framework. Multi-targeting is more work than using .NET Standard 2.0, but the results are more robust.
Could you explain how you get ef-6 to work on Core-3...
where it remains compatible with existing dotnet framework, "multi-targetting" i think you missed,
Its simply not possible, you would be forces to redo your Presentation layer and Db layer at the same time.
If you did ef-6 to std-2.1 it needs core-3 for presentation, and if you did core-3 for presentation it would need at least 2.1 on ef-6.
You are forced to do both, you may as well just do ef on ef-core.
Basically this is helping nobody migrate, as they are forced to do both.
I believe I'm correct? am i missing something with "multi-targetting"
@Seabizkit What are your concrete target frameworks? (By concrete, I mean not .NET Standard, since it can't be used to directly execute anything.)
I am in the process of trying to convert everything which can to std-2.
Db layer is ef-6 and presentation is mvc5;
Could you be a little more specific with your question, seems like a question on a question.
My question is simply is it possible to start the migration to core, without doing DB and presentation at the same time. If your db layer is ef-6 and presentation is mvc5. If so, how would you do this. I have several libs, most can be converted to std-2. Currently in the process to trying to convert Service layer to std-2, which is the hardest as i have ref to EF-6 which i currently removing... with the hope that DI will solve the dependency when done. But lets assume all are converted bar ef-6 lib and mvc5 lib. im still stuck...correct? presentation layer references service layer and persistence layer for DI registration.
legit-mentally asking am I missing something?
@Seabizkit Multitarget your service layer (or any library that pulls in EF6) to net462 (or whichever lowest framework you support) and netstandard21.
The service layer targeting net4x will pull in ef6 targeting net4x and the netstd20 libraries. When compiled targeting netstandard21 it will pull in ef6 targeting netstd21 and the netstd20 libraries.
Make sure you update your test projects for the service layer to run under both netcoreapp30 or higher _and_ net4x to ensure you have no compatibility issues.
You can then keep your MVC5 presentation layer intact while the rest of your stack is updated to be able to run on netcore.
When you are ready, you can re-write your presentation layer with aspnetcore.
If your presentation layer has webservices/webapi as well as razor/mvc pages you might be able to migrate them separately.
Splitting an application like that improves scalability anyway.
I am part way through this process myself.
@CZEMacLeod Thank you for taking the time to write that. Very well explained.
@ajcvickers
i think i finally understand, that was not obvious
but at the same time so obvious now,
but i tell you wasn't before... LOL
so basically start a standard x, then set to multiple targets, like;
<TargetFrameworks>netstandard2.1;net472</TargetFrameworks>
Then i should be able to ref this from a net472 or a Core 3.1
@Seabizkit You're not alone in finding this hard to get your head around. :-)
I'll just add my two cents.
@ajcvickers
It's clear that EF 6 should multi target to support older framework like .NET 4.0. But I really think EF team should consider multi-targeting to .NET Standard 2.0 as well.
The typical migration path for solutions that contain one main "entry project" like ASP.NET MVC 5 web app or WPF/WebForms desktop app plus many class libraries is like that:
Event though it's not mention in migration docs site it's clearly recommended here and even more recently in this NET Community Standup video. Most recent Microsoft nuget package still targets .NET Standard 2.0 (like System.Text.Json, System.Threading.Channels, System.IO.Pipelines. Really, browse through https://www.nuget.org/profiles/Microsoft and try to find package that target only .NET Standard 2.1, it's mostly 2.0 or even earlier.
After hearing that EF 6.3 supports new SDK-style csproj and old web csproj can reference it without problems I migrated all my class library projects and it works great, there's no problem with EF migrations and this was what stopped me one year ago when I first attempted to migrate.
So good work guys! But really, consider multi-targeting to .NET Standard 2.0. In my project it looks that most of my nuget dependencies have newer version that target .NET Standard 2.0. It's not a trivial task to update all this dependencies but when we'll do it then migration of main website project to ASP.NET Core (probably ASP.NET 5 by that time ;)) will be much easier.
For me if you multi-target EF6 to .NET Standard 2.0 you could say this project is "done" and just focus on EF Core ;-)
@mpawelski
From what i understand and believe that its basically not really possible.
Its kind of like an apple cant be a grape at the same time.
They would need to write conversion layers for every abstraction in the dot "data" namespace, and this is what they want to avoid, its either A or B not B translated to A.
Saying all this, i gave up on the journey, as it was way to hard to try get it all to play with Identity as well... and seeing as they stopped development of Identity with EF6. It left me no options, the "Identity" switch, in that making two versions with different development pipelines literally made 0 sense, if its meant to be an abstraction anyway but that's a separate story but one that annoyed me.
So i simply started converting ef6 to ef core and then started converting web.
Another thing that is annoying to me, is hiding the example code, we use this to learn from, so that was a bad move in my opinion.
Also considering im trying to develop something in my private time as 1 developer, all these changes are taxing when you trying to migrate quite large code bases, and finding out all the new quirks.
Most helpful comment
I'll just add my two cents.
@ajcvickers
It's clear that EF 6 should multi target to support older framework like .NET 4.0. But I really think EF team should consider multi-targeting to .NET Standard 2.0 as well.
The typical migration path for solutions that contain one main "entry project" like ASP.NET MVC 5 web app or WPF/WebForms desktop app plus many class libraries is like that:
Event though it's not mention in migration docs site it's clearly recommended here and even more recently in this NET Community Standup video. Most recent Microsoft nuget package still targets .NET Standard 2.0 (like System.Text.Json, System.Threading.Channels, System.IO.Pipelines. Really, browse through https://www.nuget.org/profiles/Microsoft and try to find package that target only .NET Standard 2.1, it's mostly 2.0 or even earlier.
After hearing that EF 6.3 supports new SDK-style csproj and old web csproj can reference it without problems I migrated all my class library projects and it works great, there's no problem with EF migrations and this was what stopped me one year ago when I first attempted to migrate.
So good work guys! But really, consider multi-targeting to .NET Standard 2.0. In my project it looks that most of my nuget dependencies have newer version that target .NET Standard 2.0. It's not a trivial task to update all this dependencies but when we'll do it then migration of main website project to ASP.NET Core (probably ASP.NET 5 by that time ;)) will be much easier.
For me if you multi-target EF6 to .NET Standard 2.0 you could say this project is "done" and just focus on EF Core ;-)