DEV Community: Eros Fratini

LINQPad: More control over your queries

Eros Fratini — Sat, 21 Sep 2019 12:51:46 +0000

Keep exploring

Following my previous post of this serie, I'll keep exploring the tool, to show you some useful trick you can use to get a better control of the query.

If you're an experienced LINQPad user a lot of this stuff will look trivial, but I actually used it for years without knowing them, and I think some of you will appreciate a kickstart.

Control the Dump

As you already noticed the result of the Dump() extension is varying from type to type. Simple types and strings, for example, are just dumped as HTML strings on the output panel.

Objects are dumped as HTML table with their properties exploded on rows:

While arrays, lists and other enumerable types are rendered as tables in which properties are exploded in columns:

The Dump() extension is automatically searching for public properties, recursively, nesting the results where is needed and rendering them is its standard way.

But if you look at the overloads of the method you'll see 5 parameters:

description
depth
toDataGrid
exclude
alpha

Writing something like:

DateTime.Now.Dump("Current date:");

Will use the description param, nesting the result under a label, useful if your query is outputting a lot of variables.

With the depth parameter you can control how much deep the Dump() is exploding the object on the first render. By default is 5, that means the Dump is preparing 5 levels of nested HTML tables upfront, and it can be a little too much, especially on large and complex objects (you will notice that the execution of the query will slow considerably if you try to render hundreds of results together). Setting the depth to a lower value will speed up the first render, and you'll still be able to manually explode the collapsed properties on the output panel just clicking on them.

Try for example:

System.Globalization.CultureInfo.GetCultures(System.Globalization.CultureTypes.AllCultures).Dump(1);

You'll notice a faster rendering, as this collection is quite big.

With the toDataGrid setted to true the output panel will switch to a WPF control instead of the standard HTML, while exclude allows you to omit from the rendering specific properties:

System.Globalization.CultureInfo.GetCultures(System.Globalization.CultureTypes.AllCultures).Dump(toDataGrid: true, exclude: "Parent");

Finally, the alpha params setted to true changes the order of appearence of the properties. By default LINQPad write them as they appear in the class, with this you'll see them alphabetically ordered.

Implementing ToDump()

You may need to specify a custom way to show data of specific classes, for example explicitating the properties to show or even the HTML format to use.

The fastest way is implementing a ToDump() method in the class, so assuming the class is defined in the query itself, you can write:

class User
{
    public string FirstName { get; set; }

    public string LastName { get; set; }

    object ToDump()
    {
        return new {
            FirstName = this.FirstName,
            LastName = Util.WithStyle(this.LastName, "color:green")
        };
    }
}

In this case ToDump() is returning an anonymous object with the same properties, but LastName will be rendered in green color (notice the use of Util, we'll talk more about later).

Implementing this kind of method in your domain model is not optimal (in this case impossible, Util is defined only in LINQPad queries), so an alternative would be to use a static method in the "My Extensions" query.
"My Extensions" is a special query you'll find in My Queries tab, that's always included during the execution of the other queries, so whatever you link or define there will be available everywhere.

Still not optimal: you'll have to move your User class in My Extensions (or reference there the assembly which contains the class). That, as said, will import the class in EVERY other query you will run.

In the end the best approach is working with reflection and dynamic keyword.

public static object ToDump(object input)
{
    if (input.GetType().FullName == "User") // e.g. "MyApp.DataModel.User"
    {
        dynamic output = input;

        return new
        {
            FirstName = output.FirstName,
            LastName = Util.WithStyle(output.LastName, "color:green")
        };
    }

    return input;
}

Another good approach, assuming you're producing your own NuGet packages, is to include in them a set of LINQPad example to be imported in your queries, as I'll show in future posts.

DumpContainer examples

A simple .Dump() invocation can be limiting in some scenario: each one is going to create a new dumped output row, in a sequence, without the ability to change the actual dumped result during the execution of the query. But if you need to show a progress or an updating information in general is not the good thing to use.

DumpContainer is going to help you.

As the name suggests is a sort of container for dynamically updated contents, you Dump() it once and update its Content as you need during the lifetime of the query:

void Main()
{
    DumpContainer dc = new DumpContainer();
    dc.Content = "Starting the application...";
    dc.Dump();

    Thread.Sleep(500);

    for (int i = 1; i <= 10; i++)
    {
        dc.Content = $"{i}/10 - Processing...";
        Thread.Sleep(200);
    }

    dc.Content = "Completed!";
}

If you just need a progress bar to be shown you can use, guess what, Util.ProgressBar.

As I said before, each LINQPad query's referencing LINQPad.Util namespace, an utility belt full of useful tools to interact with LINQPad itself, and ProgressBar is a class to work with simple but effective HTML progress bars.

We can replace the previous code with something like:

void Main()
{
    Util.ProgressBar pb = new LINQPad.Util.ProgressBar();
    pb.Caption = "Progress";
    pb.Dump();

    for (double i = 1; i <= 10; i++)
    {
        pb.Fraction = i/10;
        Thread.Sleep(200);
    }
}

In this case you can interact with the Fraction or Percent property to advance the bar.

Manage input for interactive queries

In some scenario it can be useful to just not hardcode everything, but to ask for user input(s), in the same way you'll do with a console application.

Again you can access the Util namespace ad use the ReadLine() method. This will prompt an input box at the bottom of LINQPad window, its input can be assigned to a string variable and be used in the execution code:

Exploring the Util.*

Explore the Util namespace! Is really full of useful stuff that'll help you pushing your queries to the next level.

Some examples:

.Cmd() : Will execute any system command
.Dif() : A graphical comparer for objects, allows you to easily show differences between two given inputs
.KeepRunning() : creates a cycle to keep the query alive, useful when working with secondary threads
.CurrentQuery : is the object representing the current query, allows you to access the raw code and assembly references

Conclusions

LINQPad is really an amazing piece of software, knowing it well is going to improve by a factor of ten your productivity in the .NET ecosystem.

I'm going to write at least another post about it in the future, because there are still interesting stuff to talk about.

Stay tuned!

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

Eros Fratini — Fri, 13 Sep 2019 07:03:16 +0000

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.