.Net Framework > .Net Migration Problem - Incremental upgrade with Entity Framework 6.4.4

Question

Hi,

(apologies for the lengthy description)

I'm working on setting a roadmap for a phased/incremental upgrade path of a .Net Framework 4.8 solution to .Net 8.0+.

The existing solution has a large number of projects with direct project references and has become quite the monolith in places, one of which is the Repository/DataAccess layer which utilises Entity Framework 6.4.4, fronted by classes for the CRUD actions.

The core requirement of a phased migration exists, due to the desire to achieve this almost transparently, reducing impact on the product roadmap.

I've realised we can't migrate directly to .Net 8.0 due to the lack of support for referencing between .Net Framework & .Net. So I determined that initially we'll need to target .NetStandard 2.0, having a mix of .Net Framework & Standard, before a further phase to target .Net 8.0+.

The key issue I'm facing is that we use EF 6.4.4, which isn't supported in .NetStandard 2.0, but annoyingly is supported in .NetStandard 2.1, which we can't use given that isn't supported in .Net Framework. Additionally, we can't use EFCore as that is only supported in .Net and not Standard 2.0. On top of all this, I need to maintain transaction scope multiple updates.

Clearly I'll need to implement an alternative Repository/DA layer and migrate functionality when and as required.

FYI - I've explored the possibility of switching to Fluent NHibernate (as that has support for Standard 2.0), but feel it would be a huge refactor and prohibitive learning curve. I've also considered implementing a new layer either as a self-hosted REST API or gRPC service, however that fails on the transaction scope requirement.

So finally the Question... Has anyone any suggestions of how best to implement the Repository/DA layer given the above issues?

Answer 1

Yeah it is pretty bad. Even using the Upgrade Assistant won't help here. There is no way to mix EF and EFCore together in a single project. You can't even conditionally compile for one vs the other easily because of all the namespaces and related changes.

The general recommendation is to multi-target your projects that can be multi-targeted. Have them target NET Framework (whatever version you need) + NET8. This is generally doable with all the middle layers of your app minus the UX and EF stuff. You may need to break your projects apart but the goal is to move all the EF-specific stuff into its own project. If you're using interfaces/base classes to isolate your code (as you should be) then this isn't too hard. Once you have your EF-logic isolated then things get easier.

Since your app should now be targeting interfaces/base classes then you can create a new EFCore project that mimics your existing EF project. Bring across the code and adjust it to work with EFCore. There are some pretty big differences so this can be painful and some things just may not work. However once you have a project for each version you can now build a new NET8 app that relies on all your existing projects that are multi-targeted + EFCore project whereas your NF app continues to use those same existing projects + EF project. It really ends up being an app startup problem at this point. Once you have finished migrating all your functionality into your new NET8 app then you can remove the old EF project and stop multi-targeting which will allow you to start taking advantage of the newer features. To me this is the biggest pain for multi-targeting, you cannot use the nicer C# features because NF projects don't allow them.

Finally, if you have a web app AND you need to be able to migrate from NF to NET8 slowly then you can use YARP. That is what the Upgrade Assistant does. It sets up a new NET8 web app and then you move your controllers/views/etc across one by one as you are ready to port them. It is the new app that you point everyone to and the old app has to be running somewhere as well. Any requests the new app doesn't recognize it forwards to the old app. Hence you can migrate a web app as you go along. However it introduces its own problems, doesn't work with Windows auth, requires yet another site to be hosted, and can prolong the migration. It is a decision you have to make. Honestly moving from ASPNET MVC to ASPNET Core, outside startup, isn't particularly difficult and mostly works the same way so it is pretty easy to move everything. Of course if you have a client-side framework setup with bundling or complex customizations with handlers then it'll be harder to do.

Answer 2

the whole point of using the Repository pattern, is to abstract the actual data access. You should be able to create two versions, one that uses EF 6 and one that uses EF core. The repository should not "leak" any EF methods.

you have options, convert the repository to an interface, or have the repository wrap the data access layer interface. you should use dynamic inject or just compile time configuration.