All Blog Posts

How to Debug LINQ to Entities using LINQPad

Debug LINQ in LINQPAD banner

Entity Framework (EF) and LINQ are powerful tools that make the job of developing software applications much easier. EF provides an abstraction layer to the underlying data source, while LINQ to SQL allows you to easily query it. The alternatives to LINQ are SQL queries or stored procedures, which can be tedious to maintain and can add significant overhead to the software development life cycle. For example, unless you use EF Migrations or something of the like, you might have to use a separate source control mechanism to manage versions of your SQL scripts. In fairness, SQL generally has faster execution times than LINQ.

With LINQ, we can write complex queries using tools and languages (C#, Visual Studio, ReSharper, etc.) most developers are familiar with. Yet, sometimes there are situations where we don’t quite understand an expression, or we need to isolate some part of a query to debug it. In those instances, LINQPad can be very handy. A small utility, available both in free and different premium editions, LINQPad allows us to write test queries against EF or a variety of other sources, such as OData or WCF services.

In this post, I will show how to quickly set up a connection in LINQPad so we can write queries using EF and LINQ. I’ll also cover how to use the Dump method to graphically display the results set or, more generally, to inspect an object. In this example, I assume we have a C# project setup with a public class inheriting from DbContext. The model is database first, and it is based on the Northwind database.

First, we need to setup a connection. Click on Add Connection. 
Add Entity Framework Connection

In the Choose Data Context window, select EntityFramework (DbContent V4/V5/V6) and click next. 
Choose Data Context

In the Connection window, specify the parameters of the connection:

Path to Custom Assembly: The path to the dynamic link library (DLL) that contains the public class inheriting DbContext(). Use the Browse link to locate it in the file system. Hint: In Visual Studio, right click on the project and select “Open folder in File Explorer.” Most likely, the DLL is located in the bin folder of the project.

Full Type Name of Typed DbContent: Using the choose link, select the class with the context that contains the DbSet we want to query.

How Should LINQPad Instantiate Your DbContext: This setting depends on how your project is set up. In this example, I am using a connection string in the web.config file.

Path to the Application Config File: This is the path of the config file that contains the connection string.

Production Database: If this option is selected, when you run a potentially dangerous query, LINQPad will warn you that you are working on a production database.

Remember this Connection: A self-explanatory setting—I suggest leaving it checked, unless there are security concerns.
Remember This Connection

Once the connection has been created, select it in the query tab. You can then write a simple C# statement with a query. In this example, we want to select the first 10 orders with related details. Click on the Execute button (or hit F5 on your keyboard) to run the code. 
Execute EF Query

In the results pane, we see a graphical representation of our orderDetails object. That’s the result of the Dump() method of the ordersDetails object.

Um, wait a second… orderDetails is an IQueryable object, so where does Dump come from?

Dump is an extension method provided by LINQPad. It prints the query result in the nice formatting shown above. Notice how we can navigate through the properties (customer, details, etc.) of an order by clicking on them. Dump can be called on pretty much anything. For fun, you can try 5.Dump(). Guess what you’ll get?

If you agree that a picture is worth 1000 words, then you will probably find the graphical representation of the query result very helpful. We can use the buttons in the result pane to translate from Query Syntax to Method Syntax, to see the SQL or CIL generated by our code, or to get a tree representation of the result set.

Another convenient feature of LINQPad is saving code snippets. If I write a query (or any other code) that is not so straightforward, I save it with a meaningful name in LINQPad for future reference. If, weeks later, I have to write something similar and I need to refresh my memory, I can quickly recall it without having to dig through several repositories and thousands of lines of code.

Sometimes simple things can make life easier. LINQPad is a simple application, yet very powerful, and it makes my job much simpler. I hope I have convinced you to give it a try, and that you too will find it useful!