Test with VB/F# to make sure expression tree differences are handled

[ajcvickers]

This is in particular reference to removal of Relinq since it was doing some normalization in this area.

• VB string equality/comparison, LanguageNormalizingExpressionVisitor for VB.NET string comparisons #19681

[bricelam]

These re-linq transformations handled things like this.

[ajcvickers]

Note from triage: add a cross-language functional tests project.

[bricelam]

I've added a VB test suite with coverage for things that we've fixed (string comparisons and checked arithmetic).

We still have a few known bugs:

• Extensive SQL translation in where-statement with nullable types #27202
• Calling SelectMany from VB throws InvalidOperationException #29185
• Simple VB Group By clause throws #30773

But I think we can say that the VB part of this issue is done.

[gaglia]

Hi,

Is there any news regarding this problem?

We are testing with EF 8 and still encounter the same problems.
The problem is very impactful in our opinion, we have just finished a huge migration work from Entity Framework 4 to .NET 8 + EF 8 but we are experiencing big problems for certain queries due to these mistranslations for VB.NET

Thank you

[roji]

@gaglia this is a general issue tracking improving testing for VB/F# - please vote on specific translation issues so that we know what you're blocked by. See the issues linked to just above; if you're running into something that isn't already covered, please open a new issue with a minimal code sample that shows the problematic query.

[gaglia]

Hi @roji

I'm experiencing the same problem already reported in issue #31578.

Wrong translation of WHERE with simple filters for string fields

If you need any other information, just let me know.
Thank you

[roji]

@gaglia then be sure to vote on #31578, which currently has just one vote - that's a big part of how we choose which issues to prioritize.

[koenigst]

I created a test project for F# in #34541. I don't know of any issues concerning difference in syntax trees with F# so I created a sample test. Are any issues known that I could test?

[roji]

@koenigst I don't think we're aware of any specific problems, but then again EF has generally received little usage under F#, so it may be that the issues haven't been discovered/reported yet...

[bricelam]

@koenigst The area-F# label and efcore/EFCore.FSharp repo might have a few known issues in them.

[koenigst]

@bricelam The area-F# label has no open or closed issues concerning query translation. I found one, two issues in efcore/EFCore.FSharp. To test them the test project would need to take a dependency on that project which I would find weird. Take the dependency or leave it for now?

[roji]

Ah, interesting... So it seems that the EFCore.FSharp package has actual method translators to take care of some F# expression tree variance. I'd need to look (and probably discuss with the team), but I think we should consider bringing these into EF itself (we already have various normalization support for VB.NET constructs in the box). These also may make more sense as preprocessing normalization rather than a method translators.

Otherwise, for the time being, it seems that EFCore.FSharp is necessary for proper query translation of some constructs, so I think it makes sense to take a dependency on it from the F# functional test project - you can go ahead and do that.

[roji]

FYI opened #34552 to track moving the query translation stuff from EFCore.FSharp into EF.

[koenigst]

Otherwise, for the time being, it seems that EFCore.FSharp is necessary for proper query translation of some constructs, so I think it makes sense to take a dependency on it from the F# functional test project - you can go ahead and do that.

The package EntityFrameworkCore.FSharp does not exist in the dnc package sources. I don't have the rights to mirror the package from nuget.org.

I will mention the two solved issues in #34552 and not pursue them here.

[roji]

@koenigst makes sense, thanks for looking at it. The right thing to do is probably to bring in the query fixes from the external package into the core as per #34552.