DEV Community: Stewart Celani

Why I Built Another File Converter (Probably a Stupid Idea)

Stewart Celani — Fri, 27 Feb 2026 23:46:48 +0000

There are a million file converters on the internet. And I built one anyway.

The Backstory

About 10 years ago I was working at a design agency in Adelaide and we used TinyPNG constantly. Drop your PNGs, get them back smaller, done. I loved the simplicity of it and always thought the same approach would work for file conversion - find the format pairing you need, drag your files in, see per-file progress in real time, get a batch ZIP at the end.

A few years back I built a .NET API called ConvertX.to - 90+ converters, mostly a portfolio project. Then I let the domain lapse. Life happened. When I finally went to build the frontend I'd always wanted, the .fast gTLD had just launched. I checked convert.fast. Available. Bought it on the spot, along with about 70 other .fast domains.

What I Actually Built

I spent about two months building and shipping the web UI in December 2025. The architecture behind it is a shared accounts system on accounts.tools.fast - an OpenIddict SSO provider across the whole network. One login, shared credit wallet, unified identity. The idea is I can ship different tools quickly behind the same account, with a unified API that gets more valuable as more tools join the network.

The converter handles images, documents, audio, video, ebooks, fonts, and animations. The UX is deliberately simple: find your format pair, drop your files, watch the per-file progress, download individually or as a batch ZIP. The TinyPNG ethos, applied to everything.

Is This a Stupid Idea?

I ask myself this regularly. CloudConvert, Zamzar, Convertio - well-funded, well-established, years of SEO authority. Competing with them sounds insane. The domain alone is $500 USD/year.

Years ago I built a Chromebook classroom monitoring tool that grew to $10K ARR through word of mouth in a handful of primary schools in Adelaide. Then I got distracted by other things and shut it down. That decision haunts me. I had something real and I took it for granted - didn't put in the work to grow it when the opportunity was there. My son just turned one. I turn 37 this year. I've told myself I have until I'm 40 to give this everything I've got - three years of genuine effort - and if it's still not working, I can walk away knowing I actually tried this time.

The bet I'm making is a long one - three to five years minimum. The .fast network approach (one login, shared credits, a unified API across conversion, compression, and eventually more tools) creates something more valuable than any single converter site, but only if people actually find it. And that's the hard part. SEO is a slow grind when you're competing against domains with a decade of authority, and it's getting harder - half of Google's first page is sponsored results now, AI overviews are eating clicks, and the rules change every few months. Word of mouth takes even longer. There's a free tier with 500 credits and no credit card required. The pricing page has the full breakdown.

I might be wrong. This might never get enough traffic to justify the domain costs, let alone the engineering time. But I've always wanted to build this, and so far I'm enjoying the process. Here's the engineering behind it.

The Frontend: Vue Islands on Razor Pages

I usually write React - I'd just finished building BeamIt.to on TanStack Start. But for this project I wanted a single language across the full stack. Razor Pages (ASP.NET's server-rendered templating) turned out to work really well - real HTML that Google can crawl, fast first paint, no JavaScript required for the initial page load.

That worked great until I needed interactivity. The drag-and-drop uploader, real-time progress bars, batch queue management - managing that much UI state without a framework was going to be a maintenance nightmare.

So I came up with a Vue island system (demonstration of the technique on GitHub). Each converter page is a Razor Page that server-renders the exact HTML markup that the converter UI will display. Then a tiny Vue 3 app hydrates against that specific <div> - and because the server-rendered HTML matches what Vue would render, it's essentially a no-op on the DOM. Vue mounts without the user noticing anything. No flash of content, no layout shift. Every tool page is its own little Vue app, with shared core chunks split out by Vite for download optimization.

This approach would work equally well with PHP + Vue, or Django + Vue, or any server-rendered framework. The key insight is: let the server own the SEO-critical markup, let Vue own the interactivity, and make sure they agree on what the HTML looks like.

The core of the system is a single FileConverter.vue component - about 3,700 lines of Vue 3 Composition API. It's the engine behind all 165+ converters. Every converter wraps it with a thin config layer.

Real-Time Per-File Progress via SSE

When you upload files, the frontend opens a Server-Sent Events connection to the batch endpoint. Every file in the queue gets its own live progress bar, updated independently in real time.

For converters where we control the processing pipeline - which is most of them - we report genuinely granular progress. Our image library bridges report per-frame progress for animated formats (GIF-to-WebP shows "Converting frame 42/110..."). Document converters report per-page progress (PDF-to-JPG shows "Converting page 550 of 606..."). Audio converters report per-second progress based on transcription speed.

For a 200-file batch, you see 200 individual progress bars all ticking independently - uploading, queued, processing, and completed files organized into collapsible sections.

The Honest Tradeoff: Asymptotic Progress

Not everything has progress hooks though. OCR engines, external APIs like Whisper for transcription, CLI tools like Pandoc - they're black boxes. You hand them a file and wait. Without intervention, the progress bar sits at 35% for 30 seconds and users think it's broken.

I didn't have this at launch. I shipped without it, and then watched Microsoft Clarity session recordings of real users looking visibly confused when their conversion hit 50% and just... sat there. You could see them hovering over the progress bar, scrolling up and down, some refreshing the page entirely. That was enough motivation.

So I built an asymptotic progress system. The server calculates an ETA based on input characteristics (page count, audio duration, file size) and tells the frontend via SSE: "Interpolate smoothly from 20% toward 75% over approximately 30 seconds." The frontend uses an exponential decay curve - progress = from + (ceiling - from) * (1 - e^(-elapsed/tau)) - that accelerates quickly then decelerates as it approaches the target. Crucially, it never reaches the target until the server confirms completion.

It's honestly a beautiful lie. We're faking smooth progress over operations where we genuinely have no idea how far along they are. We just know roughly how long they should take. But users don't need accurate progress - they need reassurance. A bar that smoothly approaches 89% and then snaps to complete is far better UX than one that sits frozen at 35% for half a minute.

The API

Not a "here's a POST endpoint, good luck" kind of API. I wanted extensive documentation, self-describing discovery, and copy-to-clipboard on everything so integration is as low-friction as possible.

Three Requests

At minimum it's submit, check status, download:

API_KEY="fast_prod_your_key_here"

curl -sS -X POST "https://api.tools.fast/convert" \
  -H "X-Fast-Api-Key: $API_KEY" \
  -F "file=@photo.heic" \
  -F "targetFormat=jpg"

{
  "id": "019c56454f8b755996c45a4874a1f3f6",
  "status": "Queued",
  "creditCost": 1
}

Poll for completion at GET /convert/job/{id}, then download at GET /convert/job/{id}/download. That's it - three requests. If you don't want to poll, there are webhooks with Stripe-style HMAC-SHA256 signatures.

Discovery-First Design

I always found it annoying when I had to dig through docs to figure out if an API supports a specific format pair. So the API is self-describing:

# What can I convert HEIC to?
curl -sS "https://api.tools.fast/convert/conversions/heic" \
  -H "X-Fast-Api-Key: $API_KEY"

# All image conversions
curl -sS "https://api.tools.fast/convert/conversions/images" \
  -H "X-Fast-Api-Key: $API_KEY"

# What converts TO PDF?
curl -sS "https://api.tools.fast/convert/conversions/to/pdf" \
  -H "X-Fast-Api-Key: $API_KEY"

The response includes everything: supported formats, max file sizes, credit costs, costing strategy, and concurrency limits. No guessing.

Every converter also publishes its options as a JSON Schema, queryable at /convert/schema/{from}/{to}. Things like resize presets, compression modes, OCR, metadata stripping - it's all machine-readable, so you can build dynamic UIs or validate options before submitting.

There are currently 165 unique conversion pairings, and we keep adding more. And because each converter has its own page, they naturally become discoverable - every converter is a landing page.

Built for AI Agents

This is the part I'm probably most excited about. The entire API documentation is Markdown-based and published as downloadable files - designed from the ground up to be fed into an AI agent's context window.

There's a For AI Agents page with a copy-paste prompt you can give to Claude Code, Codex, OpenCode, or any AI coding assistant:

Download the Convert.FAST skill and reference docs, then use them to complete my task:

curl -fsSL https://convert.fast/SKILL.md -o SKILL.md
mkdir -p reference && curl -fsSL https://convert.fast/api/docs.md -o reference/docs.md
curl -fsSL https://convert.fast/convert.fast.sh -o convert.fast.sh && chmod +x convert.fast.sh

Read SKILL.md to understand how to use the Convert.FAST API.

The agent downloads a skill file (~2k tokens), the core API reference (~18k tokens), and a CLI wrapper script. That's everything it needs to convert files on your behalf. The CLI wrapper handles the submit-poll-download loop in a single command:

./convert.fast.sh photo.heic jpg
./convert.fast.sh document.pdf docx
./convert.fast.sh scan.pdf docx output.docx '{"ocr":{"enabled":true}}'

I built the docs this way because I use AI coding agents every day and the integration experience with most APIs is terrible - the agent has to scrape docs pages, guess at endpoints, and hallucinate request formats. I wanted mine to be different: download three files, read the skill, you're done. I tested this by onboarding a Claude Code agent with the prompt above - it converted files autonomously with no hand-holding.

What's Next

The next site in the network is pdf.fast - my take on iLovePDF. A visual PDF toolkit: merge, split, compress, OCR, watermark. I'm also working on a free offline desktop compression app - right-click images, documents, and PDFs and they get optimized. Think the old Windows Image Resizer before PowerToys absorbed it.

Every format I support on the web is available through the API - same processing pipeline, same quality defaults. It's well-tested, but there are definitely edge cases I haven't hit yet, and I'm sure someone will find a format combination that breaks in a way I didn't anticipate.

If you try it out, I'd love to hear what breaks - or tell me the format pair you need that I don't have yet. Drop a comment.

Links:

API docs
Sign up (500 free credits, no credit card)
The web tool
pdf.fast (coming soon)
ConvertX.to (the original .NET portfolio project)

How a Bottleneck, YouTube Video and C# Channels Led to a 3x Faster .NET Backup Tool

Stewart Celani — Fri, 29 Aug 2025 03:27:36 +0000

When I first released my Autodesk Construction Cloud Backup tool back in 2022, I was pretty happy with it. It was reliably backing up about 150 GB of data in around 6 hours, which was a huge improvement over the commercial alternatives at the time.

Fast forward three years to 2025. The data had grown to about 225 GB, but the nightly backup was now taking a whopping 12 hours.

The data hadn't even doubled, but the backup time had. Something felt really off with how it was scaling, and I wasn't happy with it.

The Lightbulb Moment

I was already in the middle of updating the project to .NET 9 and taking the opportunity to swap out NLog for Serilog (it's just a personal preference, I love Serilog's structured logging). While taking a break, I stumbled upon a Nick Chapsas video about C# Channels.

Not affliated, but I do highly recommend Nick's Dometrain courses if you are serious about learning C#

I honestly didn't know C# had powerful, built-in "queues" like this designed for exactly this kind of work. Suddenly, the solution to my scaling problem became crystal clear. The entire bottleneck was the tool's dumb, sequential approach:

Project 1: Enumerate (30s) -> Download (5m) -> Done
Project 2: Enumerate (45s) -> Download (3m) -> Done  
Project 3: Enumerate (15s) -> Download (8m) -> Done

During each enumeration phase, the downloader sits completely idle. During each download phase, the enumerator sits completely idle. It's like having a single-lane bridge where cars can only go one direction at a time!

I had my lightbulb moment. What if I could have workers that only enumerate projects, and while they're doing that, another worker is already downloading a project the first one prepared? The downloader could be running the whole time, constantly being fed new work.

How It Works

The core concept is a "conveyor belt" (the Channel) that holds projects ready for download. I chose an unbounded channel because project enumeration times can vary wildly—some projects take seconds while others can take 30+ minutes. A bounded channel could block fast enumerations waiting for slow downloads.

// Create an unbounded channel to queue enumerated projects
var enumerationChannel = Channel.CreateUnbounded<ProjectBackup>(new UnboundedChannelOptions
{
    SingleWriter = false, // Multiple enumeration tasks will write
    SingleReader = true   // Single download task will read
});

The Producer task controls how many projects get enumerated simultaneously. I use a SemaphoreSlim rather than Parallel.ForEachAsync because I want fine-grained control over concurrency and better error handling per project.

// Producer task: Enumerate projects with controlled concurrency
var enumerationTask = Task.Run(async () =>
{
    var semaphore = new SemaphoreSlim(4, 4); // Allow up to 4 concurrent enumerations
    var enumerationTasks = new List<Task>();

    foreach (var project in _projects)
    {
        var projectTask = Task.Run(async () =>
        {
            await semaphore.WaitAsync();
            try
            {
                Logger.Info($"=> Enumerating project {project.Name} ({project.ProjectId})");
                Logger.Info("Querying for list of folders and files, this may take a while depending on project size.");
                project.BackupStartedAt = DateTime.Now;
                await project.GetContentsRecursively();
                Logger.Info($"=> Enumeration complete for {project.Name}, queuing for download");
                await enumerationChannel.Writer.WriteAsync(project);
            }
            catch (Exception ex)
            {
                Logger.Error(ex, $"Failed to enumerate project {project.Name} ({project.ProjectId})");
                // Still queue the project so it appears in the summary as failed
                if (project.BackupStartedAt == null)
                    project.BackupStartedAt = DateTime.Now;
                project.BackupFinishedAt = DateTime.Now;
                await enumerationChannel.Writer.WriteAsync(project);
            }
            finally
            {
                semaphore.Release();
            }
        });
        enumerationTasks.Add(projectTask);
    }

    await Task.WhenAll(enumerationTasks);
    enumerationChannel.Writer.Complete(); // Signal no more projects coming
});

The Consumer task runs continuously, processing projects as they become available. But here's the cool part—it also tracks performance metrics to measure pipeline efficiency.

// Consumer task: Download projects sequentially with wait time tracking
var downloadTask = Task.Run(async () =>
{
    DateTime? lastDownloadEndTime = null;
    var isFirstProject = true;

    await foreach (var project in enumerationChannel.Reader.ReadAllAsync())
    {
        // Track wait time (time between downloads)
        var projectReceivedTime = DateTime.Now;
        if (lastDownloadEndTime.HasValue)
        {
            var waitTime = projectReceivedTime - lastDownloadEndTime.Value;
            _totalWaitTime = _totalWaitTime.Add(waitTime);
            Logger.Debug($"Waited {waitTime.TotalSeconds:F1}s for next project to be enumerated");
        }
        else if (!isFirstProject)
        {
            // For the first project after initialization
            var waitTime = projectReceivedTime - _backupStartTime!.Value;
            _totalWaitTime = _totalWaitTime.Add(waitTime);
        }
        isFirstProject = false;

        // Download the project and track active download time
        var downloadStartTime = DateTime.Now;
        Logger.Info($"=> Downloading project {project.Name} ({project.ProjectId})");
        Logger.Info("Backup beginning.");

        // Use sanitized project name for directory creation
        var sanitizedProjectName = SanitizeProjectName(project.Name);
        await project.DownloadContentsRecursively(Path.Combine(Config.BackupDirectory, sanitizedProjectName));

        var downloadEndTime = DateTime.Now;
        var downloadTime = downloadEndTime - downloadStartTime;
        _totalDownloadTime = _totalDownloadTime.Add(downloadTime);
        lastDownloadEndTime = downloadEndTime;
        _projectsProcessed++;

        project.BackupFinishedAt = downloadEndTime;
        Logger.Info($"=> Finished downloading project {project.Name} ({project.ProjectId})");
        LogBackupSummaryLine(project);
    }
});

// Wait for both tasks to complete
await Task.WhenAll(enumerationTask, downloadTask);

What makes this implementation special is the performance tracking. I measure the wait time (when the downloader is idle waiting for projects) vs the download time (actively downloading). This tells me exactly how efficiently the pipeline is running. If wait time is high, I know enumeration is the bottleneck and I should increase concurrent enumerations. If it's low, downloads are keeping up perfectly with enumerations.

Notice that projects are processed sequentially by the consumer—this is intentional! The Autodesk API has rate limits, so downloading multiple projects simultaneously would just trigger throttling. But within each project, files download in parallel via Parallel.ForEachAsync.

Two-Level Parallelization Strategy

Here's where it gets really interesting. The Channels handle project-level parallelization, but within each project, I also use Parallel.ForEachAsync for downloading individual files (which I previously blogged about here). This creates a two-tier performance boost:

public async Task<List<FileInfo>> DownloadFiles(
    IEnumerable<File> fileList, string rootDirectory, CancellationToken ct = default)
{
    List<FileInfo> fileInfoList = new();

    var parallelOptions = new ParallelOptions
    {
        CancellationToken = ct,
        MaxDegreeOfParallelism = Config.MaxDegreeOfParallelism // Default: 8
    };

    await Parallel.ForEachAsync(fileList, parallelOptions, async (file, ctx) =>
    {
        var fileInfo = await DownloadFile(file, rootDirectory, ctx);
        fileInfoList.Add(fileInfo);
    });

    return fileInfoList;
}

So the complete picture is:

Level 1: Up to 4 projects being enumerated concurrently via Channels
Level 2: Within each downloading project, up to 8 files downloading in parallel via Parallel.ForEachAsync
Pipeline: While one project downloads its files, 3 others can be querying the API for their folder structures

The key insight is that enumeration (API calls to get folder/file lists) and downloading (HTTP file transfers) have completely different bottlenecks. Enumeration is limited by API rate limits, while downloading is limited by bandwidth. By separating them with Channels, each can run at its optimal speed.

The Results

The performance improvement was dramatic. That 12-hour backup of 225GB across ~170 projects now finishes in just 4 hours—a 3x improvement! But the real magic is in the efficiency reporting the tool now generates.

Here's what a typical backup now logs:

=================================================================================
=> Pipeline Efficiency Statistics:
    Total pipeline time: 03:45:23
    Active download time: 03:32:18 (94.2%)
    Wait time (idle): 00:13:05 (5.8%)
    Projects processed: 168
    Average wait between projects: 00:00:05
=================================================================================

This tells an amazing story. The pipeline is now 94.2% efficient—meaning the downloader is actively working 94% of the time instead of sitting idle waiting for the next project to be enumerated. The old sequential approach was probably around 50% efficient at best.

The tool also tracks incremental backup statistics (v1.1.0 added smart copying from previous backups):

=================================================================================
=> Incremental Backup Statistics:
    Files copied from previous backup: 38,542 (198.7 GB)
    Files downloaded from Autodesk: 1,688 (6.3 GB)
    Total files processed: 40,230
    Estimated time saved: 11h 2m
    Bandwidth saved: 198.7 GB
    Incremental efficiency: 96.93% data reused from previous backup
=================================================================================

When you combine the producer-consumer pipeline with incremental backups, you get compounding performance benefits. The pipeline keeps the tool busy, while incremental sync avoids re-downloading unchanged files.

The Key Insight

The breakthrough wasn't just using Channels—it was recognizing that enumeration and downloading are fundamentally different operations with different bottlenecks:

Enumeration: I/O bound, limited by API rate limits (~4 projects at once is optimal)
Downloading: Bandwidth bound, benefits from high parallelism (8 files at once)
Sequential coupling: The old approach made downloading wait for enumeration to finish

By decoupling them with Channels, each operation can run at its natural speed. The enumeration never blocks downloads, and downloads never wait for enumeration.

Overall, I'm incredibly happy with how this turned out. It was a great reminder that sometimes the most elegant solution to a nagging problem is just one YouTube video away. C# Channels turned what could have been a complex threading nightmare into clean, readable code that just works.

Benchmark: How to use C# Parallel.ForEachAsync for 3x faster bulk file downloading time

Stewart Celani — Sat, 16 Aug 2025 12:39:20 +0000

Recently I was working on a project to backup files via the Autodesk BIM360/Construction Cloud API.

My initial prototype took 12 hours to backup roughly 100 GB (40,230 files in 11,737 folders) which wasn't good. Due to the fast pace data is being added to the account, within 1–2 years the backup would be taking over 24 hours.

After a program re-write which included moving the file downloading logic from a synchronous foreach loop to a Parallel.ForEachAsync loop I was able to get the nightly backup time down to 3 hours.
I wanted to quantify how much of the 4x performance improvement was down to the re-write vs the Parallel.ForEachAsync loop so ran two benchmarks in the awesome Benchmark.NET.

The first was on a small project containing 300 MB (136 files in 30 folders):

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1645 (21H2)
Intel Core i7-5820K CPU 3.30GHz (Broadwell), 1 CPU, 12 logical and 6 physical cores
.NET SDK=6.0.202
[Host]     : .NET 6.0.4 (6.0.422.16404), X64 RyuJIT
Job-KSORIT : .NET 6.0.4 (6.0.422.16404), X64 RyuJIT

IterationCount=3 LaunchCount=1 WarmupCount=1

|          Method |    Mean |   Error | StdDev |
|---------------- |--------:|--------:|-------:|
|    ParallelLoop | 123.2 s | 61.06 s | 3.35 s |
| SynchronousLoop | 299.8 s | 74.74 s | 4.10 s |

The second was on a large project containing 26 GB (10,653 files in 973 folders):

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1706 (21H2)
Intel Core i7-5820K CPU 3.30GHz (Broadwell), 1 CPU, 12 logical and 6 physical cores
.NET SDK=6.0.202
[Host]     : .NET 6.0.4 (6.0.422.16404), X64 RyuJIT
Job-QIVIZX : .NET 6.0.4 (6.0.422.16404), X64 RyuJIT

IterationCount=3  LaunchCount=1  RunStrategy=Monitoring  
WarmupCount=0

|          Method |     Mean |    Error |   StdDev |
|---------------- |---------:|---------:|---------:|
|    ParallelLoop |  98.83 m |  12.97 m |  0.711 m |
| SynchronousLoop | 300.62 m | 368.38 m | 20.192 m |

So the improvement from Parallel.ForEachAsync is roughly 3x.
I would have loved to run more iterations of benchmark 2 to get the error and stddev down but it took a day to run as is and the results match with both the benchmark 1 and the nightly real-world performance of the 100 GB backup.

Note the 100~ minutes for 26 GB backup in the benchmark above is using my home internet which is much slower than where the backup is running from each night.

The actual benchmark runner:

using ACC.ApiClient;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Engines;
using Library.Logger;
using Library.SecretsManager;

[SimpleJob(RunStrategy.Monitoring, launchCount: 1, warmupCount: 0, targetCount: 3)]
public class DownloadSynchronousVsParallel
{
    private readonly ApiClient _apiClient;

    private readonly string _projectId =
        SecretsManager.GetEnvironmentVariable("acc:benchmarks:DownloadSynchronousVsParallel:projectId");

    private readonly string _rootDirectory = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());

    public DownloadSynchronousVsParallel()
    {
        string clientId = SecretsManager.GetEnvironmentVariable("acc:clientid");
        string clientSecret = SecretsManager.GetEnvironmentVariable("acc:clientsecret");
        string accountId = SecretsManager.GetEnvironmentVariable("acc:accountid");

        _apiClient = TwoLeggedApiClient
            .Configure()
            .WithClientId(clientId)
            .AndClientSecret(clientSecret)
            .ForAccount(accountId)
            .WithOptions(options =>
            {
                options.Logger = new NLogLogger(new NLogLoggerConfiguration
                {
                    LogLevel = LogLevel.Debug,
                    LogToConsole = true
                });
            })
            .Create();
    }

    [Benchmark]
    public async Task ParallelLoop()
    {
        var project = await _apiClient.GetProject(_projectId);
        await project.GetContentsRecursively();
        await project.DownloadContentsRecursively(_rootDirectory);
        Directory.Delete(_rootDirectory, true);
    }

    [Benchmark]
    public async Task SynchronousLoop()
    {
        var project = await _apiClient.GetProject(_projectId);
        await project.GetContentsRecursively();
        foreach (var file in project.FilesRecursive) 
            await _apiClient.DownloadFile(file, _rootDirectory);
        Directory.Delete(_rootDirectory, true);
    }
}

The SynchronousLoop task on line 49 does what you expect, a foreach loop iterates over an IEnumerable of files and passes each down to a DownloadFile method:

public async Task<FileInfo> DownloadFile(
        File file, string rootDirectory, CancellationToken ct = default)
    {
        CreateDirectory(file.ParentFolder, rootDirectory);
        string downloadPath = Path.Combine(rootDirectory, file.GetPath()[1..]);

        if (Config.DryRun)
        {
            await System.IO.File.WriteAllBytesAsync(downloadPath, Array.Empty<byte>(), ct);
            file.FileInfo = new FileInfo(downloadPath);
            file.FileSizeOnDisk = file.FileInfo.Length;
            Config.Logger?.Info($"{file.FileInfo.FullName} ({file.FileSizeOnDiskInMb} MB)");
            return file.FileInfo;
        }

        return await Config.RetryPolicy.ExecuteAsync(async () =>
        {
            await EnsureAccessToken();
            file.DownloadAttempts++;
            await using Stream stream = await Config.HttpClient.GetStreamAsync(file.DownloadUrl, ct);
            await using FileStream fileStream = new(downloadPath, FileMode.Create);
            await stream.CopyToAsync(fileStream, ct);
            file.FileSizeOnDisk = fileStream.Length;
            file.FileInfo = new FileInfo(downloadPath);
            if (file.FileSizeOnDisk == file.StorageSize)
                Config.Logger?.Debug($"{file.FileInfo.FullName} ({file.FileSizeOnDiskInMb} MB)");
            else
                Config.Logger?.Warn(
                    @$"{file.FileInfo.FullName} ({file.FileSizeOnDiskInMb}/{file.ApiReportedStorageSizeInMb} bytes) (Mismatch between size reported by API and size downloaded to disk)");
            return file.FileInfo;
        });
    }

The file downloading logic is wrapped in a Polly AsyncRetryPolicy and is essentially 3 lines (20–22).

Both the SynchronousLoop and the ParallelLoop use the above method to download files.

The ParallelLoop’s ‘DownloadContentsRecursively’ call on line 44 of the benchmark uses the below method incorporating Parallel.ForEachAsync:

 public async Task<List<FileInfo>> DownloadFiles(
        IEnumerable<File> fileList, string rootDirectory, CancellationToken ct = default)
    {
        List<FileInfo> fileInfoList = new();

        var parallelOptions = new ParallelOptions
        {
            CancellationToken = ct,
            MaxDegreeOfParallelism = Config.MaxDegreeOfParallelism
        };

        await Parallel.ForEachAsync(fileList, parallelOptions, async (file, ctx) =>
        {
            FileInfo fileInfo = await DownloadFile(file, rootDirectory, ctx);
            fileInfoList.Add(fileInfo);
        });

        return fileInfoList;
    }

As you can see on line 14 the same DownloadFile method is being called as with the synchronous loop.

The C# dev team have really made it incredibly simple to incorporate parallelism into our applications when the situation calls for it.

Combine Blazor WebAssembly Client and Server Logs: Two-way log streaming with NLog and SignalR

Stewart Celani — Wed, 06 Aug 2025 03:15:23 +0000

Last time, in Streaming Blazor (ASP.Net Core) Logs to the Browser with a custom NLog Target and SignalR, we set up a fresh Blazor WebAssembly project to stream server logs to the browser:

At the end of that post I concluded "this is much more useful for Blazor Server projects as everything is happening on the server already". Over the next couple days it continued to bug me as I pondered how nice it would be to have combined Client and Server logs in Blazor WASM like in Blazor Server.

The exact setup I'm going for is as a development environment tool:

Server project streams logs to Browser JavaScript console
Client project streams logs to the Server project console

On the server this will give the same experience as a Blazor Server project, with frontend and backend logs being combined, while also adding the ability to access those same logs from the browsers JavaScript console.

Repository with commits at each step can be found here: GitHub - stewartcelani/WasmTwoWayLogging

Feel free to skip to the end of the article to see a GIF of this working in action.

Step 7: Fixing the Server project to access the LoggingHub directly instead of via Microsoft.AspNetCore.SignalR.Client

It felt a bit clunky using SignalR via Server\Logging\LoggingHubConnection.cs to send SignalR messages from the server to itself so luckily there is a way to send messages from outside the hub via the SignalR HubContext. All is not wasted though, we will need to use the LoggingHubConnection.cs later from the Client project to get client logs to the server.

Not including the deletion of Server\Logging\LoggingHubConnection.cs we have 4 changed files.

Server\Services\DebugService.cs is where we will send log messages to the browser directly via the LoggingHub context made available via ASP.NET Core dependency injection in the constructor.

We need a way to get a reference to the DebugService into the Server\Logging\LoggingHubTarget.cs. To do this, in Server\Program.cs, we can get a reference to a service as at app start up and then pass this reference into Server\Logging\Logger.cs::Configure.

Server\Logging\Logger.cs passes the reference through to the LoggingHubTarget.

A very slimmed down Server\Logging\LoggingHubTarget.cs simply renders the logEvent to a string and passes it to DebugService::LogToBrowser.

// Server\Services\DebugService.cs
using Microsoft.AspNetCore.SignalR;
using WasmTwoWayLogging.Server.Hubs;

namespace WasmTwoWayLogging.Server.Services
{
    public class DebugService
    {
        private readonly IHubContext<LoggingHub> _hubContext;
        public DebugService(IHubContext<LoggingHub> hubContext)
        {
            _hubContext = hubContext;
        }
        public async Task LogToBrowser(string logMessage)
        {
            await _hubContext.Clients.All.SendAsync("Log", logMessage);
        }
    }
}

// Server\Logging\Logger.cs
using NLog;
using NLog.Config;
using NLog.Targets;
using WasmTwoWayLogging.Server.Services;

namespace WasmTwoWayLogging.Server.Logging
{
    public static class Logger
    {
        public static NLog.Logger Log = LogManager.GetCurrentClassLogger();

        public static void Configure(DebugService debugService)
        {
            LoggingConfiguration config = new LoggingConfiguration();
            string layout = "${longdate}|Server|${level}|${callsite}|Line:${callsite-linenumber}|${message}             ${all-event-properties} ${exception:format=tostring}";

            // Log to console
            ColoredConsoleTarget consoleTarget = new ColoredConsoleTarget()
            {
                UseDefaultRowHighlightingRules = true,
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: consoleTarget);

            // Log to file (minLevel: Info)
            FileTarget infoFileTarget = new FileTarget("info")
            {
                FileName = "${basedir}\\Logging\\${date:format=yyyy-MM-dd}.log",
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Info, maxLevel: NLog.LogLevel.Fatal, target: infoFileTarget);

            // Log to file (minLevel: Trace)
            FileTarget traceFileTarget = new FileTarget("trace")
            {
                FileName = "${basedir}\\Logging\\${date:format=yyyy-MM-dd}.trace.log",
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: traceFileTarget);

            // Log to SignalR LoggingHub
            var loggingHubTarget = new LoggingHubTarget(debugService)
            {
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: loggingHubTarget);

            LogManager.Configuration = config;
            Log = LogManager.GetCurrentClassLogger();
        }
    }
}

// Server\Logging\LoggingHubTarget.cs
using NLog;
using NLog.Targets;
using WasmTwoWayLogging.Server.Services;

namespace WasmTwoWayLogging.Server.Logging
{
    public class LoggingHubTarget : AsyncTaskTarget
    {
        private readonly DebugService _debugService;
        public LoggingHubTarget(DebugService debugService)
        {
            _debugService = debugService;
            OptimizeBufferReuse = true;
        }
        protected override async Task WriteAsyncTask(LogEventInfo logEvent, CancellationToken token)
        {
            string logMessage = this.Layout.Render(logEvent);
            await _debugService.LogToBrowser(logMessage);
        }
    }
}

// Server\Program.cs
using Microsoft.AspNetCore.ResponseCompression;
using WasmTwoWayLogging.Server.Hubs;
using WasmTwoWayLogging.Server.Logging;
using WasmTwoWayLogging.Server.Services;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddSignalR();
builder.Services.AddControllersWithViews();
builder.Services.AddRazorPages();
builder.Services.AddResponseCompression(opts =>
{
    opts.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(
        new[] { "application/octet-stream" });
});
builder.Services.AddSingleton<DebugService>();

var app = builder.Build();

// Need to get reference to Server\Services\DebugService.cs to inject into Logging\Logger.cs::Configure
using (var serviceScope = app.Services.CreateScope())
{
    var services = serviceScope.ServiceProvider;

    DebugService debugService = services.GetRequiredService<DebugService>();
    Logger.Configure(debugService);
    Logger.Log.Info("App starting");
    // Lets log something every second to simulate legitimate log output
    System.Timers.Timer timer = new System.Timers.Timer(1000);
    timer.Elapsed += (source, e) =>
    {
        Logger.Log.Trace("tick");
    };
    timer.Enabled = true;
    timer.Start();
}

app.UseResponseCompression();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseWebAssemblyDebugging();
}
else
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseBlazorFrameworkFiles();
app.UseStaticFiles();

app.UseRouting();

app.MapRazorPages();
app.MapControllers();
app.MapHub<LoggingHub>("/hubs/logging");
app.MapFallbackToFile("index.html");

app.Run();

Step 8: Set up NLog in the Client project

Time add the NLog to our client project.

cd .\Client
dotnet add package NLog

Now lets quickly get NLog up and running and logging to the console.

@* Client\Pages\Counter.razor *@
@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        Logger.Log.Debug($"BEFORE: currentCount: {currentCount}");
        currentCount++;
        Logger.Log.Debug($"AFTER: currentCount: {currentCount}");
    }
}

// Client\Logging\Logger.cs
using NLog;
using NLog.Config;
using NLog.Targets;

namespace WasmTwoWayLogging.Client.Logging
{
    public class Logger
    {
        public static NLog.Logger Log = LogManager.GetCurrentClassLogger();

        public static void Configure()
        {
            LoggingConfiguration config = new LoggingConfiguration();
            string layout = "${longdate}|Client|${level}|${callsite}|Line:${callsite-linenumber}|${message} ${all-event-properties} ${exception:format=tostring}";

            ConsoleTarget consoleTarget = new ConsoleTarget()
            {
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: consoleTarget);

            LogManager.Configuration = config;
            Log = LogManager.GetCurrentClassLogger();
        }
    }
}

// Client\Program.cs
global using WasmTwoWayLogging.Client.Logging;
using Microsoft.AspNetCore.Components.Web;
using Microsoft.AspNetCore.Components.WebAssembly.Hosting;
using WasmTwoWayLogging.Client;
using WasmTwoWayLogging.Client.Library;
using WasmTwoWayLogging.Client.Services;

Logger.Configure();
Logger.Log.Info("App starting.");

var builder = WebAssemblyHostBuilder.CreateDefault(args);
builder.RootComponents.Add<App>("#app");
builder.RootComponents.Add<HeadOutlet>("head::after");

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
builder.Services.AddScoped<DebugService>();
builder.Services.AddScoped<JsConsole>();

await builder.Build().RunAsync();

Now we have combined Server/Client logging via the JavaScript console:

Step 9: Clean up Client code

First lets refactor Client\Services\DebugService.cs to only log server output to the console.

// Client\Services\DebugService.cs
using WasmTwoWayLogging.Client.Library;

namespace WasmTwoWayLogging.Client.Services
{
    public class DebugService
    {
        private readonly JsConsole _console;
        public DebugService(JsConsole console)
        {
            Logger.Log.Trace("Ctor");
            _console = console;
        }

        public async Task HandleLogFromServer(string logMessage)
        {
            await _console.LogAsync(logMessage);
        }
    }
}

Update MainLayout.razor to only mount the ServerConsole.razor component if our environment is 'Development'.

@* Client\Shared\MainLayout.razor *@
@inherits LayoutComponentBase
@inject DebugService DebugService
@using Microsoft.AspNetCore.Components.WebAssembly.Hosting
@inject IWebAssemblyHostEnvironment HostEnvironment

<div class="page">
    <div class="sidebar">
        <NavMenu />
    </div>

    <main>
        <div class="top-row px-4">
            <a href="https://docs.microsoft.com/aspnet/" target="_blank">About</a>
        </div>

        <article class="content px-4">
            @Body
        </article>
        @if (HostEnvironment.Environment == "Development")
        {
            <ServerConsole />
        }
    </main>
</div>

And finally lets tell our SignalR connection to always retry if it drops out. We will do this by implementing IRetryPolicy. By default WithAutomaticReconnect will stop trying after four failed attempts. The default behaviour and how to implement custom retry policies can be read here.

// Client\Library\InfiniteRetryPolicy.cs
using Microsoft.AspNetCore.SignalR.Client;

namespace WasmTwoWayLogging.Client.Library
{
    public class InfiniteRetryPolicy : IRetryPolicy
    {
        public TimeSpan? NextRetryDelay(RetryContext retryContext)
        {
            // For the first 5 minutes try to reconnect every 15 seconds and after that try every 60
            if (retryContext.ElapsedTime < TimeSpan.FromSeconds(300))
            {
                return TimeSpan.FromSeconds(15);
            }
            else
            {
                return TimeSpan.FromSeconds(60);
            }
        }
    }
}

@* Client\Shared\ServerConsole.razor *@
@using Microsoft.AspNetCore.SignalR.Client
@using WasmTwoWayLogging.Client.Library
@inject DebugService DebugService
@inject NavigationManager NavigationManager
@implements IDisposable

<div class="server-console">Server Console: @_hubConnection?.State</div>

@code {
    private HubConnection? _hubConnection;

    private async Task OnReceiveLogEvent(string logMessage)
    {
        await DebugService.HandleLogFromServer(logMessage);
    }

    protected override async void OnInitialized()
    {
        _hubConnection = new HubConnectionBuilder()
            .WithUrl($"{NavigationManager.BaseUri}hubs/logging")
            .WithAutomaticReconnect(new InfiniteRetryPolicy())
            .Build();

        _hubConnection.On<string>("Log", OnReceiveLogEvent);
        await _hubConnection.StartAsync();
    }

    public void Dispose()
    {
        if (_hubConnection != null)
        {
            try
            {
                _hubConnection.StopAsync();
                _hubConnection.DisposeAsync();
                _hubConnection = null;
            }
            catch (Exception ex)
            {
                Logger.Log.Error(ex);
            }
            finally
            {
                _hubConnection = null;
            }
        }
    }
}

Step 10/10: Connect client to server with custom NLog Target and finishing up

Here we will reimplement essentially the same LoggingHubTarget and LoggingHubConnection used in the last post, except this time in the Client project.

I wont cover every change in an embed as there are too many but you can browse the changes directly here.

Summary of changes:

Moved Client\Library\InfiniteRetryPolicy.cs to Shared\InfiniteRetryPolicy.cs as we will use on both Client and Server
Configure logs to stream to server via Client\Logging\Logger.cs, Client\Logging\LoggingHubConnection.cs and Client\Logging\LoggingHubTarget.cs
We needed some way to wire up Server\Services\DebugService.cs to listen for the "LogToServer" LoggingHub event and print them to console. Unfortunately this isn't possible directly from the HubContext so I used Microsoft.AspNetCore.SignalR.Client to set up a HubConnection within the DebugService. In summary: DebugService broadcasts logs from the server to the client with its HubContext and listens to broadcasts from the client with HubConnection.On.

And the end result can be seen below:

Overall I'm happy with how easy it is to get this kind of logging functionality up and running in Blazor. I can see myself using it in my future projects.

Streaming Blazor (ASP.Net Core) Logs to the Browser with a custom NLog Target and SignalR

Stewart Celani — Mon, 04 Aug 2025 03:44:39 +0000

This article was originally written and published on Medium on April 10, 2022. I'm migrating some of my favorite posts to dev.to to begin posting new content again.

While developing in PHP and Node/React in the past I often dreamily wished I was able to see the servers log output in the browser or JavaScript console.

As a newcomer to C#, Blazor and ASP.NET Core I have set myself the goal of familiarising myself with the stack by building a small prototype/feature each week and formalising that knowledge by doing a quick write up in a blog.

Yesterday I was hooking up NLog in Blazor and wondering what I should build for my first post and the idea to see if I could make good on my dream of getting server log output into the browser came back to me.
As the wise philosopher Mr. LaBeouf once said…

“JUST DO IT”

We will walk through one approach on how to achieve this. It is a Blazor WebAssembly & Blazor Server compatible approach using a custom NLog target and SignalR hub.

We will cover a v1 prototype version which streams log output from the moment a client connects with no guarantee of delivery. If the browser connection drops and reconnects minutes later, all the log output that occurred on the server during that time will not be sent to the browser.

Adding a method to guarantee delivery and have the client & server resync data since the connection was lost would be something to add to a v2. I'll likely cover this problem in a future post on building a SignalR chat app.
There is also an easier way to do this which is a Blazor Server only approach and utilises the existing SignalR connection established and managed by Blazor Server. I can do a post on this in the future if there is any interest.

In a real project you would implement your own authentication and authorization on the SignalR connections/hub, but, as this is a demo…

I'm walking through how I, personally, approached this problem. I can guarantee that there are better and more performant ways to achieve the same result. The reason I am writing this is to improve as a developer and I apologize in advance for any coding sins you are about to witness.

You can find the GitHub repo with commits at each step here: WasmLogToBrowser GitHub Repo

To get started we will create a new ASP.NET Core hosted Blazor WASM application.

dotnet new blazorwasm --hosted -o WasmLogToBrowser
Now add the packages we need and start the server:
cd .\WasmLogToBrowser\Client
dotnet add package Microsoft.AspNetCore.SignalR.Client
cd ..\Server
dotnet add package NLog
dotnet add package NLog.Web.AspNetCore
dotnet add package Microsoft.AspNetCore.SignalR.Client

Step 1: Hook Up NLog

Create Server\Logging\Logger.cs and then update Server\Program.cs:

// Logger.cs
using NLog;
using NLog.Config;
using NLog.Targets;

namespace WasmLogToBrowser.Server.Logging
{
    public static class Logger
    {
        public static NLog.Logger Log = LogManager.GetCurrentClassLogger();

        public static void Configure()
        {
            LoggingConfiguration config = new LoggingConfiguration();
            string layout = "${longdate}|${level}|${callsite}|Line:${callsite-linenumber}|${message}             ${all-event-properties} ${exception:format=tostring}";

            // Log to console
            ColoredConsoleTarget consoleTarget = new ColoredConsoleTarget()
            {
                UseDefaultRowHighlightingRules = true,
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: consoleTarget);

            // Log to file (minLevel: Info)
            FileTarget infoFileTarget = new FileTarget("info")
            {
                FileName = "${basedir}\\Logging\\${date:format=yyyy-MM-dd}.log",
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Info, maxLevel: NLog.LogLevel.Fatal, target: infoFileTarget);

            // Log to file (minLevel: Trace)
            FileTarget traceFileTarget = new FileTarget("trace")
            {
                FileName = "${basedir}\\Logging\\${date:format=yyyy-MM-dd}.trace.log",
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: traceFileTarget);

            LogManager.Configuration = config;
            Log = LogManager.GetCurrentClassLogger();
        }
    }
}

// Program.cs
using WasmLogToBrowser.Server.Logging;

Logger.Configure();
Logger.Log.Info("App starting");
// Lets log something every second to simulate legitimate log output
System.Timers.Timer timer = new System.Timers.Timer(1000);
timer.Elapsed += (source, e) =>
{
    Logger.Log.Trace("tick");
};
timer.Enabled = true;
timer.Start();

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllersWithViews();
builder.Services.AddRazorPages();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseWebAssemblyDebugging();
}
else
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();

app.UseBlazorFrameworkFiles();
app.UseStaticFiles();

app.UseRouting();


app.MapRazorPages();
app.MapControllers();
app.MapFallbackToFile("index.html");

app.Run();

We now have some simulated log output we can worry about getting into the browser:

Step 2: Create SignalR Hub

Create Server\Hubs\LoggingHub.cs and hook it up in the Server\Program.cs:

// LoggingHub.cs
using Microsoft.AspNetCore.SignalR;
using WasmLogToBrowser.Server.Logging;

namespace WasmLogToBrowser.Server.Hubs
{
    public class LoggingHub : Hub
    {
        public async Task Log(string logMessage)
        {
            await Clients.All.SendAsync("Log", logMessage);
        }

        public override Task OnConnectedAsync()
        {
            Logger.Log.Trace("Top");
            Logger.Log.Debug($"{Context.ConnectionId} connected");
            return base.OnConnectedAsync();
        }

        public override async Task OnDisconnectedAsync(Exception? e)
        {
            Logger.Log.Trace("Top");
            Logger.Log.Debug($"Disconnected {e?.Message} {Context.ConnectionId}");
            await base.OnDisconnectedAsync(e);
        }
    }
}

// Program.cs
using Microsoft.AspNetCore.ResponseCompression;
using WasmLogToBrowser.Server.Hubs;
using WasmLogToBrowser.Server.Logging;

Logger.Configure();
Logger.Log.Info("App starting");
// Lets log something every second to simulate legitimate log output
System.Timers.Timer timer = new System.Timers.Timer(1000);
timer.Elapsed += (source, e) =>
{
    Logger.Log.Trace("tick");
};
timer.Enabled = true;
timer.Start();

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddSignalR();
builder.Services.AddControllersWithViews();
builder.Services.AddRazorPages();
builder.Services.AddResponseCompression(opts =>
{
    opts.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(
        new[] { "application/octet-stream" });
});

var app = builder.Build();

app.UseResponseCompression();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseWebAssemblyDebugging();
}
else
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseBlazorFrameworkFiles();
app.UseStaticFiles();

app.UseRouting();

app.MapRazorPages();
app.MapControllers();
app.MapHub<LoggingHub>("/hubs/logging");
app.MapFallbackToFile("index.html");

app.Run();

Step 3: Create and connect a custom NLog Target to the LoggingHub

In order for our custom NLog target to log to the LoggingHub we will need to connect ourselves so we will create both a Server\Logging\LoggingHubTarget.cs and a connection class at Server\Logging\LoggingHubConnection.cs the target can use to establish the connection when the target is instantiated. Finally, we will add the target to Server\Logging\Logger.cs::Configure().

// Logger.cs
using NLog;
using NLog.Config;
using NLog.Targets;

namespace WasmLogToBrowser.Server.Logging
{
    public static class Logger
    {
        public static NLog.Logger Log = LogManager.GetCurrentClassLogger();

        public static void Configure()
        {
            LoggingConfiguration config = new LoggingConfiguration();
            string layout = "${longdate}|${level}|${callsite}|Line:${callsite-linenumber}|${message}             ${all-event-properties} ${exception:format=tostring}";

            // Log to console
            ColoredConsoleTarget consoleTarget = new ColoredConsoleTarget()
            {
                UseDefaultRowHighlightingRules = true,
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: consoleTarget);

            // Log to file (minLevel: Info)
            FileTarget infoFileTarget = new FileTarget("info")
            {
                FileName = "${basedir}\\Logging\\${date:format=yyyy-MM-dd}.log",
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Info, maxLevel: NLog.LogLevel.Fatal, target: infoFileTarget);

            // Log to file (minLevel: Trace)
            FileTarget traceFileTarget = new FileTarget("trace")
            {
                FileName = "${basedir}\\Logging\\${date:format=yyyy-MM-dd}.trace.log",
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: traceFileTarget);

            // Log to SignalR LoggingHub
            var loggingHubTarget = new LoggingHubTarget("https://localhost:7254/hubs/logging")
            {
                Layout = layout
            };
            config.AddRule(minLevel: NLog.LogLevel.Trace, maxLevel: NLog.LogLevel.Fatal, target: loggingHubTarget);

            LogManager.Configuration = config;
            Log = LogManager.GetCurrentClassLogger();
        }
    }
}

// LoggingHubConnection.cs
using Microsoft.AspNetCore.SignalR.Client;

namespace WasmLogToBrowser.Server.Logging
{
    public class LoggingHubConnection : IAsyncDisposable
    {
        private HubConnection? _hubConnection;
        private string _hubUrl;

        public LoggingHubConnection(string hubUrl)
        {
            _hubUrl = hubUrl;
        }

        public async Task Log(string logMessage)
        {
            await EnsureConnection();
            if (_hubConnection != null)
            {
                await _hubConnection.SendAsync("Log", logMessage);
            }
        }

        public async Task EnsureConnection()
        {
            if (_hubConnection == null)
            {
                _hubConnection = new HubConnectionBuilder()
                .WithUrl(_hubUrl)
                .Build();

                await _hubConnection.StartAsync();
            }
            else if (_hubConnection.State == HubConnectionState.Disconnected)
            {
                await _hubConnection.StartAsync();
            }
        }

        public async ValueTask DisposeAsync()
        {
            if (_hubConnection != null)
            {
                try
                {
                    await _hubConnection.StopAsync();
                    await _hubConnection.DisposeAsync();
                }
                catch (Exception ex)
                {
                    NLog.Common.InternalLogger.Error(ex, "Exception in LoggingHubConnection.DisposeAsync");
                }
                finally
                {
                    _hubConnection = null;
                }
            }
        }
    }
}

// LoggingHubTarget.cs
using NLog;
using NLog.Targets;

namespace WasmLogToBrowser.Server.Logging
{
    public class LoggingHubTarget : AsyncTaskTarget
    {
        private LoggingHubConnection? _connection;

        public LoggingHubTarget(string hubUrl)
        {
            _connection = new LoggingHubConnection(hubUrl);
            OptimizeBufferReuse = true;
        }

        protected override async Task WriteAsyncTask(LogEventInfo logEvent, CancellationToken token)
        {
            string logMessage = this.Layout.Render(logEvent);
            if (_connection != null)
            {
                await _connection.Log(logMessage);
            }
        }

        protected override async void CloseTarget()
        {
            if (_connection != null)
            {
                await _connection.DisposeAsync();
                _connection = null;
            }
        }
    }
}

When we start the server now we should see a connection from the LoggingHubTarget come through in OnConnectedAsync:

The server is now broadcasting all NLog messages to clients connected to the SignalR hub at https://locahost:XXXX/hubs/logging.

Step 4: ServerConsole.razor, DebugService and hooking them up to the index page

First we need to create and hook up our Client\Services\DebugService.cs which is going to handle storing the log messages and (in the next step) toggling the console connection on/off.

Razor components will be able to inject DebugService to get access to the log messages and subscribe to the OnChange event within the DebugService to have Blazor re-render.

I’m a big fan of this approach to state management compared to React + Redux with the boilerplate and having to pass the entire state down the component tree.

// _Imports.razor
@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using WasmLogToBrowser.Client
@using WasmLogToBrowser.Client.Shared
@using WasmLogToBrowser.Client.Services

// DebugService.cs
namespace WasmLogToBrowser.Client.Services
{
    public class DebugService
    {
        public event Func<Task>? OnChange;
        public bool ConnectToServerConsole = true;
        public List<string> LogMessages = new List<string>();

        public void AddLogMessage(string logMessage)
        {
            LogMessages.Add(logMessage);
            HandleOnChange();
        }

        private void HandleOnChange()
        {
            if (OnChange != null)
            {
                OnChange?.Invoke();
            }
        }
    }
}

// Program.cs 
using Microsoft.AspNetCore.Components.Web;
using Microsoft.AspNetCore.Components.WebAssembly.Hosting;
using WasmLogToBrowser.Client;
using WasmLogToBrowser.Client.Services;

var builder = WebAssemblyHostBuilder.CreateDefault(args);
builder.RootComponents.Add<App>("#app");
builder.RootComponents.Add<HeadOutlet>("head::after");

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
builder.Services.AddScoped<DebugService>();

await builder. Build().RunAsync();

Now that is out of the way we can implement our Client\Shared\ServerConsole.razor component that we will mount in Client\Shared\MainLayout.razor if DebugService.ConnectToServerConsole is true.

// MainLayout.razor
@inherits LayoutComponentBase
@inject DebugService DebugService
@implements IDisposable

<div class="page">
    <div class="sidebar">
        <NavMenu />
    </div>

    <main>
        <div class="top-row px-4">
            <a href="https://docs.microsoft.com/aspnet/" target="_blank">About</a>
        </div>

        <article class="content px-4">
            @Body
        </article>
        @if (DebugService.ConnectToServerConsole) {
            <ServerConsole />
        }
    </main>
</div>

@code {
    public async Task OnChange()
    {     
        await InvokeAsync(() =>
        {
            StateHasChanged();
        });
    }

    protected override void OnInitialized()
    {
        DebugService.OnChange += OnChange;                    
    }

    public void Dispose()
    {        
        DebugService.OnChange -= OnChange;       
    }
}

// ServerConsole.razor
@using Microsoft.AspNetCore.SignalR.Client
@inject DebugService DebugService
@inject NavigationManager NavigationManager
@implements IDisposable

<div class="server-console">Server Console: @_hubConnection?.State</div>

@code {
    private HubConnection? _hubConnection;

    private void OnReceiveLogMessage(string logMessage)
    {
        DebugService.AddLogMessage(logMessage);        
    }

    private async Task OnChange()
    {   
        await InvokeAsync(() =>
        {
            StateHasChanged();
        });
    }

    protected override async void OnInitialized()
    {        
        DebugService.OnChange += OnChange;
        _hubConnection = new HubConnectionBuilder()
            .WithUrl($"{NavigationManager.BaseUri}hubs/logging")
            .Build();

        _hubConnection.On<string>("Log", OnReceiveLogMessage);        
        await _hubConnection.StartAsync();
    }

    public void Dispose()
    {        
        DebugService.OnChange -= OnChange;
        if (_hubConnection != null)
        {            
            try
            {             
                _hubConnection.StopAsync();
                _hubConnection.DisposeAsync();
                _hubConnection = null;
            } catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            } finally
            {
                _hubConnection = null;
            }
        }
    }
}

Finally, some styling tweaks in Client\wwwroot\css\app.css and then we can display the DebugService LogMessages list on the Client\Pages\Index.razor page:

// app.css
@import url('open-iconic/font/css/open-iconic-bootstrap.min.css');

html, body {
    font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;
}

h1:focus {
    outline: none;
}

a, .btn-link {
    color: #0071c1;
}

.btn-primary {
    color: #fff;
    background-color: #1b6ec2;
    border-color: #1861ac;
}

.content {
    padding-top: 1.1rem;
}

.valid.modified:not([type=checkbox]) {
    outline: 1px solid #26b050;
}

.invalid {
    outline: 1px solid red;
}

.validation-message {
    color: red;
}

#blazor-error-ui {
    background: lightyellow;
    bottom: 0;
    box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
    display: none;
    left: 0;
    padding: 0.6rem 1.25rem 0.7rem 1.25rem;
    position: fixed;
    width: 100%;
    z-index: 1000;
}

    #blazor-error-ui .dismiss {
        cursor: pointer;
        position: absolute;
        right: 0.75rem;
        top: 0.5rem;
    }

.blazor-error-boundary {
    background: url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iNTYiIGhlaWdodD0iNDkiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIG92ZXJmbG93PSJoaWRkZW4iPjxkZWZzPjxjbGlwUGF0aCBpZD0iY2xpcDAiPjxyZWN0IHg9IjIzNSIgeT0iNTEiIHdpZHRoPSI1NiIgaGVpZ2h0PSI0OSIvPjwvY2xpcFBhdGg+PC9kZWZzPjxnIGNsaXAtcGF0aD0idXJsKCNjbGlwMCkiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMzUgLTUxKSI+PHBhdGggZD0iTTI2My41MDYgNTFDMjY0LjcxNyA1MSAyNjUuODEzIDUxLjQ4MzcgMjY2LjYwNiA1Mi4yNjU4TDI2Ny4wNTIgNTIuNzk4NyAyNjcuNTM5IDUzLjYyODMgMjkwLjE4NSA5Mi4xODMxIDI5MC41NDUgOTIuNzk1IDI5MC42NTYgOTIuOTk2QzI5MC44NzcgOTMuNTEzIDI5MSA5NC4wODE1IDI5MSA5NC42NzgyIDI5MSA5Ny4wNjUxIDI4OS4wMzggOTkgMjg2LjYxNyA5OUwyNDAuMzgzIDk5QzIzNy45NjMgOTkgMjM2IDk3LjA2NTEgMjM2IDk0LjY3ODIgMjM2IDk0LjM3OTkgMjM2LjAzMSA5NC4wODg2IDIzNi4wODkgOTMuODA3MkwyMzYuMzM4IDkzLjAxNjIgMjM2Ljg1OCA5Mi4xMzE0IDI1OS40NzMgNTMuNjI5NCAyNTkuOTYxIDUyLjc5ODUgMjYwLjQwNyA1Mi4yNjU4QzI2MS4yIDUxLjQ4MzcgMjYyLjI5NiA1MSAyNjMuNTA2IDUxWk0yNjMuNTg2IDY2LjAxODNDMjYwLjczNyA2Ni4wMTgzIDI1OS4zMTMgNjcuMTI0NSAyNTkuMzEzIDY5LjMzNyAyNTkuMzEzIDY5LjYxMDIgMjU5LjMzMiA2OS44NjA4IDI1OS4zNzEgNzAuMDg4N0wyNjEuNzk1IDg0LjAxNjEgMjY1LjM4IDg0LjAxNjEgMjY3LjgyMSA2OS43NDc1QzI2Ny44NiA2OS43MzA5IDI2Ny44NzkgNjkuNTg3NyAyNjcuODc5IDY5LjMxNzkgMjY3Ljg3OSA2Ny4xMTgyIDI2Ni40NDggNjYuMDE4MyAyNjMuNTg2IDY2LjAxODNaTTI2My41NzYgODYuMDU0N0MyNjEuMDQ5IDg2LjA1NDcgMjU5Ljc4NiA4Ny4zMDA1IDI1OS43ODYgODkuNzkyMSAyNTkuNzg2IDkyLjI4MzcgMjYxLjA0OSA5My41Mjk1IDI2My41NzYgOTMuNTI5NSAyNjYuMTE2IDkzLjUyOTUgMjY3LjM4NyA5Mi4yODM3IDI2Ny4zODcgODkuNzkyMSAyNjcuMzg3IDg3LjMwMDUgMjY2LjExNiA4Ni4wNTQ3IDI2My41NzYgODYuMDU0N1oiIGZpbGw9IiNGRkU1MDAiIGZpbGwtcnVsZT0iZXZlbm9kZCIvPjwvZz48L3N2Zz4=) no-repeat 1rem/1.8rem, #b32121;
    padding: 1rem 1rem 1rem 3.7rem;
    color: white;
}

    .blazor-error-boundary::after {
        content: "An error has occurred."
    }

.server-console {
    position: absolute;
    bottom: 0;
    right: 0;
    z-index: 2;
    margin-bottom: 0.33rem;
    margin-right: 0.5rem;
    color: #181818;
    font-size: 12px;
}

.console {
    font-family: Courier New, Courier, monospace;
    font-size: 12px;
    background-color: #303030;
    color: #ffffffc7;
    border-radius: 0.5rem;
    padding: 1rem;
}

// Index.razor
@page "/"
@inject DebugService DebugService
@implements IDisposable

<PageTitle>Index</PageTitle>

<h1>Hello, world!</h1>

Welcome to your new app.

<SurveyPrompt Title="How is Blazor working for you?" />

@if (DebugService.LogMessages.Count > 0)
{
    <hr />
    <h3>Server Console</h3>    
    <div class="console">
        @foreach (string s in DebugService.LogMessages)
        {
            <div>@s</div>
        }
    </div>    
}

@code {
    public async Task OnChange()
    {        
        await InvokeAsync(() =>
        {
            StateHasChanged();
        });
    }

    protected override void OnInitialized()
    {
        DebugService.OnChange += OnChange;        
    }

    public void Dispose()
    {
        DebugService.OnChange -= OnChange;               
    }
}

Now when we run our app we get server console output!

Step 5: Make the console toggle-able and implement clearing the console

For the toggle we will clean up Client\Pages\Index.razor and implement the toggle in Client\Services\DebugService.cs. We will also set ConnectToServerConsole to false by default so that connecting to the server console is a manual thing like one might do in a debugging scenario.

// DebugService.cs
namespace WasmLogToBrowser.Client.Services
{
    public class DebugService
    {
        public event Func<Task>? OnChange;
        public bool ConnectToServerConsole = false;
        public List<string> LogMessages = new List<string>();

        public void AddLogMessage(string logMessage)
        {
            LogMessages.Add(logMessage);
            HandleOnChange();
        }

        public void ClearLogMessages()
        {
            LogMessages.Clear();
            HandleOnChange();
        }

        public void ToggleConnectToServerConsole()
        {
            ConnectToServerConsole = !ConnectToServerConsole;
            HandleOnChange();
        }

        private void HandleOnChange()
        {
            if (OnChange != null)
            {
                OnChange?.Invoke();
            }
        }
    }
}

// Index.razor
@page "/"
@inject DebugService DebugService
@implements IDisposable

<PageTitle>Debug</PageTitle>

<h1>Debug</h1>

<input name="logtojavascriptconsole" type="checkbox" checked=@DebugService.ConnectToServerConsole @onchange="LogToJavascriptConsoleChanged"/>
<label for="logtojavascriptconsole">Stream server logs to Javascript console</label>


@if (DebugService.LogMessages.Count > 0)
{
    <hr />
    <h3>Server Console</h3>   
    <button style="float: right;" class="btn-sm btn-danger m-2" @onclick="DebugService.ClearLogMessages">Clear console</button>
    <div class="console">
        @foreach (string s in DebugService.LogMessages)
        {
            <div>@s</div>
        }
    </div>    
}

@code {
    private void LogToJavascriptConsoleChanged(ChangeEventArgs e)
    {
        DebugService.ToggleConnectToServerConsole();       
    }

    public async Task OnChange()
    {        
        await InvokeAsync(() =>
        {
            StateHasChanged();
        });
    }

    protected override void OnInitialized()
    {
        DebugService.OnChange += OnChange;        
    }

    public void Dispose()
    {
        DebugService.OnChange -= OnChange;               
    }
}

Toggle and clear in action:

Note the ServerConsole.razor component unmounting/remounting in the bottom right on toggle

Step 6: Simultaneously output logs to the JavaScript console

It’s nice to be able to access the logs from anywhere in our application but, for practical purposes, we would likely open and detach a devtools console.

Lets create a console logging helper class at Client\Library\JsConsole.cs, implement the functionality in Client\Services\DebugService.cs and hook the JsConsole up in Client\Program.cs.

We also need to change the OnReceiveLogMessage void in Client\Shared\ServerConsole.razor to an async Task now that AddLogMessage in the DebugService is async.

// DebugService.cs
using WasmLogToBrowser.Client.Library;

namespace WasmLogToBrowser.Client.Services
{
    public class DebugService
    {
        private readonly JsConsole _console;
        public event Func<Task>? OnChange;
        public bool ConnectToServerConsole = false;
        public List<string> LogMessages = new List<string>();

        public DebugService(JsConsole console)
        {
            _console = console;
        }

        public async Task AddLogMessage(string logMessage)
        {
            LogMessages.Add(logMessage);
            await _console.LogAsync(logMessage);
            HandleOnChange();
        }

        public async Task ClearLogMessages()
        {
            LogMessages.Clear();
            await _console.ClearAsync();
            HandleOnChange();
        }

        public void ToggleConnectToServerConsole()
        {
            ConnectToServerConsole = !ConnectToServerConsole;
            HandleOnChange();
        }

        private void HandleOnChange()
        {
            if (OnChange != null)
            {
                OnChange?.Invoke();
            }
        }
    }
}

// JsConsole.cs
using Microsoft.JSInterop;

namespace WasmLogToBrowser.Client.Library
{
    public class JsConsole
    {
        private readonly IJSRuntime _jsRuntime;
        public JsConsole(IJSRuntime jSRuntime)
        {
            _jsRuntime = jSRuntime;
        }

        public async Task LogAsync(string message)
        {
            await _jsRuntime.InvokeVoidAsync("console.log", message);
        }

        public async Task ClearAsync()
        {
            await _jsRuntime.InvokeVoidAsync("console.clear");
        }
    }
}

// Program.cs
using Microsoft.AspNetCore.Components.Web;
using Microsoft.AspNetCore.Components.WebAssembly.Hosting;
using WasmLogToBrowser.Client;
using WasmLogToBrowser.Client.Library;
using WasmLogToBrowser.Client.Services;

var builder = WebAssemblyHostBuilder.CreateDefault(args);
builder.RootComponents.Add<App>("#app");
builder.RootComponents.Add<HeadOutlet>("head::after");

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
builder.Services.AddScoped<DebugService>();
builder.Services.AddScoped<JsConsole>();

await builder.Build().RunAsync();

// ServerConsole.razor
@using Microsoft.AspNetCore.SignalR.Client
@inject DebugService DebugService
@inject NavigationManager NavigationManager
@implements IDisposable

<div class="server-console">Server Console: @_hubConnection?.State</div>

@code {
    private HubConnection? _hubConnection;

    private async Task OnReceiveLogMessage(string logMessage)
    {
        await DebugService.AddLogMessage(logMessage);        
    }

    private async Task OnChange()
    {   
        await InvokeAsync(() =>
        {
            StateHasChanged();
        });
    }

    protected override async void OnInitialized()
    {        
        DebugService.OnChange += OnChange;
        _hubConnection = new HubConnectionBuilder()
            .WithUrl($"{NavigationManager.BaseUri}hubs/logging")
            .Build();

        _hubConnection.On<string>("Log", OnReceiveLogMessage);        
        await _hubConnection.StartAsync();
    }

    public void Dispose()
    {        
        DebugService.OnChange -= OnChange;
        if (_hubConnection != null)
        {            
            try
            {             
                _hubConnection.StopAsync();
                _hubConnection.DisposeAsync();
                _hubConnection = null;
            } catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            } finally
            {
                _hubConnection = null;
            }
        }
    }
}

Now we have output in the console which we can view regardless of which page we’re on in the app:

This is much more useful for Blazor Server projects as everything is happening on the server already. I can see this being very useful while an app is in development but you’d either want to make sure your auth on the LoggingHub is solid or else you’d want to remove the feature completely for production.

You can find the GitHub repo with commits at each step here: WasmLogToBrowser GitHub Repo