Three month ago OzCode launched it’s new version 3.0, that introduced the new LINQ Debugging feature. This was a breakthrough in the LINQ debugging experience, and we’ve been hearing feedback from customers who tell us that it’s been a life-changing feature to them – allowing C# devs to visually break down and understand each and every part of a complicated LINQ query.
So why have we been so restless to release the new 3.1 version?
Although the original LINQ debugging experience was great, it wasn’t all perfect. It only worked with LINQ to Objects queries (in other words, with IEnumerable<T> collections). When working with LINQ to Entity Framework, LINQ to SQL, or LINQ to anything, we work with IQueryables (see IEnumerable vs IQueryable). We couldn’t enjoy OzCode’s new LINQ Debugging features, and there were some good reasons for that…
Why IQueryable debugging wasn’t supported (till now)
When working with LINQ to Entities or LINQ to SQL, we are usually working with a database. Databases tend to get quite large.
The premise of the OzCode LINQ debugging feature is that it shows you everything, displaying all the values that passed through the LINQ query, including the source. Since we’re working with a database, the source is usually an entire table, which could potentially contain millions of rows. Counting and displaying all the items in the table can freeze our debugging session or even crash Visual Studio with an OutOfMemoryException.
After a lot of thought, we decided to evaluate the data up to an arbitrary number of rows – 100,000. This is a big enough number that should give you some sense of what the query is doing, but small enough that analyzing it in less than a second, if working with a local database. If the data exceeds 100,000 items, OzCode will display a popup explaining what happened.
In this case, the data indeed exceeded 100,000 items. OzCode is displaying partial results, taking just the first 100,000 items in the data source.
Behind the scenes, OzCode is using Take() to give you these partial results.
Display actual results when the data is very big
You might want to see actual, complete results, not just partial results. To be able to do that, OzCode offers a workaround: simply add a .ToList() somewhere in the query where you’re convinced the amount of results won’t exceed 100,000. We can leverage Edit & Continue to add that .ToList() without having to stop the debugger:
In case ToList() or ToArray() is present in the query, OzCode will start evaluation from there.
What can LINQ Debugging do for you
With LINQ Debugging we can write our long LINQ queries that we love and stop compromising on debugging! OzCode shows the number of items returned by each LINQ operator. Clicking on this indicator will show us a DataTip with all the items. We can then choose a specific item and see how it “travels” within the LINQ pipeline.
If you aren’t yet familiar with LINQ to debugging, there is much more it can do – see all the features here.
OzCode now supports LINQ debugging with any kind of IQueryable collection. This can be Entity Framework, LINQ to MongoDB or even LINQ to Twitter.
Support for IQueryable was one of the most highly requested feature in recent months, and we’re excited to make it available for you.
Of course, there’s more 🙂
Ever wanted to track how a certain collection was transformed between one LINQ operator to the next? In our next blog post, I will cover some more cool new features we added in v3.1, such as the new “Pin” functionality in the LINQ analysis window. Here’s a sneak peek:
In this query, which of the good (above-average) students came from which departments? OzCode will show us:
var aboveAverageStudents2 = from department in StudentRepository.GetAllDepartments() let departmentAverage = department.Students.Average(student => student.Grade) from student in department.Students where student.Grade >= departmentAverage select student.Name; (edited)
Please keep sending us your feedback, and have a great debugging day!