DEV Community: Simone Riggi

Mastering Task Cancellation in C#: A Practical Guide with Linked Tokens

Simone Riggi — Fri, 05 Sep 2025 15:59:33 +0000

Over the past few days, I worked on a microservice that heavily relied on asynchronous tasks, synchronized code sections, and monitoring jobs to keep track of the task status. While doing this, I struggled a bit to fully understand how the cancellation token pattern works in C#. In this article, I’ll share what I learned.

Async Programming in C

Async programming in C# is powerful—but as with great power comes great responsibility.

Long-running tasks can quickly become resource hogs if you don’t give them a way to stop when they’re no longer needed. That’s exactly where cancellation tokens come in.

In this guide, we’ll explore:

How to use CancellationToken
How to combine multiple cancellation sources with CreateLinkedTokenSource()
A practical demo: a fake file download manager with workers that can be cancelled by the user or automatically when they timeout

Why Cancellation Matters

Imagine starting a big file download—or any task that risks running forever in the background. Now imagine the user closes the app or decides to cancel. Without cancellation support, your tasks will continue running until completion, wasting CPU and memory.

Cancellation tokens provide a cooperative mechanism to signal when a task should stop.

A First Taste of Cancellation

Our demo will have the following requirements:

Start 5 tasks simulating file downloads
Each download should take roughly 5–10 seconds
Show progress in the console
Allow the user to cancel all downloads by pressing 'c'
Support a timeout simulation on one of the tasks that cancels itself
Print a success message if all tasks complete

static void Main(string[] args)
{
    var externalCancellation = new CancellationTokenSource();
    var app = new Program();

    Task.Run(() =>
    {
        Console.WriteLine("Press 'c' to cancel within 3 seconds after work begins.");
        Console.WriteLine("Or let the task time out by doing nothing.");
        if (Console.ReadKey(true).KeyChar == 'c')
            externalCancellation.Cancel();
    });

    // Wait 1 second before starting the main work
    Thread.Sleep(1000);

    Task[] tasks = new Task[5];
    for (int i = 0; i < 5; i++)
    {
        int workerIndex = i; // capture the current value
        tasks[i] = Task.Run(() =>
        {
            var timerTimeout = workerIndex == 1 ? 2000 : (int?)null;
            var worker = new BackgroundDownloadWorker(workerIndex, timerTimeout);
            worker.DoWork(externalCancellation.Token);
        });
    }

    try
    {
        Task.WhenAll(tasks).Wait();
        Console.WriteLine("Main: All workers completed successfully.");
    }
    catch (AggregateException ae)
    {
        foreach (var e in ae.InnerExceptions)
        {
            if (e is OperationCanceledException)
            {
                if (externalCancellation.IsCancellationRequested)
                    Console.WriteLine("Main: Operation cancelled by user.");
                else
                    Console.WriteLine("Main: Operation cancelled due to timeout or other reasons.");
            }
        }
    }

    Console.WriteLine("Press a key to exit");
    Console.ReadKey();
    externalCancellation.Dispose();
}

Key Takeaways from the Main Program:

A separate task monitors for user cancellation via key press.
externalCancellation is used to cancel all running tasks when the user presses 'c'.
Each worker executes a simulated file download, with a unique index for console logging.
When cancellation occurs, an OperationCanceledException is thrown and caught, distinguishing between user-triggered and internal cancellations.

BackgroundDownloadWorker

class BackgroundDownloadWorker
{
    private CancellationTokenSource internalCancellation = new CancellationTokenSource();
    private CancellationToken internalCancellationToken;
    private int _workerIndex;
    private Timer _timer;

    public BackgroundDownloadWorker(int index, int? timerTimeout = null)
    {
        _workerIndex = index + 1;
        if (timerTimeout.HasValue)
            _timer = new Timer(TimeoutAction, null, timerTimeout.Value, Timeout.Infinite);
    }

    public void DoWork(CancellationToken externalCancellationToken)
    {
        internalCancellationToken = internalCancellation.Token;
        using var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(internalCancellationToken, externalCancellationToken);

        try
        {
            DoInternalWork(linkedCts.Token);
        }
        catch (OperationCanceledException)
        {
            if (internalCancellationToken.IsCancellationRequested)
                Console.WriteLine($"Worker {_workerIndex}:: download timeout");

            if (externalCancellationToken.IsCancellationRequested)
                Console.WriteLine($"Worker {_workerIndex}:: download cancelled by user");
        }
    }

    private void DoInternalWork(CancellationToken cancellationToken)
    {
        int secondsOfWork = _workerIndex switch
        {
            1 => 5000,
            2 => 8000,
            3 => 10000,
            _ => 7000
        };

        Console.WriteLine($"Worker {_workerIndex}:: downloading");

        for (int i = 0; i < secondsOfWork; i += 1000)
        {
            cancellationToken.ThrowIfCancellationRequested();
            Console.WriteLine($"Worker {_workerIndex}:: Working... {i / 1000 + 1} seconds elapsed.");
            Thread.Sleep(1000);
        }

        Console.WriteLine($"Worker {_workerIndex}:: Download completed successfully.");
    }

    private void TimeoutAction(object state)
    {
        Console.WriteLine($"Worker {_workerIndex}:: timeout expired");
        internalCancellation.Cancel();
        _timer.Dispose();
    }
}

1. Fields

private CancellationTokenSource internalCancellation = new CancellationTokenSource();
private CancellationToken internalCancellationToken;
private int _workerIndex;
private Timer _timer;

internalCancellation: A CancellationTokenSource that allows this worker to cancel itself, e.g., on timeout.
internalCancellationToken: Holds the CancellationToken from internalCancellation, to be used for checking if the task was canceled internally.
_workerIndex: Stores the worker’s index, mainly for logging purposes.
_timer: A System.Threading.Timer to enforce a timeout on the work

2. Constructor

public BackgroundDownloadWorker(int index, int? timerTimeout = null)
{
    _workerIndex = index + 1;
    if (timerTimeout.HasValue)
        _timer = new Timer(TimeoutAction, null, timerTimeout.Value, Timeout.Infinite);
}

index: Used to differentiate workers.
timerTimeout: Optional parameter that sets a timeout in milliseconds.
If a timeout is provided, a timer is created, which will call _TimeoutAction _when the timeout expires.

3. Method

public void DoWork(CancellationToken externalCancellationToken)
{
    internalCancellationToken = internalCancellation.Token;
    using var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(internalCancellationToken, externalCancellationToken);

    try
    {
        DoInternalWork(linkedCts.Token);
    }
    catch (OperationCanceledException)
    {
        if (internalCancellationToken.IsCancellationRequested)
            Console.WriteLine($"Worker {_workerIndex}:: download timeout");

        if (externalCancellationToken.IsCancellationRequested)
            Console.WriteLine($"Worker {_workerIndex}:: download cancelled by user");
    }
}

Accepts an external cancellation token, e.g., user requested cancellation.
Combines internal and external tokens into a linked token. This allows cancellation to occur from either source.
Calls DoInternalWork, which simulates the download.
Catches OperationCanceledException and logs the reason for cancellation:
- Internal → timeout
- External → user cancellation

Combining Multiple Cancellation Sources

Sometimes cancellation can come from multiple sources:

External cancellation – user input, signals, etc.
Internal cancellation – timeout, watchdog, or business logic

C# provides a neat solution:

using var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(internalCancellationToken, externalCancellationToken);

If either token is cancelled, the linked token triggers cancellation for the task.

4. DoInternalWork Method

private void DoInternalWork(CancellationToken cancellationToken)
{
    int secondsOfWork = _workerIndex switch
    {
        1 => 5000,
        2 => 8000,
        3 => 10000,
        _ => 7000
    };

    Console.WriteLine($"Worker {_workerIndex}:: downloading");

    for (int i = 0; i < secondsOfWork; i += 1000)
    {
        cancellationToken.ThrowIfCancellationRequested();
        Console.WriteLine($"Worker {_workerIndex}:: Working... {i / 1000 + 1} seconds elapsed.");
        Thread.Sleep(1000);
    }

    Console.WriteLine($"Worker {_workerIndex}:: Download completed successfully.");
}

Simulates a download task by looping and sleeping 1 second at a time.
secondsOfWork is a rough duration for the task, based on _workerIndex.
Checks cancellationToken every second. If cancellation is requested, throws OperationCanceledException.
Logs progress to the console.

5. TimeoutAction Method

private void TimeoutAction(object state)
{
    Console.WriteLine($"Worker {_workerIndex}:: timeout expired");
    internalCancellation.Cancel();
    _timer.Dispose();
}

called when the timer expires.
Cancels the worker using internal cancellation.
Disposes the timer to clean up resources.

Test Cases

To see the cancellation pattern in action, you can test two main scenarios:

1️⃣ User Cancels with `'c'`

Scenario: The user decides to stop all downloads before they complete.

Steps:

Run the program.
When prompted, press 'c' within a few seconds.
Observe the console logs.

Expected Behavior:

Each worker (1,3) prints a cancellation message
Worker (2) cancelled because of timeout expired

2️⃣ Let the Program Run Without Interruption

Scenario: The program is allowed to complete normally.
Steps:

Run the program.
Do not press 'c'.
Wait for all workers to finish.

Expected Behavior:

Workers (1,3) complete their downloads successfully
Worker (2) cancelled because of timeout expired

Conclusion

In this article, we explored:

How to use CancellationToken to stop long-running tasks
How to link multiple cancellation sources (user input + internal timeout)
A practical demo with multiple background workers

This pattern is extremely useful in real applications:

Cancelling HTTP requests when users navigate away
Stopping database queries after a timeout
Managing parallel background jobs gracefully

Cancellation makes your applications more responsive, resource-friendly, and robust.

From .NET Framework on Windows to .NET 5 on Linux (AWS): what I migrated, how, and why

Simone Riggi — Fri, 22 Aug 2025 14:19:53 +0000

Overview

I recently completed a deep migration that touched code, infrastructure, build, and runtime. The starting point was a Windows-only .NET Framework class library, bundled into a monolithic deployment and manually hosted on a static server. It depended on Windows-specific executables/libraries, had hard-coded configuration, no CI/CD, and no elasticity.
The target was a cloud-native, Linux-hosted .NET 5 Web API running on EC2 behind an Auto Scaling Group, configured via AWS Systems Manager Parameter Store, managed by systemd, and deployed automatically through TeamCity.

Note: I had to use .NET 5 ** to guarantee the backward compatibility of legacy code and third-party libraries** not compatible with .NET6+.

Why the change?

Cost: Linux vs Windows hosting.
Modernization: move toward .NET (Core) and decouple from Win32 APIs.
Scalability: ASG with rolling/instance refresh.
Velocity: CI/CD, reproducible builds.
Reliability: systemd supervision, health checks, structured logging.

Before → After

Before

.NET Framework class library (MVC-era Web API glue).
Windows-only dependencies (EXEs/DLLs).
Manual deploys, single box, no auto-scaling.
Config in web.config/app.config, minimal environment awareness.

After

.NET 5 Web API (Kestrel), Linux-first.
Native dependencies replaced or repackaged for Linux.
CI/CD with TeamCity → S3 artifact → ASG instance refresh.
Config from Parameter Store → appsettings.json at boot.
Service managed by systemd with logs in journalctl

Step 1 — Port to .NET 5 Web API

I created a new .NET 5 Web API host and moved all registration/configuration (Autofac, Swagger, formatters, handlers) into Startup/Program:

public class Program
{
    public static void Main(string[] args) =>
        CreateHostBuilder(args).Build().Run();

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(web =>
            {
                // Listen on any IP; can be overridden with ASPNETCORE_URLS or --urls
                web.UseKestrel()
                   .UseStartup<Startup>();
            });
}

Key changes:

Handlers → Middleware: old DelegatingHandler/MessageHandler logic became ASP.NET Core middleware.
Configuration: moved from AppSettings.config to appsettings.json + IConfiguration/IOptions<T>.
Swagger: re-registered via AddSwaggerGen() and UseSwaggerUI().

Note: .NET 5 does not support implicit global usings (that came in .NET 6). Keep your usings explicit.

Step 2 — Make it build and run on Linux

Set the runtime identifier and (optionally) self-contained publish in the Web API .csproj:

<PropertyGroup>
  <TargetFramework>net5.0</TargetFramework>
  <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
  <PublishSingleFile>true</PublishSingleFile>
  <SelfContained>true</SelfContained>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

Publish:

dotnet publish -c Release -r linux-x64

Tip: If you use third-party libraries, ensure the Linux variants are included next to your binary and have execute permission where required.

Step 3 — Handle Windows-only dependencies

Some functionality relied on Windows executables (e.g., structured output converters). On Linux:

Replace with vendor’s Linux binaries.
Ensure they’re part of the artifact (mark files as Copy to Output Directory).
Mark them executable at deploy time:

chmod +x /var/opt/net-webapi/Libraries/library

If a native .so must be found at runtime, export LD_LIBRARY_PATH in the service unit:

Environment=LD_LIBRARY_PATH=/var/opt/net-webapi/Libraries:$LD_LIBRARY_PATH

Also normalize path separators in code; prefer Path.Combine and avoid C:\... style paths.

Step 4 — Service on Linux with systemd

Create and add net-webapi.service in the .NET project:

[Unit]
Description=WebAPI service 
After=network.target

[Service]
WorkingDirectory=/var/opt/net-webapi
ExecStart=/var/opt/net-webapi/NET.WebAPI --urls http://0.0.0.0:80
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=net-webapi
User=www-data
Group=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
# Optional: for native libs / external tools
Environment=LD_LIBRARY_PATH=/var/opt/net-webapi/lib:$LD_LIBRARY_PATH
# Allow www-data to bind :80 without root (or use a reverse proxy)
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.targe

Step 5 — CI/CD with TeamCity → S3 → ASG refresh

Artifacts (example):

noodls.utilities/NET.WebAPI/bin/%Configuration%/net5.0/linux-x64 => NET/NET.WebAPI

Upload to S3 (build step):

<artifactsPath> => <bucket>/<env>/NET/NET.WebAPI/package.zip
<artifactsPath> => <bucket>/<env>/NET/NET.WebAPI/PreviousVersions/package_%build.number%.zip

Instance refresh (PowerShell in TeamCity agent, or Bash):

$envs = "%AutoscalingGroups%".Split([Environment]::NewLine)
foreach($env in $envs){
  $parts = $env.Split(';')
  if($parts.Count -lt 2){ continue }
  $asg = $parts[0].Trim(); $region = $parts[1].Trim()
  aws autoscaling start-instance-refresh `
    --auto-scaling-group-name $asg `
    --preferences '{\"InstanceWarmup\":300,\"MinHealthyPercentage\":100}' `
    --region $region
}

Example variable:

ASG-NET-WEBAPI;us-east-1

Step 6 — Launch Template & User Data (EC2)

Launch template highlights:

AMI: choose a Linux image compatible with your runtime.

For .NET 5 (OpenSSL 1.1), Ubuntu 20.04 (focal) or Amazon Linux 2 are safer than 22.04+ unless you add libssl1.1. Better yet, plan to upgrade to .NET 8.
IAM Role: allow ssm:GetParameter and S3 read.
Instance metadata:
- Enable metadata & allow tags in metadata.
Tags (key/value):
- appsettings-parameter-name = net-webapi.appsettings
- log4net-parameter-name = net-webapi.log4net

User Data (hardened & corrected):

#!/bin/bash
set -euo pipefail

# Update base
apt-get update -y
apt-get install -y unzip curl python3 jq

# Install AWS CLI v2
curl -sS "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o /tmp/awscliv2.zip
unzip -q /tmp/awscliv2.zip -d /tmp
/tmp/aws/install

# (Optional) Install chrony
apt-get install -y chrony

# Prepare app folder
install -d -o www-data -g www-data /var/opt/net-webapi

# Download package from S3
aws s3 cp "s3://<bucket>/<ENV>/NET/NET.WebAPI/package.zip" /tmp/package.zip
unzip -q /tmp/package.zip -d /var/opt/net-webapi
chown -R www-data:www-data /var/opt/net-webapi
chmod +x /var/opt/net-webapi/NET.WebAPI || true

# If you ship native tools, ensure they're executable
# chmod +x /var/opt/net-webapi/Exporters/AprysePDFNet/lib/StructuredOutput || true

# Fetch Parameter Store values (instance tags carry the parameter names)
CONFIG_PARAM=$(curl -fsS http://169.254.169.254/latest/meta-data/tags/instance/appsettings-parameter-name)
LOG4NET_PARAM=$(curl -fsS http://169.254.169.254/latest/meta-data/tags/instance/log4net-parameter-name)

aws ssm get-parameter --name "$CONFIG_PARAM" --with-decryption --region us-east-1 \
  | jq -r '.Parameter.Value' > /var/opt/net-webapi/appsettings.json

aws ssm get-parameter --name "$LOG4NET_PARAM" --with-decryption --region us-east-1 \
  | jq -r '.Parameter.Value' > /var/opt/net-webapi/log4net.config

chown www-data:www-data /var/opt/net-webapi/appsettings.json /var/opt/net-webapi/log4net.config

# Install systemd unit
cp /var/opt/net-webapi/net-webapi.service /etc/systemd/system/net-webapi.service
systemctl daemon-reload
systemctl enable net-webapi
systemctl start net-webapi

Avoid weakening TLS (e.g., forcing TLS 1.0 in openssl.cnf). Instead, keep modern defaults and fix the database side or client library if you hit handshake issues.

Step 7 — Database connectivity (TLS gotchas)

If you see errors like “SSL/TLS handshake failed”:

Prefer Microsoft.Data.SqlClient in .NET, which has better TLS support than the legacy System.Data.SqlClient.
Ensure SQL Server supports TLS 1.2+ with a proper certificate.
As a temporary diagnostic only, try Encrypt=False or TrustServerCertificate=True in the connection string to confirm TLS is the issue—then fix certificates and revert to secure defaults.

Step 8 — Observability & permissions

Use journalctl -u net-webapi -f to tail logs.
If the app writes under /var/opt/net-webapi/temp, ensure the folder exists and is writable by the service user:

install -d -o www-data -g www-data /var/opt/net-webapi/temp

For “Permission denied to execute external module” errors, chmod +x the binary and verify the directory mount options allow execution (noexec would block it).

Step 9 — TeamCity artifact hygiene

Mark non-code files (native tools, configs, templates) as “Copy to Output Directory” → “Copy if newer” so they appear in the published output and the TeamCity artifact.

What I’d improve next

Upgrade to .NET 8 LTS (security & runtime support; avoids OpenSSL 1.1 headaches).
Health checks (/health) + Auto Scaling based on ALB target health.
CodeDeploy or SSM Distributor instead of ad-hoc unzip for richer deployments.
Secret management via Parameter Store (SecureString) or Secrets Manager with IAM.

Final notes

This migration wasn’t just a “retarget the framework” exercise. It required:

Reworking hosting and middleware.
Replacing/porting Windows-specific dependencies.
Designing a Linux-friendly packaging and service model.
Building CI/CD and immutable infrastructure via ASG + Launch Templates.
Tightening permissions, TLS, and observability.

The Developer Behind the Code: Growth, Anxiety, and Rediscovering Joy

Simone Riggi — Sun, 03 Aug 2025 14:38:14 +0000

I promise — this will be the first and last post about me. From now on, I’ll try to keep things professional and focus on interesting topics.

I’ve always admired people who can explain complex technical ideas, or even talk about themselves, in a way that’s simple, engaging, and clear.

Lately, I’ve started journaling everything I do: what I learn, small wins of the day or week — anything that helps me stay aware of my journey, where I started, and where I’m heading.

Every morning, when I wake up, one of my first feelings is anxiety — the pressure to hit some goal of the day: read a book for 30 minutes, study one hour for a certification, journal, do something productive… and in the rush, I completely forget to breathe.

I’m writing this mainly to help myself. I read somewhere that writing your thoughts down can help you “debug” yourself. Maybe it’ll help someone else too.

Am I the only one obsessed with the idea of constant self-improvement? Every day feels like the day — the day I must make progress, and if I do, I expect to see immediate results.

But that’s not how it works (unfortunately).

How It Started

Six years ago, right after earning my Master’s degree in Computer Science and just before the pandemic hit, I started working as a Software Engineer at a consulting company.

Honestly, back then I didn’t want to be a developer.

Just the thought of deadlines, hidden bugs, building UIs and apps… it gave me a headache. I dreamed of a classic “9-to-6” job — no stress, no crunch, no chaos.

(Please don’t judge me — I was young, and I’m human.)

Anyway, if you’ve worked in consulting, you know the drill. You get hired, and then… you may wait. No clients. Just waiting.

Waiting for a project, waiting for a chance — any chance.

Luckily (yes, luckily), my first opportunity came in the form of a .NET Desktop application to develop with another colleague — both of us at our first job.

And that was it — despite all my efforts to avoid coding, fate had other plans.

Before I knew it, my life became a cycle of team meetings, client calls, demos, tasks, unit tests… and yes, deadlines.

I’ll spare you the details of how hard that first experience was — the unrealistic expectations, the pressure, the learning curve — but I want to highlight two things:

I realized I liked that life.
And surprisingly, I really liked .NET and C#.

It was a revelation. A real mind-blower.

From Confusion to Clarity

I remember the early months vividly. I’d look in the mirror and think:

“Really? You? Are you serious?”

But despite the sleepless nights and a few scoldings from clients, I discovered something unexpected:

I was having fun. I was being creative.

And it changed everything.

It was the one variable I hadn’t considered. Creativity.

It turned out to be the key to my career.

The Illusion of Constant Growth

At this point, you might expect a happy ending — that everything went smoothly from there, that I found my path and got better every day.

Not quite.

Once I found my way, another problem surfaced: the obsession with always improving.

Some days I feel really anxious — maybe I’m stuck doing boring or repetitive tasks, and I start thinking,

“Everyone else is building something meaningful while I’m stuck here.”

I don’t know if that’s true, but it’s probably more realistic to say that most people in tech aren’t changing the world every day.

Most of the time, we’re just facing challenges, fixing issues, and solving small problems — and over time, those little efforts can lead to something big.

I started coding in my free time, thinking it would help me grow, land a better job, learn a new framework, or build a product or startup.

But recently, I realized something: that mindset doesn’t come from love for software engineering.

It comes from anxiety and unrealistic expectations.

When your hobby becomes something that must deliver results — a business, a skill, a product — then it stops being a hobby.

So now, I’m trying to reset my mindset.

I want to code, study, or explore a topic just for the joy of it. For myself.

It doesn’t have to be perfect. I can even suck.

And that’s fine — because in that space, in my space, I feel free.

Free to experiment, take risks, create something useless, and enjoy the moment.

The Work on Myself

While writing this, I’m fully aware that shifting to this mindset isn’t easy.

It’s a daily process — journaling, analyzing habits, building new ones, letting go of others.

It takes commitment.

Awareness.

And the ability to celebrate small wins every day.

There’s probably no perfect recipe for becoming a great software engineer.

But I like to believe this:

Even if the path seems boring or pointless some days, if you try to improve just 1% each day, eventually you’ll reach a tipping point — where all the knowledge and effort you’ve accumulated finally pays off and becomes something powerful.

Thanks for reading. If you’ve felt similar emotions in your journey, I’d love to hear your story too.