EF Core 5 support

[lauxjpn]

We will use this issue to track the progress on supporting EF Core 5.

[lauxjpn]

@ChrisJollyAU I think we should make this one comply with what's expected for EF Core 5, ensure the tests that did run before still run now, and get this out the door. Split queries are basically a must for Jet.

I propose moving any real new features and major work to the EF Core 6 support, so we can release in parallel to their release upstream in November.

[ChrisJollyAU]

So more of a compatibility update? Can do go with that

[francescomazzurco]

Do you plan to publish the daily builds in your Azure DevOps feed?
Thanks in advance for your all your work!

[lauxjpn]

Do you plan to publish the daily builds in your Azure DevOps feed?

@francescomazzurco Yes, every merge automatically makes it into the daily build feed.

[ChrisJollyAU]

@lauxjpn What's the current plan? .Net 6 is already here

[bairog]

@lauxjpn @bubibubi Hello there! How can I obtaion some test build with EF Core 5 (or even EF Core 6) support? Thank you.

[lauxjpn]

@bairog

I have scheduled time on Sunday to fix the tests and merge this.

[lauxjpn]

@bairog @ChrisJollyAU I moved the recent posts to #111.

[lauxjpn]

A 5.0 alpha prerelease is now available via our daily builds feed.

[lauxjpn]

For the 5.0 GA release, we have to ensure that all tests that worked in 3.1 are still working (at a first glance, it looks pretty good).
We will also need feedback from the community regards any issue their existing applications have with the new release.

[bairog]

A 5.0 alpha prerelease is now available via our daily builds feed.

@lauxjpn @ChrisJollyAU I've tested 5.0 alpha prerelease in my console application with .net5.0-windows7.0 TFM.
Basic reading with .Where() filtering is working as expected.

P. S. I have x86 version of MS Office 2010 installed. I had to switch my test project to x86, because I got an error with AnyCPU:

The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine

Is there any way to make you provider work in AnyCPU test projects? Installing x64 version of Microsoft Access Database Engine 2010 Redistributable (even with a /passive flag trick) is not an option for me - it breaks my existing x86 MS Office installation.
Wiki page tells us that The provider published on NuGet is compiled with AnyCPU Platform. - so I suppose there should be a workaround for this. Thank you in advance.

[ChrisJollyAU]

@bairog If the provider you have installed is x86 you have to target your project for x86. Similar for x64. It's just one of those things with using the access database engine - target the platform of the engine you have installed. And as you have found out, it's also not really doable/easy to have x86 and x64 installed side by side

As to the nuget being as AnyCPU, that's just so that the same package can be used in projects that target either x86 or target x64. Otherwise you may have ended up with a nuget package specifically for x86 projects and a different package for x64 and you would have to change the package if you changed your target platform

Also as to the project targeting AnyCPU, as far as I understand it, on a 32 bit OS it will run as 32bit/x86 (and you probably wouldnt notice any problems). On x64 systems it will run as x64

[lauxjpn]

@bairog AnyCPU basically means "I can and will be compiled to whatever the target OS or host process architecture is when I am being executed". Nowadays, most machines run a 64 bit OS version.

If the app is compiled to 64 bit, it runs in a 64 bit process. A 64 bit process can only load 64 bit compiled libraries. Because of that, there is also a 64 bit dedicated registry hive for COM components (OLE DB is implemented using COM). If no 64 bit compiled ACE/Jet OLE DB provider has been registered in that hive, your 64 bit app cannot use it to access ACE/Jet databases via OLE DB.

The same is true for 32 bit apps respectively.

---

If you cannot install a 64 bit version of ACE/Jet, then your app needs to run as a 32 bit process to access the 32 bit libraries (either the ones explicitly installed by you, or the legacy ones that ship with Windows).

Since you are building a .NET 5 app, there should be at least two options for you to run your app as 32 bit:

• Compile the app as x86 and run its EXE file
• Compile the app as AnyCPU and run its DLL via the 32 bit .NET Host Process (C:\Program Files (x86)\dotnet\dotnet.exe)

[lauxjpn]

In my daily use, the 5.0 bits work fine.
So unless there are any objections, I suggest we publish those bits as a beta and then go GA after that.

[ChrisJollyAU]

I think there have been some fixes in the 3.1 branch since this was merged to the main branch. Just to confirm those have been ported to the .Net5 main branch?

If so then should be fine for beta

[horseyhorsey]

Anyone have issues with transactions? These were good in the 3x versions.

Invalid SQL statement; expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or 'UPDATE'.

[lauxjpn]

Anyone have issues with transactions? These were good in the 3x versions.

Invalid SQL statement; expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or 'UPDATE'.

@horseyhorsey Please open a new issue and post us some code, so we can take a look at it. Thanks!

[ChrisJollyAU]

Can we close this topic? .Net 5 is already out of support so no use continuing on with this. Better to work on .Net 6/EF Core 6 and EF Core 7 support