Reproduced indeed.
Test:
Dim metaData As New LinqMetaData(adapter)
Dim q = From c In metaData.Customer _
Group By c.Country, c.City _
Into Count() _
Select Country, City, NumberOfCustomers = Count
expression tree:
: Initial expression to process:
value(SD.LLBLGen.Pro.LinqSupportClasses.DataSource2`1[NW26.Adapter.EntityClasses.CustomerEntity])
.GroupBy(c => new VB$AnonymousType_3`2(Country = c.Country, City = c.City),
($VB$It, $VB$ItAnonymous) =>
new VB$AnonymousType_4`3(Country = $VB$It.Country, City = $VB$It.City, Count = $VB$ItAnonymous.Count()))
.Select($VB$It => new VB$AnonymousType_5`3(Country = $VB$It.Country, City = $VB$It.City, NumberOfCustomers = $VB$It.Count))
Will now check how the expression tree looks when it's compiled with the old compiler and with C# too.
(edit)
C# equivalent:
var metaData = new LinqMetaData(adapter);
var q = from c in metaData.Customer
group c by new {c.Country, c.City}
into g
select new {Country = g.Key.Country, City = g.Key.City, Count = g.Count()};
Tree:
: Initial expression to process:
value(SD.LLBLGen.Pro.LinqSupportClasses.DataSource2`1[NW26.Adapter.EntityClasses.CustomerEntity])
.GroupBy(c => new <>f__AnonymousType137`2(Country = c.Country, City = c.City))
.Select(g => new <>f__AnonymousType138`3(Country = g.Key.Country, City = g.Key.City, Count = g.Count()))
VB.NET clearly uses a different construct. The main issue is that the aggregates are in the groupby clause in vb.net, but in C# they're in the projection.
When I rewrite the C# code to use lambda's instead, which mimic the VB.NET expression tree, I get the same error:
var metaData = new LinqMetaData(adapter);
var q = metaData.Customer.GroupBy(c=>new {Country = c.Country, City = c.City}, (a, b)=>new {Country = a.Country, City = a.City, Count = b.Count()})
.Select(a=>new {Country = a.Country, City = a.City, Count = a.Count});
In vs.net 2012 I get the same error btw. It could be because roslyn is still invoked, not sure. It's also a bit moot as it doesn't solve the problem at all, the problem is present in the current framework.
There's a problem though: the error it runs into is in code to work around the issue of the old vb.net compiler, so it interprets the tree produced by that compiler. What I need is to see how that tree looks. I can't make changes to the current code without it, as changing the code might break the code of older vb.net compilers. I'll try on an old VM with the v3.x environment on it, to see whether it works there. No roslyn on that machine.