.NET Standard 2.0 or 2.1?

[gojanpaolo]

Thank you for all the hard work you've made to create this library. I would just like to ask if there are any plans to migrate from .NET Framework to .NET Standard? From the looks of it, .NET Framework 4.8 will be the last version and will only support up to .NET Standard 2.0.

[bubibubi]

The provider uses OleDB and the Jet/ACE OleDB provider so it will run only on Windows. I think that it will have the same behaviour of System.Windows.Forms (that we probably will find also on .Net 5 but will work only on Windows).

[gojanpaolo]

@bubibubi I see. But is there a chance to use the .Net Standard versions of those libraries? e g. System.Data.OleDb.

That way, we can create a .Net Standard 2.1+ library that depends on this library.

Not sure if that is doable. But if it is, I can give it a try with some guidance on where to start. :)

[bubibubi]

As far as I know System.Data.OleDb will be available only in .Net Standard 3 so actually it's not possible.

I think that the needs to make it compatible with .Net Standard is to split it in 2 different projects, one for .Net Standard and one for .Net Framework then pack it in a single NuGet package.

[FreddyDgh]

@bubibubi

I have been playing around with trying to use this package with .NET Core 3. Just wanted to share my findings, in case they are helpful to you or others.

It is actually pretty easy to convert the two project files to .NET Standard 2.0, using the new SDK-style format. Beyond that, the references can be replaced with the following:

• System.Data.Jet: System.Data.OleDb, System.Dynamic.Runtime, and Microsoft.CSharp NuGet packages
• EFCore.Jet: Microsoft.EntityFrameworkCore.Relational NuGet package

Aside from that, there is one override in JetProviderFactory.cs that does not exist in the .NET Standard version of the library that has to be removed. After only editing those 3 files, I found that the .NET Standard library would successfully run several different query operations from a .NET Core 3 WPF app.

However, what doesn't work seems to be the use of the dynamic keyword in AdoxWrapper.cs. Operations that call into this class seem to fail (e.g. creating a database). My understanding is that .NET Core doesn't support late-binding to COM objects. I think, in theory, you could remove all the usage of the dynamic keyword (at which point, I think you could also remove the references to System.Dynamic.Runtime and Microsoft.CSharp) and replace with Runtime Callable Wrappers (RCWs). I tried to generate an interop assembly for the RCWs with Tlbimp.exe and that seemed to work for actually calling the dynamic methods, but it started giving other errors that someone with more knowledge of EFCore.Jet than me might be better able to debug.

In short, my preliminary findings were that the primary blocking issue with porting to .NET Standard 2.0 is AdoxWrapper.cs. So, you'd either have revise the COM interop in a way that it can play nicely with both .NET Framework and .NET Core, or potentially find an alternative to ADOX, if that's possible.

Also, I found this link to be a helpful starting point: http://joelleach.net/2018/06/06/com-interop-with-net-core-2-0/

Edit: For clarification, I was testing on .NET Core 3.0, but I was still using EF Core 2.2.