LINQPad: Why I love it and why you should, too

Loving the tool

I started using LINQPad something more than 10 years ago, and it followed me through endless machines and system installations.
It is one of the first 5 programs I install on every new PC.

I'm what is called now a full-stack developer, focused mainly on server-side stuff in .NET. I saw the thing evolving from FW2.0 to the current Core3.0, and LINQPad was always there at my side, helping me study the language, explore the framework, prototype ideas and (sic) run fast patches for data in production. All the good and bad things, we did them together.

For the ones of you who never used it, a quick introduction.

Where and how

LINQPad is downloadable from https://www.linqpad.net/, and it came in different flavours, depending on your needs: for specific framework versions / with installer / without installer / for x64 assemblies (AnyCPU) / etc...
For any of these you can have a free edition: the limits of the free edition are related to the intellisense, NuGet integration and in general coding automation we're used to have in IDEs like Visual Studio.

You just download it and launch the .exe, that's it.

UI

Once you're there, you'll see something like:

That's pretty straightforward: on the right side you've the main code editor, on the left a list of connections you can use in your query and a list of saved queries.

Let's first examine the code section.

Writing code

An empty query defaults on "C# Expression" (overridable via Edit -> Preferences -> Query).
The available options are Expression, Statements and Program in both C# and VB, SQL, ESQL and even F#.
If we are in Expression mode, that means you can only write a single C# expression whose output will automatically be dumped on execution.

Executing the query (F5) will open the ouput panel with the result of your single expression and other interesting tabs. From here you can for example examine the underlying SQL queries produced by your code (if any), the intermediate language and even the syntax tree analysed by the compiler.

With a single expression there's not a lot to do, so usually you'll use the "C# Program" style. Switching to it will change the template, creating a void Main() method to represent the entry point of our query code.

To reach the same result (to show in the result panel the current DateTime) we have now to explicitly select the value(s) to dump.
LINQPad has a set of extension methods that allows us to interact with LINQPad itself, and the most common one is the Dump() method:

void Main()
{
    DateTime.Now.Dump();
}

This will produce a string representation of the DateTime.Now, as before, but now we can interact with variables and dump intermediate results:

void Main()
{
    var date = DateTime.Now;
    date.Dump();
    date.AddDays(3).Dump();
    date.AddMonths(1).Dump();
}

The Dump() method is powerful, tremendously powerful, with a lot of overloads and options. For this quick introduction the only thing I'll underline is that the output is basically an HTML representation of the data, and the Type of the data itself determines what we see.

Prototyping

The main reason I use LINQPad is to write fast snippets of code, which I can test interactively 100 times faster than in Visual Studio: there's also a step-by-step debug, so the experience is really close to the IDE.

You're not confined to the Main() method of your query, you can create the classes and interfaces you need just outside of it.

For example:

void Main()
{
    List<User> users = new List<User>();
    users.Add(new User("John", "Doe"));
    users.Add(new User("John", "Wick"));

    users.Dump();
}

public class User 
{
    public User(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Is a perfectly legit query.

Import your assembly

Let's say you've an application written in .NET framework, or .NET core, with some dependencies to other libraries, like a MyApp.DataModel, holding your domain classes and interfaces. You can actually import them in a LINQPad query simply going to Query -> References and Properties: from here you can import system assemblies, browse for a specific DLL produced by your projects or (with the Pro edition of LINQPad) connect to a NuGet feed.

You can add a list of namespaces to import in the query through the "Additional Namespace Imports" tab.

At this point you'll be able to use in your query everything's inside the imported assemblies, allowing you to explore and test functionalities fast.

Conclusions

This introduction is just grasping the surface of all the functionalities LINQPad has, but it should be already clear how much important this tool can become in a work scenario or just in learning new concepts of the language and the framework itself (just take a look to the "Samples" tab in the lower left corner). Using it in the right way improved drastically my overall productivity.

In future posts I'll examine in depth the Dump() method, data connections and a better integration with Visual Studio.

Comments

[JustinKaffenberger]

One thing I recommend is configuring your queries folder to point to a git repo on your machine. This gives you quick access to all of your queries while at the same time making it easy to push those to a remote repo to share with others on your team.

[Drew Knab]

This is great and I love LINQPad. I've started trying to shift myself over to csi/fsi from LINQPad though. It's really nice to have a small REPL shell right in Visual Studio, I've found not switching context has been kinda helpful in not drifting off task.

[Josiah Bradbury]

I use expressions and statements all the time, mainly for a lot of database querying. Or in the case of statements, making a lot of .net scripts.

Or when I need to experiment and figure out datetime.tostring() formats quick