Over the festive break I spent a bit of time trying some of the challenges in this year's Advent of Code. I wrote the logic for my answers using LINQPad, and it struck me that this has become one of my favourite developer tools. So here are a few of the reasons why it's become a key part of my toolkit, and why it might be a useful thing to add to yours too.
Visual Studio has got most C# devs pretty much use to all the boiler plate involved in even a small console app. A folder. A solution file, a project file and an entrypoint class file, plus some hidden folders to keep VS happy at an absolute minimum. Plus potentially config files and other stuff too.
But a LINQPad query is just a single file - no matter what you do with it. That file can be a single expression to evaluate, a series of statements or a full program with a
Main()
method, other methods you want and classes. The tool doesn't care - it just evaluates the code for you:
There's a debugger too - so you can set breakpoints and pause execution as you would expect. So it's pretty easy to write and validate small programs to check out ideas for code or to solve a specific focused problem.
LINQPad's result display framework provides a set of UI controls you can use in your code, so it's possible to build simple interactive tools in a single file. You can have textboxes and buttons in the results pane which work like a normal program. They generate HTML for the results pane, so you can create the UI you want by composing controls and things like panels and then outputting it all with the
Dump()
extension method (which knows how to display pretty much anything in the results view). So you can easily create buttons with event handlers for example:
LINQPad includes a regular expression tester that's built this way. It gives you text boxes for your expression and your input text, and it shows you the resulting
Match
objects (if there are any):
And if you do need to get fancier, you can have WinForms (and probably WPF - but I've not tried that) code too, if you want. Though for anything complex here VS is probably easier since it has a visual designer for these UIs. But you can absolutely open windows if you need to.
The other thing that makes little experiments very easy here is that you can easily add Nuget packages to a query, and make use of types defined in those packages. It has it's own UI which can search for and pull down packages, and that relation (and using statements if necessary) get attached to your query:
So you can make use of any external libraries you need for your experiments...
As you might guess from the name, LINQPad is great for messing about in databases and LINQ queries against anything that can store data. It will connect to all the common things .Net devs encounter. So you can grab data from Azure SQL or test queries against a locally installed DB server. But it also supports things like SqlLite. That can be useful for reading from DBs you have locally. But to me one of the most useful things is that it can easily work with in-memory connections there:
using (var db = new SqliteConnection("Data Source=:memory:")) { // create tables // insert data // do queries }
I've found that really helpful for scenarios where I want to do a throw-away experiment with some SQL syntax, or I need to temporarily store a chunk of data that wouldn't work well in a .Net
List<T>
or similar. I'm sure we've all had those jobs where you find a giant data file and need to do some processsing on it. Throwing the data into an in-memory database can make some of those operations way easier.
It's great for some more obscure things too. When you run a query, the default output view is the results pane, where you can see the console output of whatever you ran. But there are some alternative tabs for looking at the generated IL and the Roslyn syntax trees from your code.
Now I agree that these aren't often useful - but when they are they're very useful.
I wrote a while back about using Roslyn code generation for a modern alterantive to some reflection tasks. And when I was working on that I found the data structures for the Roslyn APIs a bit challenging. But being able to type a code fragment into LINQPad, run it, and see what the syntax tree for it looks like is really helpful in that scenario. I'd used an online tool for my previous post, but you can do this with LINQPad too:
Both the tree and the diagram representation here can be really helpful when you're considering why a Roslyn data structure needs to be the way it is.
Nothing is perfect, alas. If there was one thing I'd change about LINQPad it's some of the auto-complete behaviour in its text editor.
The parser / editor being used will do proper autocomplete
if you have a licensed copy, which makes it similar to writing in Visual Studio. But it can be a bit over-agressive with inserting
lambda expressions
as you type. If you start typing
MyTable.Sele
hit control-space to complete, it will throw in
ct(x =>
for you - to get the selection expression going.
But annoyingly it will apply this behaviour to methods which don't necesarily need that lambda too. If you have an array of
int
s, and type
myArray.Cou
and hit the autocomplete then it adds
nt(x =>
as well. Now there is an overload of
Count()
which takes an expression to filter the list. But I'm rarely wanting that one, yet it always adds the beginning of the lambda. And that means I find myself always needing to delete the extra business.
It's not the end of the world - you do get used to expecting that behaviour. But it's made a bit more tedious by swapping between different editors with different behaviours for this.
But lets not end on a negative. There's loads more on offer in this tool as well as the things called out above. I've focused on features that have helped me recently here, but I've skipped over good stuff I've not needed. Like a pile of "here's how you can do it" example queries to help you learn, the ability to run VB and F# code as well, Copilot integration, and support for XUnit testing.
There's a free version you can download if you fancy giving LINQPad a try - so it's easy to give it a go.
Maybe it could become an important part of your developer toolbox too?
↑ Back to top