EF Core 3.0/3.1 support

[lauxjpn]

Are there any plans for an EF Core 3.0/3.1 release? If so, what is the expected timeline?
This is related to #30.

@bubibubi There seems to be no activity on this repo in the last 4 month. Is this repo dead or is there still active development going on? In case there is no one available for the 3.0/3.1 upgrade, I will do in the first quarter of 2020, because I need EntityFrameworkCore.Jet to work with EF Core 3.1. I am just making sure first, that Pomelo.EntityFrameworkCore.MySql has an official 3.1.0 release available (because of the larger user base and because I personally need MySQL support faster then Access support), which will take until mid-January.

[Veflow]

Any update on this?

@lauxjpn if you're still planning on doing the upgrade, and could use some help, let me know if I can be of assistance.

[lauxjpn]

@Veflow Since I got no answer from @bubibubi, it looks like I will have to fork the repo and take over. We have already released 3.1 for Pomelo.EntityFrameworkCore.MySql, but will add some promised features first, before I can get on to upgrading EFCore.Jet.

The timeline has not changed, so doing the upgrade in this quarter is still what I have planed.

I will update this thread once I begin preparing to work on this. Though I will try to contact @bubibubi over different channels first.

Generally, the upgrade might be a bit of a challenge, because EF Core 3.0 dropped the automatic client-side evaluation. So if Jet does not support a features, EFCore.Jet is going to throw instead of implicitly falling back on LINQ to Objects.
So it is likely, that users will need to apply some additional code changes, to manually trigger client-eval in some cases, where Jet just cannot perform the requested operations. This had been an issue for EFCore.Jet in the past though, so it shouldn't be too unexpected for the community.

[Veflow]

@lauxjpn Thanks for taking the initiative! I too think that the throws shouldn't be too much of an issue for most. I've encountered the issue myself on migrating own projects from EFCore 2.2 to 3.x and I think most people have. Though I'm not too familiar yet with EFCore.Jet to have a idea of the limitations in this specific scenario.

Looking forward to hearing about the progress. And again, let me know if there's anything I can do.

[bubibubi]

Sorry for the late answer...
I'm working on a project that is taking a lot of time.
Could I add you as developer so you can handle changes in this period?
About compiling and nuget I can handle it with very short delay..
After this period we can share the effort.

[lauxjpn]

@bubibubi Yes, that should work. I haven't taken a deeper look into the CI pipeline here, but until we have a first prerelease ready, there would be no need to do so anyway.
I plan to start working on the upgrade in February.

About myself

I am currently the lead developer on the Pomelo.EntityFrameworkCore.MySql project here on GitHub and did once write and maintain an MS Access EF 4/5 provider (around 2012, of course based on the published SQL Server sample provider) that I used heavily but never published.
I retired this provider last year, and switched to EntityFrameworkCore.Jet.

Some of the work I am doing in my day job is to migrate applications from MS Access to .NET and I am using EFCore.Jet as an intermediate step.

I have been working with MS Access for about 12 years now.

[bubibubi]

That's great!
In this case I can work on the EF 6.3 provider.

About this provider, it is a porting of the SQL Server provider plus an Ado provider (that uses OleDb and ADOX). ADOX is not referenced but loaded dynamically to avoid 32/64 bit issues. If ADOX cannot be loaded, migrations have some limitations.
There is no CI for this project.

Please feel free to contact me every time you need and I hope I can help you soon!

[FreddyDgh]

@lauxjpn FYI, I have done work converting the projects to dual-target .NET Framework 4.6.1 and .NET Core 3.1 over at https://github.com/FreddyD-GH/EntityFrameworkCore.Jet

@bubibubi I found that there were still 3400+ tests that failed on .NET framework before I even touched a line of code. I take it the project never had a 100% pass rate on tests? I can dig into the tests more later, but it seemed odd to me that so many were failing.

Regardless, I have found that there are currently some pretty significant issues with System.Data.OleDb that will prevent running EntityFrameworkCore.Jet on .NET Core for the time being:
dotnet/runtime#32509
dotnet/runtime#31177

Once those issues are resolved, I can start looking at whether or not the .NET Core tests at least have the same pass rate as the .NET Framework tests.

[bubibubi]

@FreddyD-GH great job!!!

The failing tests came from EF Core 1. When I ported EF.Core from 1 to 2 I did not update the tests.
EFCore.Jet.Integration.Test are tests that I used in EF 6. We could keep that tests. About other tests we probably should delete everything than copy SQL Server tests then start the porting. This is the hard work. Also, if a test fails in a global tests run, sometimes run alone works (probably because issues on System.Data.OleDb) so the tests cannot be included in CI.
During the port we can use also SQL Server Compact work https://github.com/ErikEJ/EntityFramework.SqlServerCompact/tree/master/test . We have similar issues

[bubibubi]

@FreddyD-GH after running the EFCore.Jet.Integration.Test can you tag the old project and merge your branch?

[lauxjpn]

@FreddyD-GH Looks good to me. I think we can use this as the base for the upgrade.

@bubibubi Seems it might be better after all, if we implement a CI pipeline for future PRs. Can you setup an AZDO account? I will implement the CI while working on the upgrade.

[FreddyDgh]

@bubibubi I don't think it makes sense to merge the branch quite yet. The bugs in the .NET Core version of System.Data.OleDb means that it doesn't offer much functionality at this point.

I would recommend the following procedures:

1. Let's wait a few days, because there is a PR in the works for the transaction issue. Once it's merged, we should be able to get a preview version that fixes quite a few of the tests. Maybe we can merge the branch after this stage.
2. After that, we can compare the current tests on Framework vs. Core and look for any further bugs in System.Data.OleDb, so we can report them. Hopefully, then, the .NET Core version of System.Data.OleDb can get up to par with the .NET Framework version.
   Edit: testing both x86 and x64 will be important at this stage to avoid headaches later.
3. If you think most of the current tests are outdated, we should probably upgrade the EF Core packages to the latest version (3.1), and port tests targeting that version instead. (I currently left the project targeting the 2.2 version of EF Core, which is probably not desirable.)

[bubibubi]

@lauxjpn Sorry for my stupid question... I use a private TeamCity server for my projects. Any suggestion for setting up the AZDO account? Should we share a password?

[bubibubi]

@FreddyD-GH

About point 3, the tests are definitely outdated. That's why I did not the port the provider from 2 to 3... Porting the 3.1 SQL Server provider tests to our provider will take days. But I think that it's necessary.

About OleDb I don't know. The only issue could be the release time. I hope they will fix it before EF Core 5... Do you have any infos about release?

[lauxjpn]

@bubibubi No, just setup your own personal account, setup an organization and add a free open source project. After that, you can add me as an admin as well.
Of course, I can do it as well, if you want me to.