May LINQ CTP - Update Goodness
The new May LINQ CTP is out and it brings a slew of updates to the previous CTP. I, of course, grabbed it as soon as I could and installed it. I've been working on an XLinq article for CodeProject in between classes, midterms, school project, and work, so I popped open that solution in Visual Studio first. I noticed a few changes right away.
VB.NET Changes
One of the first things I noticed in my solution was that all my VB queries were completely broken. That's because this CTP comes with the changes to the VB.NET LINQ syntax that Paul Vick posted about a few days ago. I think this is a great thing as it enabled Intellisense in queries in a way that wasn't there before. Also, as I stated in the comments on Paul's blog:
...with XLinq being such a key piece of Linq for VB.NET (Obviously. I mean, you guys are including XML literals. That's got to mean something.), I would almost think you would have wanted to adopt the FLWOR style queries that XQuery has in the first place. It seems to me that would certainly make VB.NET a more attractive option for those who do a lot of work with XML.
As soon as I re-ordered the queries, they worked perfectly. And, what's more, I had nice Intellisense in these queries. A much welcome change.
C# Changes
Some of my C# queries were broken as well. Now, I might have missed this before, but everywhere I looked the way to do nested queries looked like this:
var entries = from log in EventLog.GetEventLogs(),
entry in (EventLogEntries)log.Entries
where log.Log == eventLog
select entry;
Now, as I said, I could be wrong. But that compiled and worked before. And that was all I could get to work. The new CTP introduces the join operator. But that's not really what I wanted. So I looked at the new nested query syntax in the SampleQueries samples and I reworked my query to look like this:
var entriesByCategory = from log in EventLog.GetEventLogs()
where log.Log == eventLog
from entry in (EventLogEntries)log.Entries
select categories;
Which is great! This is, to me, a much more natural way to query hierarchical data than the previous way. (If indeed I am correct in thinking that this wasn't the way to query data like this before.) (BTW, in case you were wondering, the EventLogEntries class is just a wrapper I wrote around EventLogEntryCollection because it doesn't implement IEnumerable<T>
ASP.NET Support
This CTP also introduces two things to integrated LINQ into ASP.NET apps. The first is an ASP.NET LINQ Application template under File|New|Website. This has references to System.Query and family and uses the experimental LINQ compiler. This will be useful for me as I can integrate my XLinq stuff into an IHttpHandler to return some RSS. Good stuff.
The second thing is a new DLinqDataSource provider. This provider acts just like the other DataSource classes. So you can hook up your data driven controls to DLinq queries rather than straight to the DataSet or whatnot.
Samples
There are a bunch of new sample applications in the /Samples directory. The SampleQueries application has been updated with the new standard query operators (Join, First, ElementAt, etc.) There are also a few databinding example applications. The WCFLinq app.
One of the applications that really intrigued me was the ExpressionTreeVisualizer addin for Visual Studio. With it, you can see what your Expression tree looks like in an intuitive sense. Hovering over the following:
Expression myExp = Expression.Add(
Expression.Multiply(
Expression.Constant(5),
Expression.Constant(10)),
Expression.Constant(20));
Gives me the normal debugger tooltip that shows me that I've got:
{Add(Multiply(5, 10), 20)}
Which, if you ask me, is pretty dang sweet in and of itself. But, using the debugger visualizer, I can see it in a tree view. And, since these are called Expression
Trees, that seems kind of appropriate. Very nice work guys. This is good stuff.
Another of the sample applications that caught my eye was this LogicProgramming sample. There is some
heady stuff in here that it's going to take me a while to wrap my arms around.
IQueryable<T>
This is the magic that makes DLinq happen. This converts your Expression Tree into SQL for you. And, theoretically, could convert your Expression Tree into...anything. I wouldn't do nearly as good of a job describing it as Matt Warren does
here.
Anyway. Those are the things that caught my eye in this release. Good stuff to think about. Once I get done with that XLinq article, I'll start one on Expression Trees. There's a lot there.