Dumpify puts a .Dump() on the end of any expression in a console app

One extension method, borrowed from a different tool

Dumpify exists to do one thing: give console applications a .Dump() extension method, in the style of LinqPad. The README states the purpose as improving productivity and debuggability by adding .Dump() extension methods to console applications, and the project description says the same, similar to LinqPad's.

That reference explains the design better than any feature list. LinqPad is a scratchpad where you type an expression and see the result, and the problem it solves for a LinqPad user is that a console application has no equivalent. You have to either write a temporary Console.WriteLine and hand format the output, or attach a debugger and step through the object graph in a visualiser. The Dump() call is the third option, and it costs one method call at the end of an expression:

new { Name = "Dumpify", Description = "Dump any object to Console" }.Dump();

The library is a NuGet package, published as Dumpify, and the feature list describes it as dumping any object in a structured and colourful way into the Console, Trace, Debug events or your own custom output, with support for properties, fields and non-public members, maximum nesting levels, circular dependencies and references, styling and customisations, and different output targets of Console, Trace, Debug, Text and Custom.

The audience is therefore a developer who works in a console application, a web application's startup path, a tool, a script, or a test harness, and who needs to see an object's real contents at a point in the code. The Fast line at the end of the feature list is the project's own claim about its output performance, and the README gives no measurement behind it.

The output is a table, and the table has a border style

The rendering is a table, and the configuration surface is aimed at making that table readable in whatever terminal you happen to be using.

Two display options are toggled at the table level. ShowMemberTypes adds a column with each member's type, and ShowRowSeparators draws a separator between rows. Both can be set globally on the default configuration or passed for a single call:

//globally
DumpConfig.Default.TableConfig.ShowMemberTypes = true;
DumpConfig.Default.TableConfig.ShowRowSeparators = true;

new { Name = "Dumpify", Description = "Dump any object to Console" }.Dump();

//or Per dump
new { Name = "Dumpify", Description = "Dump any object to Console" }.Dump(tableConfig: new TableConfig { ShowRowSeparators = true, ShowMemberTypes = true });

The border style is the part worth knowing about, because the README says that if tables look garbled in your terminal, in VS Code or in Windows Terminal, you can change the border style. The available styles are Rounded, which is the default, Square, Ascii, None, Heavy, Double, Minimal and Markdown:

// Use ASCII borders for maximum compatibility
DumpConfig.Default.TableConfig.BorderStyle = TableBorderStyle.Ascii;

// Or use Square borders (simpler Unicode characters)
DumpConfig.Default.TableConfig.BorderStyle = TableBorderStyle.Square;

The Ascii option is the pragmatic one, because a table drawn with Unicode box drawing characters depends on the terminal having the right font and encoding, and a developer on a bare console or over SSH will recognise ASCII borders immediately. The Markdown option is interesting for a different reason, since it makes the output pasteable into a pull request or an issue.

The configuration is described as highly configurable in the feature list, and the table options are the visible part of that; the per dump variant means a global style and a one off exception can coexist without fighting.

MembersConfig decides what is visible, and the filter is a callback

By default a dump shows the public properties of an object. MembersConfig opens that up, with a boolean to include fields, a boolean to include non-public members, and a MemberFilter that takes a callback.

The simple case turns on the parts of an object the compiler would normally hide:

new AdditionValue(1, 2).Dump(members: new MembersConfig { IncludeFields = true, IncludeNonPublicMembers = true });

The filter is the more capable option, and the README documents the context it receives. The MemberFilter receives a MemberFilterContext, which provides ctx.Member for access to the member metadata such as name, type and attributes, ctx.Value for the actual value of the member, which is lazily evaluated, ctx.Source for the parent object containing the member, and ctx.Depth for the current nesting depth during rendering.

That context is what makes the filter general rather than a one trick feature. Filtering by attribute excludes members marked with something such as JsonIgnore, which is what a developer who has already declared a serialisation contract would want:

new Person()
{
    Name = "Moaid",
    SensitiveData = "We don't want this to show up"
}.Dump(members: new MembersConfig { MemberFilter = ctx => !ctx.Member.Info.CustomAttributes.Any(a => a.AttributeType == typeof(JsonIgnoreAttribute)) });

Filtering by value excludes null or empty values, and filtering by depth shows only top level properties. The depth filter in particular pairs with the nesting controls, since a dump of a deep graph can be restricted to its first level without changing the configuration globally.

The lazy evaluation of ctx.Value is worth noting for performance, since a filter that inspects a value should not force every property of a large object graph to be materialised.

Circular references are a case to handle, not a crash

Dumping an object that refers to itself is the case that breaks naive dumpers, and it is the case the README demonstrates.

The example builds two Person objects, sets each one's Spouse to the other, and dumps one of them:

moaid.Spouse = haneeni;
haneeni.Spouse = moaid;

moaid.Dump();
//You can define max depth as well, e.g `moaid.Dump(maxDepth: 2)`

Two mechanisms are in play. The circular reference is detected and represented rather than followed forever, and the maxDepth parameter bounds how deep the traversal goes regardless.

The second one matters just as much, because the depth limit is not only about cycles. A dump that is allowed to walk an entire object graph will happily print thousands of lines when what you wanted was the shape of the top level. The example's own comment shows the intended usage, dumping with a max depth of two when the graph is deeper than the question being asked.

The feature list states this as support for maximum nesting levels and for circular dependencies and references, and the same idea of bounded output reappears in the truncation configuration for collections, which is the subject of the next mechanism. Between the two, a dump is bounded in depth and bounded in breadth, which is what makes it safe to leave in a console application next to a large in memory graph.

Truncation keeps a big collection from filling the terminal

Depth is one axis of growth and length is the other, and the README handles it with the TruncationConfig, where the MaxCollectionCount property sets the limit.

int[] arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

// Outputs only the first 5 elements with a truncation marker
arr.Dump(truncationConfig: new TruncationConfig { MaxCollectionCount = 5 });
// Shows: 1, 2, 3, 4, 5, [... 5 more]

// You can also truncate from the tail (last N elements)
arr.Dump(truncationConfig: new TruncationConfig { MaxCollectionCount = 5, Mode = TruncationMode.Tail });
// Shows: [... 5 more], 6, 7, 8, 9, 10

// Or show both head and tail with truncation in the middle
arr.Dump(truncationConfig: new TruncationConfig { MaxCollectionCount = 6, Mode = TruncationMode.HeadAndTail });
// Shows: 1, 2, 3, [... 4 more], 9, 10

The three modes are head, tail and head and tail, and the last one is the interesting case, because it keeps the first and last elements with a marker in the middle. For a queue or a log buffer, the elements at the head and the tail are the ones that explain what happened, and the ones in the middle are usually the ones you do not need to look at.

The README also states that this applies to arrays, dictionaries and collections, and the examples section shows the same idea applied to a one dimensional array, a two dimensional array declared as new int[,] and a dictionary of string to string, each dumped with the extension method on the expression.

Console is one target of several

The output targets listed in the feature list are Console, Trace, Debug, Text and Custom, and that list is what turns Dumpify from a console helper into something a tool author can use in a hosted process.

Console is the obvious one and the one the examples show. Debug and Trace matter more than they first appear, because in a .NET application the Trace and Debug outputs are what a listener or a diagnostic subscriber can pick up, so a dump can travel through the existing diagnostics pipeline rather than being printed directly to standard output. The Text target is the plain one, for a file or a buffer, and Custom is the extension point for a target of your own.

The topic list on the repository is consistent with that reading: console application, debugging, instrumentation, logging, serialization and NuGet. The library is positioned as a diagnostic aid for a process, not only as something for a REPL.

The distinction from a logging framework is the one to keep in mind. A logger produces structured events with levels, categories and sinks, and it is designed to be left in the code and controlled at runtime. A dump is a human readable rendering of an object at a point in the flow, with a truncation marker and a border style, and it is designed to be removed once the question is answered. Treating one as the other is the mistake to avoid, and it is why the feature list emphasises output targets rather than levels.

Install it from NuGet and treat the version label seriously

The library is published as a NuGet package and the README gives three ways to take it. Either run dotnet add package Dumpify, or Install-Package Dumpify, or use Visual Studio's NuGet Package Manager.

dotnet add package Dumpify

That is the whole installation story, and the repository is laid out to match a package rather than an application: src/ for the source, nuget/ for the package assets, assets/ for the images used in the README, docs/ for the documentation, plus Directory.Build.props, Directory.Packages.props and nuget.config for the build and packaging configuration, and a.github/ directory with the build and publish workflows named build-dumpify.yml and publish-dumpify.yml. There is an AGENTS.md at the root as well, which is the sort of file that appears when automated tooling is expected to work on the repository.

Two things to check before relying on it.

The first is the version line. The recent releases are 0.8.0 on 2026-09-29, 0.7.0 on 2026-02-22 and 0.6.6 on 2024-05-05, and every one of them is labelled as a preview version, both 0.8.0 and 0.7.0 explicitly. The package is therefore shipping as a preview, and a team that takes a dependency on it should expect the surface to move.

The second is the terminal. The table output depends on the console's ability to render box drawing characters, and the README says plainly that tables can look garbled in VS Code, in Windows Terminal and elsewhere, which is why the border style is configurable and why an ASCII style exists. Checking the output on the terminal you actually use takes a minute and saves an afternoon.

The licence is MIT, and the repository is not archived, with the last push on 2026-09-29, the same day as the 0.8.0 preview.

Editorial conclusion

Dumpify suits a developer working inside a console application who wants to look at an object right now, with the private state and the circular references included, rather than at a curated view of it. It does not suit a production service that needs structured logs, since the output is a human readable table rather than a log event, and the extension method is awkward in code that should not depend on a debugging aid. Verify first that your console renders the table borders, since the README describes garbled tables in some terminals and offers an ASCII border style for exactly that case, and check the package's preview status, because the recent releases are labelled preview versions.

Frequently asked questions

Official sources

1. License: MIT
2. MoaidHathot/Dumpify on GitHub
3. Project website
4. README
5. Releases