> At my work I'm forced to use VB.NET :( which is a sad thing on its own,
but
> it got even sadder when using the NHibernate LINQ provider, since I found
a
> bug on it. When comparing strings with '=' operator, the expression tree
> generated replaces the '=' operator with the following function:
> Microsoft.VisualBasic.CompilerServices.Operators.CompareString. A better
> explanation for the "reasons" for doing this can be found here:
> http://blogs.msdn.com/b/vbteam/archive/2007/09/18/vb-expression-trees-
> string-comparisons.aspx
>
> So, I dug a little deeper and found a post from Fabian Schmied, who works
> with remotion, which talks about potential ways to solve this problem in
re-
> linq. The link to the post is this:
>
http://www.re-motion.org/blogs/mix/archive/2009/10/16/vb.net-specific-text-
> comparison-in-linq-queries.aspx
>
> If you follow that link you'll see I got in contact with him, and you can
> see I tried and solved my problem by hacking a little on NHibernate. After
a
> conversation with him, we come to the conclusion that there's a better way
> to solve this bug, which involves using the latest re-linq dll. Yesterday,
> Fabian made another post (http://www.re-
> motion.org/blogs/mix/archive/2010/07/15/support-for-vb-specific-string-
> comparisons-in-re-linq.aspx) in which he explains the way to handle string
> comparison expressions coming from VB.NET.
>
> After reading his post, I knew a better (not the best) way to solve this
> bug.
>
> I downloaded NHibernate trunk from sourceforge, created a failing test
case,
> and made it pass.
>
> Long story short, I found a bug in your codez and I fixed it, so I'd like
to
> know the following: what can I do to pass the fix to you guys?
There are other comparisons, casts, and code constructs in Linq
expression trees created by the VB.NET compiler which require VB.NET
specific code paths in the linq provider. String comparisons is one, the
'Like' keyword is another. Also convert.To* methods are sometimes wrapped
with convertchecked, which could cause a crash.
Another vb.net quirk is that the 'Count()' in the following:
Dim q = From c In ctxt.Customer _
Where c.Orders.Count() > 10 _
Select c
is converted to the property 'Count' which isn't present as a call
to the Count() aggregate but as a MemberExpression to the Count property.
VB.NET always adds the projection of a groupby query in the call
expression to GroupBy, C# compiler doesn't. This also creates cumbersome
code to obtain the real source of the groupby. I still have headaches
thinking about it... ;)
Then, for advanced misery, if you create a linq query in C# and
append it in VB.NET, and the C# query doesn't have an outer Select call
(e.g. the projection is inside the Join method call), the VB.NET compiler
adds a .Select(i=>i).
The useless coalesce statements added by the vb.net compiler are
better stripped out as well, because they cause complex SQL which is
unnecessary.
That's about it (there's some problem with IGrouping<> as well, but
it might be specific to how I handle things, so it might not be relevant to
how nhibernate's linq provider works).
Not sure if you handle those situations as well.
all in all it's a lot of pain, the situations where vb.net differs
from the C# stuff is undocumented and only found the hard way: trial / error
& bugreports. :(
FB
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
