DotnetLog.Viewer 0.2.0

dotnet-log-view

A viewer for the log written by the dotnet-log tool. It runs a small web server on your machine and opens a page in the browser where you walk the run of the application step by step: forward, backward, into a call, out of it.

On every step you see three things at once:

• the source file and the exact line the program was on at that moment;
• the values of the arguments, of the object's fields, of the result — as they were on that step, not as they are now;
• the call stack, with the whole way up to the top of the chain.

Nothing leaves your machine: the server listens on 127.0.0.1 only. The single exception is source code of other people's NuGet packages, which the viewer can fetch from the address recorded inside the assembly — and that can be switched off with --offline.

Installing and running

Run it without installing anything (.NET 10 and above):

dnx DotnetLog.Viewer -- --app C:\app

Or install it as a global tool and call it by name:

dotnet tool install -g DotnetLog.Viewer
dotnet-log-view --app C:\app --project C:\repos\MyApp

The browser opens by itself; the address is printed in the console as well.

A complete example, start to finish

A real run, copied from a machine. The application was published to C:\app, processed by dotnet-log and started once:

dotnet-log "SampleApp" --dir C:\app
cd C:\app && .\SampleApp.exe

That leaves two files next to the application — dotnet-log.jsonl and dotnet-log.methods.json. Now open them:

dotnet-log-view --app C:\app --project C:\repos\MyApp\samples\SampleApp

Просмотрщик лога открыт здесь: http://127.0.0.1:51234

The page answers right away, and so does everything behind it: 60 steps, 30 calls, the method map found. Step 40 of that run, for example, is a call inside SampleApp.AsyncScenarios, and the viewer opens AsyncScenarios.cs on line 47 with the values that were there at that moment.

More ways to start the same thing:

# the log lies elsewhere or is named differently
dotnet-log-view --log C:\logs\yesterday.jsonl --project C:\repos\MyApp

# a fixed port, no browser — handy over SSH or in a container
dotnet-log-view --app C:\app --port 5099 --no-browser

# closed environment: never go to the network for other people's sources
dotnet-log-view --app C:\app --project C:\repos\MyApp --offline

# no sources at hand: values and the call tree still work, files do not
dotnet-log-view --app C:\app

# the list of options
dotnet-log-view --help

Options

dotnet-log-view [options]

The usual start, when the application was processed by dotnet-log and run in place:

dotnet-log-view --app C:\app --project C:\repos\MyApp

What has to be there for it to work

The map is looked up in this order: the path given by --map, the application folder given by --app, the folder the log lies in, the sources folder — and, if none of them has it, the folders nested next to the log, three levels deep. That last step covers the common case where the log is written to bin while the assemblies and the map live in bin\Debug\net10.0.

The map records the paths as they were on the build machine. The viewer matches them against your folder by the tail of the path, so a repository moved to another disk is not a problem.

A log of any size

The viewer never reads the log into memory. On opening it builds an index — for every line it remembers only where that line starts in the file — and drops it next to the log as a .idx file; the lines themselves are read from disk when they are asked for. A 2 GB log (9.86 million steps) opens in 21 seconds the first time and in one second every time after that, taking 373 MB of memory.

The index is checked against the log before it is used: if the log has been appended to since, the stale index is silently thrown away and built anew.

Other people's code

A method from a NuGet package has no source file on your disk. The viewer still shows it, trying four ways from best to worst:

1. the source embedded into the debug file (.pdb) — nothing to download, the text is real;
2. Source Link — the address of the exact file is recorded in the debug file, and the viewer downloads it;
3. the debug file itself from the package symbol server symbols.nuget.org;
4. the text restored from the assembly (decompiled) — not the text a human wrote, and the viewer says so above the code.

The network is never waited for: the restored text is shown immediately and replaced by the real source when it arrives. What is being downloaded is visible in the status line, with a button to stop it. --offline turns the network off completely.