Wow, this one's a much bigger problem than I thought, even though I'd read about those pesky coalesce statements.
I don't handle any of those situations you mention, only the string comparison through '=' operator. What this means is that the behavior of the LINQ provider for NHibernate will never be reliable when using it in VB.NET? Or at least it will be a lot of work to make this happen. At least we can now forget about equality comaprison :P Which do you think will be the best way to handle this mess? Trying to transform VB.NET expressions to their C# counterpart? Because with the re-linq implementation to solve this kind of thing there are two options: trying to be loyal to VB.NET expressions and do something about them or ignore them. In the end what I did was to ignore things specific to VB.NET. On Fri, Jul 16, 2010 at 03:46, Frans Bouma <[email protected]> wrote: > > 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]<nhusers%[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]<nhusers%[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.
