2

I have a situation where an application uses various component libraries. The libraries were based on .NetStandard2.0/2.1 and internally used EF Core 3.1. For various deployment and development reasons, we now want to target EF Core 6.0, which raises the following issues.

  1. Net Core 3.1 support runs out in December 2022 so we need to move away from it.
  2. The application uses Net Framework functionality and cannot move to Net Core.
  3. EF Core 6.0 does not support NetStandard, only Net 6.
  4. Changing the library that uses EF Core to target NET 6 means that components referencing it also need to reference Net 6.
  5. Dependencies trickle down to the application that targets Net Framework and, as a result, the application no longer builds because Net Framework is not compatible Net 6.

How can the Net Framework application use the Net 6 assembly? Or, more specifically, how can a Net Framework application use libraries that internally use EF Core 6.0?

The interface between the application (Net Framework) and the one single touch point library component (Netstandard) is very well defined. Maybe Pinvoke could solve the problem? Or something simpler that I have overlooked?

Somewhat related question: NU1202 Package Microsoft.EntityFrameworkCore 6.0.3 is not compatible with netstandard2.1

J.R.
  • 1,880
  • 8
  • 16

2 Answers2

1

Other than process to process communication between .NET Framework and .NET 6, this is not supported (for example via a Web API or similar)

ErikEJ
  • 40,951
  • 5
  • 75
  • 115
  • Looks to be this way. Coercing Net6 into compiling some "PInvokable" native methods does not seem possible. Hosting the touch point as a `ComVisible` COM component looked promising, but there seem to be problems loading secondary Netstandard DLLs. What's left is interprocess communications. – J.R. May 26 '22 at 08:05
  • Or calling a console app? – ErikEJ May 26 '22 at 12:30
  • Technically possible, but launching processes with inter-process communications via command line arguments would be to slow in this instance. – J.R. May 26 '22 at 21:56
0

As a short term solution, you can change your .Net Standard 2.0 EF Core libraries to be multi targeted to both .Net Standard 2.0 (which will reference EF Core 3.1) and .Net 6 (which will reference EF Core 6). This will let your .Net Core apps use EF Core 6, while allowing your .Net Framework apps to use the same dlls, but to be using EF Core 3.1. I realize that EF Core 3.1 support ends December 2022, but it will keep things moving.

https://learn.microsoft.com/en-us/nuget/create-packages/multiple-target-frameworks-project-file

Btw, has Microsoft even attempted to address the fact that a .Net Framework application cannot reference .Net 6, therefore it cannot use EF Core 6? This is a major issue for us, as we were sold the idea that .Net Standard could be shared between .Net Framework and .Net Core, but this has ceased to be the case since .Net Standard 2.1 was introduced, and now MS has pushed all new features, like EF Core, to .Net 6.

Eric
  • 2,120
  • 1
  • 17
  • 34