DEV Community: dotnet

MCP (Model Context Protocol) for .NET Devs — What It Is and Why You'll Be Using It Soon

Vikrant Bagal — Fri, 15 May 2026 19:02:52 +0000

Every major AI tool is adopting MCP. If you build .NET APIs, this is the integration pattern coming your way.

What Is MCP?

MCP (Model Context Protocol) is an open-standard protocol designed to standardize integrations between AI applications and external tools and data sources. Think of it as the universal language that allows AI assistants to safely and securely connect to your .NET applications, databases, and APIs.

Originally developed by Anthropic in partnership with Microsoft, MCP provides a structured way for AI systems to:

Discover capabilities across different systems
Execute actions through external tools
Exchange structured context without custom integrations

The protocol is built on JSON-RPC 2.0, ensuring interoperability across platforms and tools.

Why MCP Matters for .NET Developers

If you're building APIs, microservices, or AI-powered applications with .NET, MCP is becoming the de facto standard for AI-tool communication. Here's why:

1. Microsoft's Full Backing

Microsoft is actively supporting MCP across its ecosystem:

Copilot Studio now supports MCP integrations
Visual Studio Code with GitHub Copilot agent mode uses MCP
Agent Framework integrates with MCP servers
Azure Functions supports remote MCP servers

This means your .NET applications can now communicate with AI agents in a standardized way.

2. Standardized AI Communication

Before MCP, every AI tool required custom integration code. MCP eliminates this by providing:

Unified protocol for all AI tools
Security-first design with explicit user consent
Composable architecture allowing multiple servers
Progressive enhancement for adding new features

3. Production-Ready .NET SDK

The official MCP C# SDK is available through NuGet and maintained by Microsoft in collaboration with Anthropic:

dotnet add package ModelContextProtocol --prerelease

This gives you everything you need to create MCP clients and servers in .NET.

The MCP Architecture

MCP follows a client-host-server architecture that's familiar to .NET developers:

Host

The host is your AI application (like GitHub Copilot in VS Code). It:

Creates and manages client instances
Handles security policies and user consent
Coordinates AI integration and sampling

Client

The client connects to MCP servers. It:

Establishes stateful sessions per server
Handles protocol negotiation
Routes messages between host and server

Server

The server exposes your .NET application's capabilities. It:

Provides tools, resources, and prompts
Operates independently with focused responsibilities
Can be local processes or remote services

Building Your First MCP Server in .NET

Creating an MCP server is surprisingly straightforward. Here's a basic stdio-based server:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;
using System.ComponentModel;

var builder = Host.CreateApplicationBuilder(args);
builder.Logging.AddConsole(consoleLogOptions =>
{
    consoleLogOptions.LogToStandardErrorThreshold = LogLevel.Trace;
});

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class EchoTool
{
    [McpServerTool, Description("Echoes the message back to the client.")]
    public static string Echo(string message) => $"Hello from C#: {message}";
}

What's happening here?

Host.CreateApplicationBuilder - Sets up dependency injection and hosting
AddMcpServer() - Registers the MCP server with DI
WithStdioServerTransport() - Configures stdio communication
WithToolsFromAssembly() - Auto-discovers tools marked with attributes
McpServerToolType - Marks a class as containing MCP tools
McpServerTool - Marks a method as an MCP-accessible tool

The Description attribute becomes part of the tool's metadata, helping AI models understand what each tool does.

Exposing Your .NET APIs with MCP

Let's say you have a Monkey API (because everyone needs one 🐒). Here's how to expose it via MCP:

public class MonkeyService
{
    private readonly HttpClient httpClient;
    public MonkeyService(IHttpClientFactory httpClientFactory)
    {
        httpClient = httpClientFactory.CreateClient();
    }

    public async Task<List<Monkey>> GetMonkeys()
    {
        var response = await httpClient.GetAsync("https://api.example.com/monkeys");
        // ... process and return monkeys
    }

    public async Task<Monkey?> GetMonkey(string name)
    {
        var monkeys = await GetMonkeys();
        return monkeys.FirstOrDefault(m => m.Name == name);
    }
}

[McpServerToolType]
public static class MonkeyTools
{
    [McpServerTool, Description("Get a list of all monkeys.")]
    public static async Task<string> GetMonkeys(MonkeyService service)
    {
        var monkeys = await service.GetMonkeys();
        return JsonSerializer.Serialize(monkeys);
    }

    [McpServerTool, Description("Get details for a specific monkey.")]
    public static async Task<string> GetMonkey(MonkeyService service, 
        [Description("The name of the monkey")] string name)
    {
        var monkey = await service.GetMonkey(name);
        return JsonSerializer.Serialize(monkey);
    }
}

Now AI assistants can query your monkey database through a standardized interface!

HTTP Transport for ASP.NET Core

For web APIs, you can use HTTP transport:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddMcpServer()
    .WithHttpTransport(options =>
    {
        options.Stateless = true;
    })
    .WithToolsFromAssembly();

var app = builder.Build();
app.MapMcp();
app.Run("http://localhost:3001");

This is perfect for exposing your existing ASP.NET Core APIs to AI tools without major refactoring.

Real-World Integrations

The MCP ecosystem already includes servers for:

Git - Version control operations
GitHub - Repository management
Playwright - Browser automation
Filesystem - Local file operations
Databases - SQL/NoSQL queries
Azure Services - Storage, Cosmos DB, etc.

You can also build custom MCP servers for your specific APIs, databases, or internal systems.

Security Considerations

MCP is designed with security first:

Explicit User Consent - Every tool invocation requires user approval
Data Privacy - Resources only share what's explicitly permitted
Tool Safety - Arbitrary code execution with proper safeguards
Sampling Controls - Users control LLM interaction parameters

As a .NET developer, you should:

Always implement proper authorization
Use least-privilege access for resources
Log and audit all tool invocations
Follow security best practices for your specific domain

Deployment Options

Local Development

Use stdio transport for local processes or ASP.NET Core HTTP servers.

Cloud Deployment

Azure Container Apps - Managed container hosting
Azure Functions - Serverless MCP servers
Docker - Multi-arch container images

Publishing a containerized MCP server:

<PropertyGroup>
    <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
    <ContainerRepository>myorg/mcp-server</ContainerRepository>
    <ContainerFamily>alpine</ContainerFamily>
    <RuntimeIdentifiers>linux-x64;linux-arm64</RuntimeIdentifiers>
</PropertyGroup>

Then deploy with:

dotnet publish /t:PublishContainer

The Future Is Here

MCP isn't just another API standard—it's becoming the universal protocol for AI-tool communication. Every major AI platform is adopting it:

GitHub Copilot
Claude
Cursor
Windsurf
And many more

As a .NET developer, learning MCP now positions you perfectly for the AI-integrated future. Whether you're building APIs, microservices, or AI-powered applications, MCP provides the standard interface that makes your .NET code accessible to AI agents.

Getting Started

Install the SDK: dotnet add package ModelContextProtocol --prerelease
Read the docs: Microsoft Learn - Get started with .NET AI and MCP
Explore examples: MCP C# SDK samples
Build your first server: Start with a simple echo tool and expand from there

The MCP revolution is happening now. Are you ready to join it?

Connect with me on LinkedIn: https://www.linkedin.com/in/vikrant-bagal

Stop putting business logic in your integration layer — here's the pattern we built

Thiago Paz — Fri, 15 May 2026 18:24:51 +0000

TL;DR — We had business logic scattered across an integration service. Debugging was painful, onboarding was slow, and every new flow was a gamble. We fixed it by moving all orchestration into our platform via a standardized job pattern. This post walks through the architecture, the full end-to-end flow, and a copy-paste recipe for creating new jobs.

The problem nobody wants to admit

You know the feeling. You open a service called ExternalApi expecting to find... API calls. Instead you find business rules, conditional flows, client-specific logic, and three years of "temporary" fixes.

That was us.

Every integration with our external system was its own snowflake. Different conventions, different error handling, different logging strategies — or no logging at all. Onboarding a new developer meant a two-hour walkthrough just to explain why a single job worked the way it did.

We needed to fix this. Not with a rewrite — with a pattern.

The principle: your platform owns the rules

The core decision was simple but had big consequences:

The integration service handles transport. Our platform owns the business logic.

This means:

The external service calls an endpoint and gets back a result
All orchestration, validation, rule application, and logging lives in our platform
The integration job becomes a dumb but reliable pipe

With this shift, every new integration follows the same skeleton. The domain knowledge stays where it belongs — inside the product.

Architecture overview

Here's how the layers map out:

Scheduler / Orchestrator
        │
        ▼
JobsController              ← route + auth (query key)
        │
        ▼
ClientUpdateApp             ← orchestration + business rules
        │
        ├── JobConfiguracao      ← job config per client (JSON)
        │
        ├── ExternalSystemApi    ← external data fetch + ack
        │
        └── Domain (Workflow, Scheduling, Notifications)

Each layer has a single responsibility. The controller authenticates and delegates. The app orchestrates and applies rules. The infra layer talks to the outside world.

The full flow: `JobSyncCompletedRecords`

Let's walk through a real job. This one syncs completed records from the external system back into our platform.

Endpoint

GET /api/Jobs/JobSyncCompletedRecords?key=<job-key>

Response	When
`200 OK`	Job completed successfully
`401 Unauthorized`	Invalid or missing key
`500 Internal Server Error`	Unhandled exception (logged automatically)

Step by step

1. Scheduler fires the route

An external scheduler (cron, Azure Timer, whatever fits your stack) calls the endpoint. No payload needed — configuration lives in the database.

2. Controller validates and delegates

[HttpGet]
[Route("JobSyncCompletedRecords")]
public async Task<HttpResponseMessage> JobSyncCompletedRecords(string key)
{
    return await ExecuteJobWithKeyAsync(
        key,
        () => _clientUpdateApp.JobSyncCompletedRecordsAsync(),
        "Records synced successfully"
    );
}

ExecuteJobWithKeyAsync is a shared helper that handles key validation, wraps execution in try/catch, and returns the appropriate HTTP response. Every job uses it — zero boilerplate per route.

3. App loads configuration

public async Task JobSyncCompletedRecordsAsync()
{
    await ExecuteJobPerClientAsync(
        JobTypeEnum.SyncCompletedRecords,
        ProcessCompletedRecordsAsync
    );
}

ExecuteJobPerClientAsync fetches the job config from APP_JOB_CONFIG by job type, deserializes the client list from the Configuration JSON field, and calls the action for each client.

4. Per-client processing (parallel, bounded)

private async Task ProcessCompletedRecordsAsync(ClientJobConfigDTO item)
{
    try
    {
        // 1. Fetch completed records from external system
        var records = await _externalApi.GetCompletedRecordsAsync(
            item.ClientId, item.GroupId, item.Route, item.Script
        );

        // 2. Process in parallel (max 6 concurrent)
        await Parallel.ForEachAsync(records, new ParallelOptions { MaxDegreeOfParallelism = 6 },
            async (record, _) =>
            {
                await UpdateRecordStatusAsync(record);
                await RegisterWorkflowTriggerAsync(record, "COMPLETED");
                await ClearPendingItemsAsync(record);
            });

        // 3. Acknowledge back to external system
        await _externalApi.AcknowledgeRecordsAsync(records, item);

        // 4. Persist execution log
        await _requestLogApp.SaveAsync(item, records.Count);
    }
    catch (Exception ex)
    {
        // Item-level error: log and continue — never abort the batch
        _appLogService.LogException(ex, new { item.ClientId, item.GroupId });
    }
}

Two things worth highlighting here:

Bounded parallelism: MaxDegreeOfParallelism = 6 prevents thread explosion on large client batches
Item-level resilience: a failure on one record is logged but never stops the rest of the batch

The configuration contract

Every job reads its client list from a single table:

Table: APP_JOB_CONFIG

Column	Description
`JobType`	Enum value identifying the job
`Route`	Endpoint path for external system calls
`Configuration`	JSON array of client configs
`CreatedByUserId`	Technical user for execution context

Configuration JSON structure:

[
  {
    "ClientId": 1,
    "GroupId": 10,
    "Route": "/api/records",
    "Script": "GET_COMPLETED",
    "Days": 7,
    "Year": 2025,
    "SendFrequency": 30
  }
]

This means enabling a new client is a database insert — no code change, no deploy.

The recipe: creating a new job in 8 steps

Follow this and you'll have a production-ready job in under two hours.

Step 1 — Add the enum value

public enum JobTypeEnum
{
    SyncCompletedRecords = 1,
    YourNewJob = 2  // 👈 add here
}

Step 2 — Expose the route

[HttpGet]
[Route("YourNewJob")]
public async Task<HttpResponseMessage> YourNewJob(string key)
{
    return await ExecuteJobWithKeyAsync(
        key,
        () => _clientUpdateApp.YourNewJobAsync(),
        "Job executed successfully"
    );
}

Step 3 — Create the entry method

public async Task YourNewJobAsync()
{
    await ExecuteJobPerClientAsync(
        JobTypeEnum.YourNewJob,
        ProcessYourNewJobAsync
    );
}

Step 4 — Implement the per-client action

private async Task ProcessYourNewJobAsync(ClientJobConfigDTO item)
{
    try
    {
        // 1. Fetch data from external system
        var data = await _externalApi.GetYourDataAsync(item);

        // 2. Apply business rules
        foreach (var record in data)
        {
            await ApplyBusinessRuleAsync(record);
        }

        // 3. Acknowledge back to external system
        await _externalApi.AcknowledgeAsync(data, item);

        // 4. Log the execution
        await _requestLogApp.SaveAsync(item, data.Count);
    }
    catch (Exception ex)
    {
        _appLogService.LogException(ex, new { item.ClientId, item.GroupId });
    }
}

Step 5 — Add external system integration methods

In ExternalSystemApi.cs, add the two methods: one for fetching (Get...) and one for acknowledging (Acknowledge...).

Step 6 — Insert the DB config

INSERT INTO APP_JOB_CONFIG (JobType, Route, Configuration, CreatedByUserId)
VALUES (
    2,
    '/api/Jobs/YourNewJob',
    '[{"ClientId": 1, "GroupId": 10}]',
    999
);

Step 7 — Observability is not optional

Your job must emit at minimum:

Entry log: job started, which type, timestamp
Per-item error log: client id, group id, item id, exception
Completion log: total received, total processed, total errors, duration

Without this, you're flying blind in production.

Step 8 — Rollout by config

Enable one pilot client. Monitor two full cycles. Validate with the functional team. Then expand. Never enable all clients at once on a first deploy.

The observability checklist

Metric	Why it matters
Records received per job/client	Detects external system issues early
Records processed successfully	Your primary success signal
Records with errors	Triggers alert if above threshold
Total job duration	Catches performance regressions
Average time per item	Diagnoses bottlenecks at scale

Alert rules we recommend:

🔴 3+ consecutive failures for the same client → page the team
🟡 Processed/received ratio below 95% → investigate before next cycle

The checklist before you ship

Technical

[ ] JobTypeEnum updated
[ ] Route created in JobsController
[ ] Interface + implementation in ClientUpdateApp
[ ] Per-item exception handling in place
[ ] External system fetch + ack methods added
[ ] APP_JOB_CONFIG record inserted
[ ] Request log and exception log covering success and error paths
[ ] Idempotency verified — no reprocessing on retry

Tests

[ ] Invalid key returns 401
[ ] Missing config doesn't crash execution
[ ] Empty record list completes with proper log
[ ] Single item error doesn't abort the batch
[ ] External system ack only fires for successfully processed items
[ ] Workflow trigger fires as expected

What we gained

After rolling this out across our first jobs:

A new developer can understand any job end-to-end in under 15 minutes
Adding a new client to an existing job is a single database insert
Debugging a production issue means checking one log table — not tracing across two services
Every new job starts from the same skeleton — zero architectural decisions at job creation time

That last one is underrated. Decision fatigue is real. When the pattern is clear, developers ship faster and make fewer mistakes.

What's next

We're looking at:

Moving the job key from a query param to a proper secret vault
Adding token-based service auth for the medium term
Building a lightweight dashboard to visualize job health across all clients in real time

If you've dealt with similar integration patterns — in health tech or elsewhere — I'd love to hear how you approached it. Drop a comment below.

I spent a year building Apache Camel for .NET. Here's the honest state of it.

rinat kozin — Fri, 15 May 2026 16:23:44 +0000

I've spent the last year building an integration ecosystem for .NET that I think fills a real gap. Three repos just went public. This post is the honest account — what it does, what it doesn't do yet, and three questions I genuinely don't know the answer to.

The gap

If you need Apache Camel in .NET, you don't have it.

MassTransit, Wolverine, NServiceBus are message buses — great at what they do, but they give you 4–7 transports and a Saga pattern. Apache Camel has 300+ components and 80+ EIP patterns as first-class DSL. But it's JVM.

There's no .NET project that gives you the full EIP catalogue —
Splitter, Aggregator, Content-Based Router, Recipient List, Dynamic Router,
Wiretap, Dead Letter Channel — as a fluent C# DSL with 20+ transports.

So I wrote one.

What I built

redb.Route — Camel-style fluent C# DSL. Apache 2.0.
github.com/redbase-app/redb-route

22 transports: Kafka, RabbitMQ, Redis, SQL polling, HTTP, gRPC, SFTP, MQTT,
S3, IBM MQ, AMQP 1.0, Azure Service Bus, Elasticsearch, LDAP, Mail, TCP,
WebSocket, SignalR, FTP, Quartz, File — plus 5 built-in (direct, seda, timer, log, mock).

30+ EIP processors as first-class DSL steps. Compiled expression engine:
${header.price} * 1.2 compiles to Func<IExchange, decimal> via
System.Linq.Expressions at route-build time. No interpreter at runtime.

redb.Tsak — runtime container for redb.Route modules. Apache 2.0.
github.com/redbase-app/redb-tsak

Drop a .dll or .tpkg (ZIP + manifest) into a folder. Tsak picks it up,
wires the DI container, starts the routes. Hot-reload — replace the file while
running, zero downtime. REST API + CLI + Blazor dashboard.

Cluster: leader election + auto-rebalance, no ZooKeeper/etcd/Consul.
Coordination lives entirely in EAV (row locks + SELECT FOR UPDATE CAS + epoch fencing).

Closest analogues are Apache Karaf and Camel K. Both JVM-only until now.

redb.Core — the storage layer underneath. Apache 2.0.
github.com/redbase-app/redb

EAV-style typed object store over Postgres / MSSQL with full LINQ. Schema is a
C# class with [RedbScheme]. Values live in typed columns with FK constraints —
not JSON blobs. SyncSchemeAsync<T>() at startup, no migration files.

[RedbScheme("Order")]
public class OrderProps
{
    public string  Status { get; set; } = "";
    public decimal Total  { get; set; }
}

// Inside a route pipeline:
.ProcessWithRedb("pg-main", async (redb, ex, ct) =>
{
    var id = await redb.SaveAsync(new RedbObject<OrderProps>
    {
        name  = $"Order-{DateTime.UtcNow:HHmmss}",
        Props = new() { Status = "new", Total = 299.99m }
    });
    ex.In.Headers["order-id"] = id;
})
.To("rabbitmq://processed");

Production state

Running at East-West / EWS — a 30-year-old national HoReCa
food distributor in Russia.

~150k orders/month, ~20k B2B customers, 600+ cities
3-node cluster (4 cores / 8 GB / 50 GB SSD per node)
~550 daily users, ~3 months stable, 10–15% CPU under full load
Routes integrate: SAP, Kafka, RabbitMQ, GPS feeds, Mercury / EGAIS / Chestny Znak / FGIS Grain (Russian regulatory systems)

43 NuGet packages, ~8.4k total downloads. Real but small.

What's honest

Bus factor of 1. I'm the solo author of the framework code. Publishing
to find early users and get harsh feedback.

Pro tier exists. Commercial license covers: compiled expression-tree-to-SQL,
parallel materialization, change-tracking diff, schema migrations.
Everything above — Route, Tsak, Core CRUD/LINQ/trees/security/export,
22 transports, hot-reload, cluster — is Apache 2.0 and stays free.

No third-party benchmarks yet. Internal Free-vs-Pro numbers at
redbase.app/results — treat as
"how editions compare on the same machine", not universal claims.

Architecture writeup: redbase.app/architecture

redb.Identity (near-complete, not yet public) — OAuth 2.0 / OIDC server
built on redb.Core. Authorization Code + PKCE, Client Credentials, Device Code,
Refresh Token, PAR, DPoP, backchannel logout, private_key_jwt. Apache 2.0.

Three questions I don't have the answer to

1. Is "another integration framework" the wrong framing?

The gap I described feels real to me — I lived with it for years before building
this. But maybe .NET teams that need Camel just use Camel via NativeAOT interop,
or have given up on the EIP model entirely. Curious what you've actually done.

2. Does "EAV" as a term kill the pitch?

redb.Core uses EAV — and that word triggers people (slow, untyped, joins
everywhere). The design is typed columns + FK constraints + 40+ indexes, not
JSON blobs. But maybe the term itself is a non-starter regardless of the
implementation. Has anyone successfully reframed EAV to a skeptical audience?

3. What makes a Pro/Free split feel fair vs bait-and-switch?

The free tier covers everything you need to build and run production pipelines.
Pro adds performance features (compiled SQL, parallel materialization) and ops
features (change tracking, migrations). Is that split legible from the outside,
or does "compiled queries are Pro" read as "the free tier is intentionally crippled"?

Links


redb.Route	github.com/redbase-app/redb-route
redb.Tsak	github.com/redbase-app/redb-tsak
redb.Core	github.com/redbase-app/redb
Architecture	redbase.app/architecture
Discussions	github.com/redbase-app/redb-route/discussions

Happy to answer technical questions in the comments.

PDFmyURL vs IronPDF: an unbiased look for .NET teams

IronSoftware — Fri, 15 May 2026 16:14:00 +0000

Picture a familiar architectural fork: a .NET service that generates compliance PDFs containing customer account data, transaction histories, and PII. A hosted HTML-to-PDF API like PDFmyURL is tempting — no install, one HTTP call, a PDF back. But the same call ships the document body across the public internet to a third-party processor, which immediately raises questions a security review will ask: where does the data land, who can audit it, and is there a DPA/BAA in place that the regulators will accept?

That fork shows up across industries with data residency or compliance constraints — healthcare (HIPAA), finance (SOX, PCI-DSS), government (FedRAMP), and EU GDPR scope generally. The question this article tries to answer is narrow: when does a cloud HTML-to-PDF API like PDFmyURL fit the use case, and when do you want a local-rendering library like IronPDF running inside your own process? Both are legitimate tools; the choice is about where the bytes are allowed to go.

Understanding IronPDF

IronPDF processes all PDF generation locally within your application's process space. HTML content, data, and generated PDFs never leave your infrastructure. The library embeds a Chromium rendering engine that executes entirely on your servers—whether on-premises Windows/Linux boxes, private cloud VMs, or containerized deployments. Network calls occur only when rendering URLs that your application explicitly requests, not as part of the library's operation.

This on-premises architecture addresses compliance requirements by default: data never transits to third parties, processing happens within your security boundary, and service availability depends only on your infrastructure. For applications with data governance requirements, this architectural difference often determines eligibility before any feature comparison begins. See the HTML to PDF tutorial for implementation patterns.

Key Limitations of PDFmyURL

Product Status

PDFmyURL has operated as a cloud conversion service since 2008, providing a stable REST API for HTML-to-PDF conversion. The service offers tiered subscription plans based on monthly conversion volume. API stability is good; breaking changes are rare.

Missing Capabilities

Data Sovereignty Compliance: Every HTML document you convert is transmitted to PDFmyURL's servers for processing. This creates compliance issues for:

GDPR (data transfer outside EU)
HIPAA (PHI transmission to third parties)
PCI-DSS (cardholder data handling)
SOX (financial data controls)
FedRAMP (government data restrictions)

Offline Operation: The service requires internet connectivity for every conversion. Air-gapped environments, private networks without external access, and scenarios requiring offline functionality cannot use cloud APIs.

Direct PDF Manipulation: PDFmyURL converts URLs/HTML to PDFs. It doesn't provide APIs for merging existing PDFs, extracting text, adding watermarks to pre-generated documents, or modifying PDFs programmatically. Each operation requires a separate tool.

Technical Issues

Network Dependency: Every conversion is an HTTP request to external servers. This introduces:

Network latency (roundtrip times)
Potential network failures (timeouts, connectivity issues)
Rate limiting (API quotas)
Service availability dependency (uptime outside your control)

Subscription Cost Model: Cloud services charge per conversion or monthly volume tiers. High-volume applications may encounter usage costs that scale with business success, creating unpredictable operational expenses.

Data Transfer Overhead: Large HTML documents with embedded images or complex layouts require uploading all content to remote servers. This consumes bandwidth and adds latency proportional to payload size.

Support Status

PDFmyURL provides email support and an API reference at https://pdfmyurl.com/html-to-pdf-api. Response time and SLA tiers vary by plan; check the current pricing/SLA page on the vendor site for specifics.

Architecture Problems

The cloud API model creates an architectural coupling where your application's PDF generation capability depends on:

External service availability
Network connectivity
API quota limits
Third-party infrastructure performance
Data transmission latency

For applications where PDF generation is a critical path operation (invoicing, reporting, document delivery), these dependencies introduce failure modes beyond your infrastructure control.

Feature Comparison Overview

Aspect	PDFmyURL	IronPDF
Current Status	Active (cloud SaaS)	Active (on-premises library)
HTML/CSS Support	Server-side rendering engine	Chromium-based engine
Rendering Output	Server-rendered HTML to PDF	Matches Chrome print preview
Installation	HTTP calls against pdfmyurl.com/api	NuGet package + first-run Chromium download (~150 MB)
Support	Email support, tier-dependent	Commercial support per IronPDF license
Operational Control	Depends on service availability	Runs inside your process

Code Comparison - Checklist Style

✅ Task: Convert HTML String to PDF

PDFmyURL Implementation:

using System;
using System.Collections.Generic;
using System.Net.Http;
using System.Threading.Tasks;

public class PdfMyUrlConverter
{
    private readonly HttpClient _httpClient;
    private readonly string _license;

    public PdfMyUrlConverter(string license)
    {
        _license = license;
        _httpClient = new HttpClient
        {
            Timeout = TimeSpan.FromMinutes(2)
        };
    }

    public async Task<byte[]> ConvertHtmlStringAsync(string htmlContent)
    {
        // Form-encoded POST against the single REST endpoint;
        // response body is the PDF binary.
        var form = new FormUrlEncodedContent(new[]
        {
            new KeyValuePair<string, string>("license", _license),
            new KeyValuePair<string, string>("html", htmlContent),
            new KeyValuePair<string, string>("page_size", "A4"),
            new KeyValuePair<string, string>("orientation", "portrait")
        });

        try
        {
            var response = await _httpClient.PostAsync("https://pdfmyurl.com/api", form);
            response.EnsureSuccessStatusCode();
            return await response.Content.ReadAsByteArrayAsync();
        }
        catch (HttpRequestException ex)
        {
            // HTTP-level failure: invalid license, rate limit, service unavailable, network error
            throw new InvalidOperationException(
                "PDFmyURL conversion failed - inspect status code / network", ex);
        }
        catch (TaskCanceledException)
        {
            throw new TimeoutException("PDF conversion exceeded HttpClient timeout");
        }
    }
}

Checklist - Trade-offs:

HTML payload is sent to PDFmyURL's servers for rendering — confirm acceptable under your data handling policy
Requires outbound HTTPS to pdfmyurl.com on every conversion
Per-call latency includes network round-trip plus server-side render time
Per-plan rate limits and monthly quotas apply; verify against the current tier on the vendor pricing page
HTTP-level errors surface as status codes and exception messages rather than typed render exceptions
Default HttpClient timeouts may need tuning for large payloads

IronPDF Implementation:

using IronPdf;
using System.Threading.Tasks;

public class LocalPdfGenerator
{
    private readonly ChromePdfRenderer _renderer;

    public LocalPdfGenerator()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";
        _renderer = new ChromePdfRenderer();
    }

    public async Task<byte[]> ConvertHtmlStringAsync(string htmlContent)
    {
        var pdf = await _renderer.RenderHtmlAsPdfAsync(htmlContent);
        return pdf.BinaryData;
    }
}

Checklist - Advantages:

✅ Data Privacy: All processing local, data never leaves infrastructure
✅ No Network Dependency: Works offline, air-gapped, private networks
✅ Low Latency: No network roundtrip overhead
✅ No Rate Limiting: Limited only by hardware resources
✅ Rich Error Handling: Detailed exceptions with stack traces
✅ Predictable Performance: Depends only on server hardware

✅ Task: Convert URL to PDF

PDFmyURL Implementation:

public async Task<byte[]> ConvertUrlAsync(string url)
{
    // PDFmyURL margin parameters: top/bottom/left/right + unit (mm/in/cm/pt/px)
    var form = new FormUrlEncodedContent(new[]
    {
        new KeyValuePair<string, string>("license", _license),
        new KeyValuePair<string, string>("url", url),
        new KeyValuePair<string, string>("page_size", "Letter"),
        new KeyValuePair<string, string>("top", "10"),
        new KeyValuePair<string, string>("bottom", "10"),
        new KeyValuePair<string, string>("unit", "mm")
    });

    var response = await _httpClient.PostAsync("https://pdfmyurl.com/api", form);
    response.EnsureSuccessStatusCode();
    return await response.Content.ReadAsByteArrayAsync();
}

Checklist - Considerations:

The fetch goes your server → PDFmyURL → target URL, so the target URL must be reachable from PDFmyURL's network
Authenticated URLs typically need cookies or headers passed as API parameters — verify what the PDFmyURL parameter set supports for your tier
Intranet, localhost, and VPN-only URLs are not reachable from a public cloud renderer
JavaScript wait timing is controlled by the javascript_time parameter rather than by event hooks

IronPDF Implementation:

public async Task<byte[]> ConvertUrlAsync(string url)
{
    var pdf = await _renderer.RenderUrlAsPdfAsync(url);
    return pdf.BinaryData;
}

public async Task<byte[]> ConvertAuthenticatedUrlAsync(string url, string cookieHeader)
{
    _renderer.RenderingOptions.CustomCssUrl = "https://yourcdn.com/print.css";
    _renderer.RenderingOptions.CustomHttpHeaders.Add("Cookie", cookieHeader);

    var pdf = await _renderer.RenderUrlAsPdfAsync(url);
    return pdf.BinaryData;
}

Checklist - Advantages:

✅ Single Network Hop: Direct fetch from your server to target URL
✅ Full Authentication Control: Pass cookies, headers, certificates programmatically
✅ Private URLs: Can convert localhost, intranet, VPN-protected URLs
✅ JavaScript Control: Configurable JS execution, wait conditions

✅ Task: Batch Convert Multiple HTMLs

PDFmyURL Implementation:

public async Task<byte[][]> BatchConvertAsync(string[] htmlContents)
{
    var tasks = new List<Task<byte[]>>();

    foreach (var html in htmlContents)
    {
        // Each conversion is a separate API call
        tasks.Add(ConvertHtmlStringAsync(html));
    }

    // All requests go to external service
    return await Task.WhenAll(tasks);
}

Checklist - Batch Considerations:

Each call counts against the plan's monthly quota and per-tier concurrency limits
Multiple large HTML payloads consume outbound bandwidth on every batch
Cost scales linearly with batch size on metered tiers
A single slow render does not block siblings, but overall throughput is bounded by the service

IronPDF Implementation:

public async Task<byte[]> BatchConvertAndMergeAsync(string[] htmlContents)
{
    // Process all in parallel on local hardware
    var tasks = htmlContents.Select(html => 
        _renderer.RenderHtmlAsPdfAsync(html));

    var pdfs = await Task.WhenAll(tasks);

    // Merge into single PDF
    var merged = PdfDocument.Merge(pdfs);
    return merged.BinaryData;
}

Checklist - Advantages:

✅ No Rate Limits: Parallelism limited only by CPU/memory
✅ No Network Overhead: All processing local
✅ No Cost Scaling: Process millions without per-unit charges
✅ Built-in Merge: Combine results without additional tools

✅ Task: Add Watermarks to Generated PDFs

PDFmyURL Implementation:

public async Task<byte[]> ConvertWithWatermarkAsync(string htmlContent, string watermarkText)
{
    // Watermark behavior is controlled via API parameters on the same /api endpoint.
    // Check the live API reference at https://pdfmyurl.com/html-to-pdf-api for the
    // current parameter set and any tier-related availability.
    var form = new FormUrlEncodedContent(new[]
    {
        new KeyValuePair<string, string>("license", _license),
        new KeyValuePair<string, string>("html", htmlContent),
        new KeyValuePair<string, string>("watermark_text", watermarkText),
        new KeyValuePair<string, string>("watermark_style", "diagonal")
    });

    var response = await _httpClient.PostAsync("https://pdfmyurl.com/api", form);
    response.EnsureSuccessStatusCode();
    return await response.Content.ReadAsByteArrayAsync();
}

Checklist - Watermark Considerations:

Confirm watermark parameter support and tier availability against the current API reference
Text, position, and opacity are controlled via parameters; check the documented ranges
Image-watermark support depends on the parameter set exposed by the service
The /api endpoint converts source HTML/URL to PDF; modifying an existing PDF is not part of the conversion endpoint

IronPDF Implementation:

public async Task<byte[]> ConvertWithWatermarkAsync(string htmlContent, string watermarkText)
{
    var pdf = await _renderer.RenderHtmlAsPdfAsync(htmlContent);

    // Add text watermark to all pages
    pdf.ApplyWatermark("<h1>" + watermarkText + "</h1>", 
        opacity: 50, 
        rotation: 45, 
        verticalAlignment: IronPdf.Editing.VerticalAlignment.Middle);

    return pdf.BinaryData;
}

public async Task<byte[]> AddImageWatermarkAsync(byte[] existingPdfBytes, string imagePath)
{
    var pdf = PdfDocument.FromBinaryData(existingPdfBytes);

    // Image watermark
    pdf.ApplyImageWatermark(imagePath,
        opacity: 30,
        verticalOffset: -100);

    return pdf.BinaryData;
}

Checklist - Advantages:

✅ Full Customization: Text, images, HTML watermarks
✅ Post-Processing: Add watermarks to any existing PDF
✅ Precise Control: Position, opacity, rotation, per-page options
✅ No API Tiers: All features available in library

✅ Task: Handle Sensitive Financial Data

Cloud API model (PDFmyURL) — questions to answer with your compliance team:

Does the conversion involve PII / PHI / cardholder data leaving your security boundary?
What processing jurisdiction is documented in the vendor's DPA?
Are data residency guarantees offered at the tier you would purchase?
Is a BAA or equivalent contractual instrument available for your regulator?
Where is the audit trail stored, and how long is it retained?
What is the documented data deletion / retention SLA?

If any of those questions does not have an acceptable answer for your data class, the cloud-API path is likely off the table regardless of feature parity — that is an organizational call, not a technical one.

On-premises library model (IronPDF) — what changes:

Processing happens inside your application's process; HTML and generated PDFs stay on your infrastructure
Processing jurisdiction equals wherever you deploy the host
Data residency is whatever your hosting choice is
No third-party data sharing introduced by the PDF step itself
Audit trail and retention are under your control
Data deletion is governed by your own storage policy

For detailed HTML rendering and security options, see the HTML string to PDF guide.

API Mapping Reference

PDFmyURL Concept	IronPDF Equivalent	Notes
HTTP POST to /api	ChromePdfRenderer methods	REST API vs. library calls
license parameter	IronPdf.License.LicenseKey	One-time setup vs. per-request
html parameter	RenderHtmlAsPdf(string)	String content directly
url parameter	RenderUrlAsPdf(string)	Same concept
page_size parameter	RenderingOptions.PaperSize	Enum vs. string
orientation parameter	RenderingOptions.PaperOrientation	Typed property
top/bottom/left/right + unit	RenderingOptions.MarginTop etc. (mm)	Margins are typed numeric properties in IronPDF
HTTP response body	PdfDocument.BinaryData	Bytes returned directly
API quota limits	Hardware limitations	No artificial throttling
Subscription tiers	License types	Per-deployment vs. per-use
Network timeout	Local processing time	No network overhead
Service uptime	Application uptime	Same availability tier

Comprehensive Feature Comparison

Feature	PDFmyURL	IronPDF
Architecture
Processing location	Cloud (third-party servers)	On-premises (your infrastructure)
Data transmission	All content to external service	Local only
Network requirement	Required for every conversion	Optional (for URL fetching)
Offline operation	No	Yes
Compliance
Data sovereignty	Data leaves boundary	Data stays local
GDPR compliance	Complex (data transfer)	Straightforward (no transfer)
HIPAA compliance	Requires BAA (if available)	Native (on-premises)
Air-gapped deployment	Not supported	Fully supported
HTML Conversion
HTML string to PDF	Yes	Yes
URL to PDF	Yes	Yes
HTML file to PDF	Via upload	Yes (direct file access)
Modern CSS support	Server-side rendering (W3C compliant per vendor docs)	Chromium-based engine
JavaScript execution	Yes (`javascript_time` wait param)	Yes (configurable render delay)
PDF Operations
Merge PDFs	Not part of the conversion endpoint	Yes (`PdfDocument.Merge`)
Split PDFs	Not part of the conversion endpoint	Yes
Extract text	Not part of the conversion endpoint	Yes
Watermarks	Via API parameters; verify tier availability	Built-in (`ApplyWatermark`)
Digital signatures	Not part of the conversion endpoint	Yes (`PdfSignature`)
Performance
Latency	Network RT + processing	Processing only
Batch processing	API rate limits	Hardware limits
Concurrent operations	Depends on tier/quota	Depends on resources
Caching	Vendor-side caching not documented as a guarantee	Application-controlled
Development
.NET integration	HttpClient/WebClient against `/api`; optional `PDFmyURL.NET.dll`	Native NuGet package (`IronPdf`)
Async support	`HttpClient.PostAsync`	Sync and async (`RenderHtmlAsPdfAsync` etc.)
Error handling	HTTP status codes / `WebException` / `HttpRequestException`	Typed exceptions (`IronPdfRenderingException`, etc.)
Type safety	Stringly-typed form parameters	Strongly typed `RenderingOptions`
Operational
Cost model	Monthly subscription tiers	Per-license (perpetual option available)
Scaling	Bounded by plan tier and vendor capacity	Bounded by your own hardware
Service dependency	External SaaS on the critical path	Runs in your process
Support	Email, tier-dependent	Commercial support per IronPDF license

Installation Comparison

PDFmyURL Setup:

# Option 1: Use HttpClient directly
dotnet add package System.Net.Http

# Option 2: Use official wrapper (if available)
# Download PDFmyURL.NET.dll from vendor site

using System.Net.Http;

var client = new HttpClient();
// Make REST API calls with API key

IronPDF Setup:

dotnet add package IronPdf

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Hello</h1>");

Deployment Checklist Comparison

PDFmyURL Deployment Checklist:

[ ] Verify API key is configured securely
[ ] Ensure outbound HTTPS connectivity to pdfmyurl.com
[ ] Configure HTTP client timeouts appropriately
[ ] Implement retry logic for network failures
[ ] Monitor API quota usage
[ ] Review data transmission policies with legal/compliance
[ ] Test network latency from production environment
[ ] Plan for service outages (fallback strategy?)
[ ] Evaluate costs at expected volume
[ ] Confirm acceptable use policy compliance

IronPDF Deployment Checklist:

[ ] Install NuGet package
[ ] Set license key in application startup
[ ] Ensure sufficient disk space (~200MB for library)
[ ] Verify .NET version compatibility
[ ] Configure memory limits for high-volume scenarios
[ ] Test on target OS (Windows/Linux/macOS)
Configure custom Chrome executable path
Set up load balancing if needed

When to Stay with PDFmyURL / When IronPDF is Better

Consider staying with PDFmyURL if:

You have zero infrastructure and want someone else to manage PDF generation
Your HTML content contains no sensitive or regulated data
Conversion volume is low and occasional (not business-critical)
Offline operation is never required
Data sovereignty is not a concern
Network latency is acceptable for your use case
You prefer operational costs over capital expenses

IronPDF becomes necessary when:

Data contains PII, PHI, financial data, or regulated information
Compliance requires on-premises processing (GDPR, HIPAA, SOX, FedRAMP)
Air-gapped or private network deployment
PDF generation is business-critical (cannot depend on external service)
High-volume conversion where per-use costs become prohibitive
Low-latency requirements (milliseconds matter)
Offline or occasionally-connected scenarios
Need full PDF manipulation (merge, split, extract, modify existing PDFs)
Want architectural control over PDF generation infrastructure

Conclusion

PDFmyURL is a straightforward cloud API for HTML-to-PDF conversion that removes infrastructure management for teams comfortable sending document content to an external processor. For public content, marketing materials, or non-sensitive document generation, the model is a real deployment shortcut: no libraries to install, no servers to maintain, just HTTP calls that return PDFs. It typically works well in low-volume scenarios where data sensitivity is low and outbound network dependency is acceptable.

The architectural fit changes when the application handles regulated data or needs to be operationally independent. A cloud API by definition transmits the source document to a third party, which can be incompatible with HIPAA, PCI-DSS, or GDPR scope unless the right DPA/BAA is in place. Even outside regulated workloads, the external dependency means your PDF step shares an availability budget with another company's service.

IronPDF takes the opposite trade-off: rendering happens inside your own process, so the source HTML and the generated PDF stay within your security boundary. The library bundles a Chromium engine, runs locally on Windows/Linux/macOS, and removes the network from the conversion path itself. For applications where PDF generation is on the critical path rather than an occasional feature, local rendering keeps that step under your own SLAs.

For teams evaluating cloud vs. on-premises: Have data privacy regulations or service dependency concerns already eliminated cloud API options from consideration, or does your architecture permit external processing with appropriate contractual safeguards?

Related resources:

HTML to PDF Tutorial - Complete guide to on-premises HTML rendering
ChromePdfRenderer API Documentation - Detailed method reference for local processing

A .NET Dinosaur in Web3. Day 6 - Wishlist or… “Dream Coins True”?

Alena — Fri, 15 May 2026 15:07:18 +0000

There's something that happened between Day 5 and Day 6 during brainstorming about project ideas. Day 6 wasn't just a deploy session — it was the first day of building something real.

Intro

Brainstorming started as a strategy question — I needed a practice project. Something to learn the full modern Web3 stack and something I could build in public.

I already have another idea that I've started building, but until the MVP is ready — I decided to keep it under wraps.

The idea was simple: pick something "common", but complex enough to cover real technical ground.

Well… I'm a dreamer. So the wishlist idea just felt right.

I started thinking — is it possible to build something interesting around it? Maybe the idea isn't new. It doesn't really matter… I just like it.

Take a wishlist, let people make each other's dreams come true and… maybe build something on-chain around it.

The base Wishlist contract was already written. It was already there — a working smart contract with a React frontend deployed on Sepolia.

So why not just build something on top of it?

Multi-user goals, ETH donations for specific goals, a Telegram bot for notifications. A proper monorepo with contract, Supabase, Drizzle, Next.js, and more.

And then the idea shifted.

What if every donation increases the "strength" of something?

A global counter. An on-chain kind of energy. A number that grows every time someone believes in someone else's dream enough to send ETH.

The working name became WishList Chain (WSHL) — not a token, at least not yet. An on-chain power score. totalDreamPower in the contract. Every donation adds to it. Every goal has its own dream power.

(DreamCoin, the name I originally wanted, is apparently already taken — so I had to rethink pretty quickly.)

Is it a real product? Possibly. Is it a learning project? Definitely. Is the idea somewhat ridiculous? Yes, and that's exactly why it might work in crypto.

The project is at github.com/alena-dev-soft/wish-list-chain — open source.

Day 6 was about laying the foundation for all of it.

The Goal

Write the core contract for WishList Chain — version 3 of the original Wishlist.sol.

Multi-user goals, ETH donations, dreamPower accumulation per goal, totalDreamPower globally, and a DreamPowerIncreased event for future Alchemy webhooks. Deploy with Hardhat. Verify on Etherscan.

The Contract

WishlistV3 is a different architecture from V2. V2 was one owner, one wishlist. V3 is a shared contract where every wallet has its own goals.

The .NET analogy:

// V2
List<WishItem> wishes;

// V3
Dictionary<address, List<Goal>> goals;

In Solidity: mapping(address => Goal[]) public goals

struct Goal gained financial fields:

struct Goal {
    string name;
    uint256 targetAmount;
    uint256 currentAmount;
    uint256 dreamPower;
    bool isFulfilled;
    uint256 createdAt;
}

donate() is the core function. Two things worth noting:

It must be payable — without that modifier, Solidity won't accept ETH. The keyword is required, not optional.

Goal storage goal = goals[_owner][_goalIndex] — storage means you're working with the actual on-chain data, not a copy. Change it, and the state changes. Use memory instead, and you're editing a local copy that disappears after the function returns. This distinction doesn't exist in .NET — it's specific to the EVM execution model.

The event:

event DreamPowerIncreased(
    address indexed owner,
    uint256 indexed goalIndex,
    uint256 addedPower,
    uint256 newTotalPower
);

indexed parameters are searchable in logs. They become filter keys — Alchemy webhooks can listen for specific owners or goal indices without scanning every event. The non-indexed parameters are just data payload.

Hardhat

Moving from Remix to Hardhat is the next step in my Web3 journey. Remix is a great tool for exploration. Hardhat provides everything needed out of the box, including a proper build pipeline.

The setup that actually works with Hardhat 3 + viem:

npm install --save-dev hardhat@latest @nomicfoundation/hardhat-toolbox-viem@latest

I really like this part — deploy and verify in one command:

npx hardhat ignition deploy ignition/modules/WishlistV3.ts --network sepolia --verify

Fair warning: getting there involved the usual package dependency hell — wrong versions, renamed config keys, cached artifacts. Nothing mysterious, just the standard tax you pay any time you touch a stack that lives and dies by npm. Read the error codes, fix one thing at a time.

The Project

WishlistV3 is not just a learning exercise. It's the core contract for something that's being built. The donate() function, the DreamPowerIncreased event, the multi-user architecture — all of it is designed for a real use case that will be revealed when the MVP is ready.

Two-week sprint. This was the foundation.

Contract address: 0x90de4a1934d0B062423adAEeDEe37Bb6fD12D0Ca

Verified: sepolia.etherscan.io/address/0x90de4a1934d0B062423adAEeDEe37Bb6fD12D0Ca

Stage: Dinosaur 🦕 — dependency hell survived. Foundation is live.

Gnostice PDFOne .NET vs IronPDF: side by side for .NET

IronSoftware — Fri, 15 May 2026 13:13:00 +0000

The legacy PDFOne.NET NuGet package is now marked deprecated (last release 24.1.60, July 1, 2024), and Gnostice now directs new work to the Gnostice.DocumentStudio.* package family. For teams currently on PDFOne .NET, this is a natural inflection point — a Gnostice-to-Gnostice move to Document Studio is itself a migration, so it is worth re-evaluating the broader PDF library landscape at the same time. PDFOne .NET served as a coordinate-based PDF creation and manipulation library — teams built documents by specifying exact positions, drawing text blocks, and manually calculating layouts.

IronPDF takes a fundamentally different approach: HTML and CSS define document structure, with a Chrome rendering engine handling layout calculations automatically. This architectural distinction affects development velocity, maintenance overhead, and the types of documents each library handles efficiently. The comparison below focuses on measurable characteristics—API surface area, code volume, and workflow patterns—that impact project timelines and long-term maintainability.

Understanding IronPDF

IronPDF centers on HTML-to-PDF conversion using an integrated Chromium rendering engine. Development teams leverage existing HTML, CSS, and JavaScript skills rather than learning PDF coordinate systems. The library supports modern web standards: CSS Grid, Flexbox, custom fonts, responsive layouts, and JavaScript execution before rendering.

Beyond HTML rendering, IronPDF provides standard PDF operations through a streamlined API: merging documents, splitting files, extracting text/images, form handling, digital signatures, and encryption. The library targets .NET Framework 4.6.2+, .NET Core 3.1+, and .NET 6-10 with consistent cross-platform behavior. For comprehensive rendering options, see HTML to PDF Conversion Tutorial.

Architectural Constraints of Gnostice PDFOne .NET

Product Status

PDFOne .NET is now in legacy maintenance — the PDFOne.NET NuGet package's last release is 24.1.60 (July 1, 2024), and the vendor recommends Gnostice.DocumentStudio.* packages for new work. Existing PDFOne .NET licenses remain functional, but teams may want to verify what feature updates and .NET version coverage are planned against the vendor's current roadmap before starting new projects on it.

Missing Capabilities

PDFOne .NET does not ship native HTML-to-PDF conversion. Document generation requires manual coordinate calculations for every text block, image, and shape. Teams build custom layout helpers or accept rigid, code-heavy document structures. Dynamic content from databases or user input means recalculating positions programmatically.

Technical Trade-offs

Coordinate-based APIs make layout changes propagate. Adding a single line of text to a header typically means adjusting Y-coordinates for every subsequent element. Multi-column layouts, tables with dynamic row counts, and page breaks across long content are application-level concerns. Text wrapping, font metrics, and overflow handling sit with the developer.

Support Status

With PDFOne .NET in legacy maintenance, Gnostice support traffic increasingly points new customers toward Document Studio .NET. Teams maintaining PDFOne .NET applications should plan for an eventual Gnostice-to-Document-Studio or Gnostice-to-alternative move.

Architecture

The library's design reflects pre-HTML5 document generation patterns. PDF coordinates originate from bottom-left corners (PostScript convention), which can create cognitive overhead for developers more familiar with top-left origin systems. There is no CSS styling, no responsive breakpoint model, and no separation of content from presentation — every document change is a code change.

Feature Comparison Overview

Feature	Gnostice PDFOne .NET	IronPDF
Current Status	Legacy (PDFOne.NET deprecated; last release 24.1.60, Jul 2024)	Active with continuous updates
HTML Support	None natively	Chromium-based rendering engine
Layout Model	Manual coordinate drawing	CSS-driven layout
Installation	`PDFOne.NET` NuGet (deprecated)	`IronPdf` NuGet
Support	Vendor redirects new work to Document Studio .NET	Live chat, email, tickets
Successor Path	`Gnostice.DocumentStudio.*` packages	Continues as `IronPdf`

Code Comparison: Efficiency Metrics

The following sections compare document generation workflows, measuring code verbosity, maintenance overhead, and adaptability to requirement changes.

Gnostice PDFOne .NET — Creating a Simple Invoice

// NuGet: Install-Package PDFOne.NET (deprecated)
using Gnostice.PDFOne;
using Gnostice.PDFOne.Graphics;
using System;
using System.Drawing;

public class PdfOneInvoiceGenerator
{
    public static void CreateInvoice()
    {
        try
        {
            // Initialize PDF document
            PDFDocument document = new PDFDocument();
            document.Open();
            PDFPage page = document.Pages.Add();

            // Font objects per text style
            PDFFont titleFont = new PDFFont(PDFStandardFont.Helvetica, 24);
            PDFFont bodyFont = new PDFFont(PDFStandardFont.Helvetica, 12);
            PDFFont boldFont = new PDFFont(PDFStandardFont.Helvetica, 14);

            // Manual coordinate calculations (origin: bottom-left)
            // Page height is ~792 points (11 inches at 72 DPI)
            double yPosition = 750; // Start near top

            // Helper: build and draw a text element at (x, y)
            void Draw(string text, PDFFont font, double x, double y)
            {
                var element = new PDFTextElement
                {
                    Text = text,
                    Font = font,
                    Color = Color.Black
                };
                element.Draw(page, x, y);
            }

            Draw("Invoice #12345", titleFont, 50, yPosition);
            yPosition -= 30;

            Draw($"Date: {DateTime.Now:yyyy-MM-dd}", bodyFont, 50, yPosition);
            yPosition -= 20;

            Draw("Customer: Acme Corporation", bodyFont, 50, yPosition);
            yPosition -= 20;
            Draw("Address: 123 Business St", bodyFont, 50, yPosition);
            yPosition -= 40;

            // Table header (manual column tracking)
            Draw("Item", bodyFont, 50, yPosition);
            Draw("Quantity", bodyFont, 250, yPosition);
            Draw("Price", bodyFont, 350, yPosition);
            Draw("Total", bodyFont, 450, yPosition);
            yPosition -= 20;

            // Line items — each requires manual positioning
            Draw("Professional Services", bodyFont, 50, yPosition);
            Draw("40", bodyFont, 250, yPosition);
            Draw("$150.00", bodyFont, 350, yPosition);
            Draw("$6,000.00", bodyFont, 450, yPosition);
            yPosition -= 20;

            Draw("Consulting", bodyFont, 50, yPosition);
            Draw("10", bodyFont, 250, yPosition);
            Draw("$200.00", bodyFont, 350, yPosition);
            Draw("$2,000.00", bodyFont, 450, yPosition);
            yPosition -= 30;

            // Total
            Draw("Total: $8,000.00", boldFont, 350, yPosition);

            // Save document
            document.Save("invoice_pdfone.pdf");
            document.Close();
            Console.WriteLine("Invoice created: invoice_pdfone.pdf");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Error: {ex.Message}");
        }
    }
}

Performance & Maintainability Metrics:

Lines of code: 64 lines for basic invoice
Manual Y-coordinate calculations: 12 explicit position updates
Font objects created: 4 instances requiring disposal
Table column alignment: Manual calculation for each column
Adding one new line item: Adjust 8+ subsequent Y-coordinates
Responsive layout support: None (fixed positions)
Change request impact: High (coordinate cascade effect)

Technical limitations:

No text wrapping—long strings overflow page boundaries
No automatic page breaks for multi-page documents
Font size changes require recalculating all subsequent positions
Dynamic table row counts need complex loop logic with position tracking
RTL languages (Arabic, Hebrew) require custom text rendering
No CSS styling or separation of content from presentation

IronPDF — Creating a Simple Invoice

using IronPdf;
using System;

public class IronPdfInvoiceGenerator
{
    public static void CreateInvoice()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        var renderer = new ChromePdfRenderer();

        var htmlContent = $@"
        <!DOCTYPE html>
        <html>
        <head>
            <style>
                body {{ font-family: Arial; padding: 40px; }}
                h1 {{ font-size: 24px; margin-bottom: 20px; }}
                .info {{ margin: 10px 0; font-size: 12px; }}
                table {{ width: 100%; border-collapse: collapse; margin-top: 30px; }}
                th {{ background: #f0f0f0; padding: 10px; border-bottom: 2px solid #000; text-align: left; }}
                td {{ padding: 10px; border-bottom: 1px solid #ddd; }}
                .total {{ font-size: 14px; font-weight: bold; margin-top: 20px; text-align: right; }}
            </style>
        </head>
        <body>
            <h1>Invoice #12345</h1>
            <div class='info'>Date: {DateTime.Now:yyyy-MM-dd}</div>
            <div class='info'>Customer: Acme Corporation</div>
            <div class='info'>Address: 123 Business St</div>

            <table>
                <thead>
                    <tr>
                        <th>Item</th>
                        <th>Quantity</th>
                        <th>Price</th>
                        <th>Total</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td>Professional Services</td>
                        <td>40</td>
                        <td>$150.00</td>
                        <td>$6,000.00</td>
                    </tr>
                    <tr>
                        <td>Consulting</td>
                        <td>10</td>
                        <td>$200.00</td>
                        <td>$2,000.00</td>
                    </tr>
                </tbody>
            </table>

            <div class='total'>Total: $8,000.00</div>
        </body>
        </html>";

        var pdf = renderer.RenderHtmlAsPdf(htmlContent);
        pdf.SaveAs("invoice_ironpdf.pdf");

        Console.WriteLine("Invoice created: invoice_ironpdf.pdf");
    }
}

Performance & Maintainability Metrics:

Lines of code: 42 lines for same invoice (34% less code)
Manual coordinate calculations: 0 (CSS handles layout)
Font management: Automatic via CSS
Table rendering: Native HTML <table> with automatic alignment
Adding one new line item: Insert single <tr> element (no position recalculation)
Responsive layout: Built-in CSS media queries and flexible layouts
Change request impact: Low (modify HTML/CSS independently of logic)

For production templates with Razor views or external CSS files, see CSHTML to PDF Tutorial.

Gnostice PDFOne .NET — Merging PDFs with Form Preservation

// NuGet: Install-Package PDFOne.NET (deprecated)
using Gnostice.PDFOne;
using Gnostice.PDFOne.Document;
using System;

public class PdfOneMerger
{
    public static void MergePdfsWithForms()
    {
        try
        {
            // Load source documents
            PDFDocument doc1 = new PDFDocument();
            doc1.Load("form_part1.pdf");

            PDFDocument doc2 = new PDFDocument();
            doc2.Load("form_part2.pdf");

            // Create destination and append each source
            PDFDocument mergedDoc = new PDFDocument();
            mergedDoc.Open();
            mergedDoc.Append(doc1);
            mergedDoc.Append(doc2);

            mergedDoc.Save("merged_forms.pdf");

            // Explicit cleanup of each document
            doc1.Close();
            doc2.Close();
            mergedDoc.Close();

            Console.WriteLine("Merge completed");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Merge error: {ex.Message}");
        }
    }
}

Workflow notes:

Each source document is opened, appended, and closed explicitly
Form-field name collisions across the appended documents are the developer's responsibility to detect and rename — confirm against your AcroForm field set
Three PDFDocument instances need explicit Close() to release resources

IronPDF — Merging PDFs with Form Preservation

using IronPdf;
using System;
using System.Collections.Generic;

public class IronPdfMerger
{
    public static void MergePdfsWithForms()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        var docs = new List<PdfDocument>
        {
            PdfDocument.FromFile("form_part1.pdf"),
            PdfDocument.FromFile("form_part2.pdf")
        };

        var merged = PdfDocument.Merge(docs);
        merged.SaveAs("merged_forms.pdf");

        Console.WriteLine("Merge completed");
    }
}

Performance & Maintainability Metrics:

Automatic form field conflict resolution
Single method call handles all merge logic
Automatic resource management
Preserves bookmarks, annotations, and metadata

Gnostice PDFOne .NET — Extracting Text from Multi-Page Document

// NuGet: Install-Package PDFOne.NET (deprecated)
using Gnostice.PDFOne;
using Gnostice.PDFOne.Document;
using System;
using System.Text;

public class PdfOneTextExtractor
{
    public static void ExtractAllText()
    {
        try
        {
            PDFDocument document = new PDFDocument();
            document.Load("report.pdf");

            var extractedText = new StringBuilder();
            int pageCount = document.Pages.Count;

            // PDFOne page indices are typically 1-based
            for (int pageIndex = 1; pageIndex <= pageCount; pageIndex++)
            {
                string pageText = document.GetPageText(pageIndex);

                extractedText.AppendLine($"--- Page {pageIndex} ---");
                extractedText.AppendLine(pageText);
                extractedText.AppendLine();
            }

            System.IO.File.WriteAllText("extracted.txt", extractedText.ToString());

            document.Close();
            Console.WriteLine($"Extracted text from {pageCount} pages");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Extraction error: {ex.Message}");
        }
    }
}

Workflow notes:

Manual per-page iteration required to assemble the document text
Page indices are 1-based (vs. 0-based in IronPDF) — easy off-by-one when porting code
Column layouts and table structure are not preserved in the linear text output
Non-standard or embedded fonts can affect text decoding fidelity

IronPDF — Extracting Text from Multi-Page Document

using IronPdf;
using System;

public class IronPdfTextExtractor
{
    public static void ExtractAllText()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        var pdf = PdfDocument.FromFile("report.pdf");
        string allText = pdf.ExtractAllText();

        System.IO.File.WriteAllText("extracted.txt", allText);
        Console.WriteLine("Text extracted successfully");
    }
}

Performance Characteristics:

Single method handles all pages
Optimized memory usage for large documents
Maintains reading order across complex layouts
Built-in encoding normalization

For more details on PDF manipulation operations, see IronPDF PDF Creation Guide.

API Mapping Reference

Gnostice PDFOne Operation	IronPDF Equivalent
`new PDFDocument(); doc.Load(path)`	`PdfDocument.FromFile(path)`
`document.Pages.Add()`	HTML rendering creates pages automatically
`PDFTextElement.Draw(page, x, y)`	HTML elements and CSS styling
Manual coordinate calculations	CSS layout engine
`doc.Append(other)`	`PdfDocument.Merge(pdf1, pdf2)`
`doc.GetPageText(i)` (1-based)	`pdf.ExtractAllText()` / `pdf.ExtractTextFromPage(i)` (0-based)
Manual form field creation	`CreatePdfFormsFromHtml` option
`doc.Save(path); doc.Close()`	`pdf.SaveAs(path)`
Not available	`ChromePdfRenderer.RenderHtmlAsPdf()`
Not available	`ChromePdfRenderer.RenderUrlAsPdf()`
Not available	JavaScript execution before PDF generation
Not available	Responsive CSS rendering
`doc.SetEncryption(...)`	`pdf.SecuritySettings.UserPassword = "..."`

Comprehensive Feature Comparison

Status & Support

Feature	Gnostice PDFOne .NET	IronPDF
Current Development Status	Legacy maintenance (last NuGet release Jul 2024)	Active
Successor Product	`Gnostice.DocumentStudio.*` packages	N/A
.NET 6+ Support	Verify against vendor matrix	Yes
.NET Core Support	Yes (legacy)	Yes (.NET Core 3.1+)
.NET Framework Support	4.6.2+	4.6.2+
Official Documentation	Available; PDFOne section in maintenance	Comprehensive
Support Channels	Vendor redirects new work to Document Studio	Live chat, email, tickets
Future Updates	Direction is Document Studio .NET	Continuous delivery

Content Creation

Feature	Gnostice PDFOne .NET	IronPDF
HTML to PDF	Not supported	Native Chrome engine
Coordinate-Based Drawing	Primary method	Alternative API available
URL to PDF	Not supported	`RenderUrlAsPdf()`
Template-Based Generation	Manual code	HTML templates
Dynamic Content Layouts	Requires custom logic	CSS Flexbox, Grid
Text Wrapping	Manual calculation	Automatic
Multi-Column Layouts	Custom implementation	CSS columns or Grid
Responsive Design	Not supported	CSS media queries

PDF Operations

Feature	Gnostice PDFOne .NET	IronPDF
Merge PDFs	Yes (manual iteration)	Yes (single method)
Split PDFs	Yes	Yes
Extract Text	Yes (page-by-page)	Yes (optimized)
Extract Images	Yes	Yes
Form Field Creation	Yes (manual)	From HTML forms
Form Data Filling	Yes	Yes
Annotations	Yes	Yes
Digital Signatures	Yes	Yes
Encryption	Yes	Yes
Page Manipulation	Yes	Yes

Code Complexity Metrics

Metric	Gnostice PDFOne .NET	IronPDF
Basic Invoice (LOC)	64 lines	42 lines (34% reduction)
Coordinate Calculations	Manual (frequent)	None (CSS-based)
Font Management	Explicit creation	CSS declarations
Table Generation	Manual drawing	HTML `<table>`
Dynamic Content	Complex (position tracking)	Simple (data binding)
Maintenance Overhead	High (coordinate dependencies)	Low (declarative layouts)

Known Trade-offs

Product-Specific Considerations

Gnostice PDFOne .NET:

PDFOne.NET package is in legacy maintenance; new work is directed to Gnostice.DocumentStudio.*
Moving forward on Gnostice means migrating to Document Studio (a different API surface)
Coordinate-based API; layout changes propagate through subsequent positions
No native HTML rendering — text wrapping, overflow, and page breaks are application-level concerns
Font-metric handling sits with the developer for precise layouts
AcroForm field-name collisions during multi-document merges are the developer's responsibility to resolve

IronPDF:

Initial Chromium engine startup adds a one-time warm-up cost (amortized in long-running processes)
Linux deployments may require libgdiplus for certain image operations
Docker containers should be sized to accommodate the bundled Chromium

Installation Comparison

Gnostice PDFOne .NET Installation (Legacy)

# PDFOne.NET is deprecated on NuGet (last release 24.1.60, Jul 2024)
Install-Package PDFOne.NET

# Current Gnostice direction for new work:
# dotnet add package Gnostice.DocumentStudio.WinForms

Configuration:

using Gnostice.PDFOne;

// License key for PDFOne (set via the static PDFOne class)
Gnostice.PDFOne.PDFOne.LicenseKey = "YOUR-GNOSTICE-LICENSE";

Migration Notice:
Teams on PDFOne .NET should evaluate Document Studio .NET (Gnostice's current product line) or alternative PDF libraries for future projects.

IronPDF Installation

# NuGet Package Manager
Install-Package IronPdf

# .NET CLI
dotnet add package IronPdf

Configuration:

using IronPdf;

// Optional license configuration
IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

Performance Benchmark Summary

Based on common document generation scenarios:

Operation	PDFOne .NET (Coordinate-Based)	IronPDF (HTML-Based)
Simple invoice (3 items)	~64 LOC	~42 LOC
Complex report (50 items, tables)	~400+ LOC	~150 LOC
Development time (initial)	~8 hours	~3 hours
Change request (add field)	Adjust 10-20 coordinates	Modify HTML template
Multi-page document handling	Custom pagination logic	Automatic page breaks
Maintenance burden	High (coordinate cascade)	Low (CSS separation)

Note: Metrics based on typical development workflows. Actual performance varies by team experience and document complexity.

Conclusion

Gnostice PDFOne .NET served as a traditional PDF generation library, emphasizing precise control over document structure through coordinate-based APIs. For teams with specific requirements around low-level PDF manipulation or applications already on PDFOne, the library has provided reliable functionality. The PDFOne.NET package is now in legacy maintenance on NuGet, and Gnostice directs new development to the Gnostice.DocumentStudio.* product line.

The coordinate-based approach, while offering fine-grained control, comes with maintenance overhead. Layout changes typically require recalculating positions for subsequent elements. Complex tables, multi-column layouts, and responsive content demand custom logic that HTML/CSS engines handle automatically. Development time often goes into font metrics, text wrapping, and page-break logic — infrastructure concerns that modern rendering engines abstract away.

IronPDF's HTML-based approach can reduce code volume substantially for typical document generation tasks (the invoice example above is about a third shorter). Maintenance overhead drops further because HTML templates separate content from presentation. Adding a header, resizing a table, or changing fonts is a CSS change, not coordinate recalculations across the codebase. For teams building .NET applications where PDF generation is a feature rather than the core business, that architectural difference often translates to faster iteration and lower long-term maintenance costs.

With PDFOne .NET in legacy maintenance and Document Studio .NET representing a different API surface, teams already face a migration decision. IronPDF's HTML-first design aligns with the web skills most .NET teams already have, which can shorten the learning curve when evaluating alternatives.

What percentage of your PDF generation code involves manual positioning versus content definition? Share your experience with coordinate-based vs. template-based document workflows.

Related Resources:

PdfiumViewer vs IronPDF: a technical breakdown for 2026

IronSoftware — Fri, 15 May 2026 12:12:00 +0000

Viewer control or headless generation? It is one of the first architectural forks a .NET team hits when PDF requirements start expanding. PdfiumViewer is built for the first answer — a WinForms/WPF control that wraps Google's PDFium and renders pages to the screen, no browser dependency, native binaries shipped via separate NuGet packages. The moment the roadmap adds "generate invoices from data" or "produce reports server-side," that architecture stops carrying the workload, and a second library has to join the project — or replace it.

PdfiumViewer is a WinForms and WPF control for displaying PDF documents in desktop applications, built on Google's PDFium library (the same engine Chrome uses for PDFs). The original pvginkel/PdfiumViewer repository was archived on 2019-08-02 and the last NuGet release (2.13.0) shipped on 2017-11-06, so the library still works for the cases it was designed for but is not receiving updates from the original maintainer. Community forks such as bezzad/PdfiumViewer and PdfiumViewer.Updated continue some development for newer .NET targets — APIs and features can vary between forks. The library exposes a PdfRenderer control for low-level page rendering, a PdfViewer control with built-in toolbar, zoom, and navigation, plus page-level text extraction via PdfDocument.GetPdfText(int page). It does not generate PDFs from HTML, URLs, or templates — that is outside its scope.

Understanding IronPDF

IronPDF is a PDF generation and manipulation library, not a viewer control. The core workflow is creating PDFs from HTML using a Chromium rendering engine, so the output tracks what Chrome would print. IronPDF covers the document lifecycle: generate from HTML, URLs, or files; manipulate (merge, split, forms, signatures, encryption); extract content (text, images, metadata); and print to physical printers. It does not ship a WinForms/WPF viewer UI control — that is intentionally outside its scope. IronPDF runs on .NET Framework 4.6.2+, .NET Core 3.1+, and modern .NET releases, with cross-platform support for Windows, Linux, macOS, Docker, and common cloud environments. Installation is a single NuGet package with embedded native dependencies.

Key Limitations of PdfiumViewer

Product Status

Upstream archived: pvginkel/PdfiumViewer was marked read-only on 2019-08-02; last NuGet release (2.13.0) is from 2017-11-06
Community forks: multiple versions exist (bezzad/PdfiumViewer, PdfiumViewer.Updated, others) with different features and APIs
Windows-focused: original docs reference Windows XP through 8; modern OS coverage varies by fork

Missing Capabilities

No PDF generation from HTML, URLs, or templates
No server-side or headless document creation as a primary use case (the library is designed around UI controls)
No PDF manipulation beyond viewing (no merge, split, edit, watermarks)
No programmatic form filling or extraction
No digital signatures or encryption APIs
Text extraction is page-level only: PdfDocument.GetPdfText(int page) returns raw page text with no per-word coordinates, no layout reconstruction, and no OCR for image-only pages

Technical Considerations

Synchronous load and render: PdfDocument.Load and Render run on the calling thread, which can freeze WinForms/WPF UI for large documents unless dispatched off the UI thread
Native DLL dependency: requires platform-specific pdfium.dll deployment via PdfiumViewer.Native.* packages
Memory profile: documents are loaded for viewer display rather than streamed for backend processing
Limited async surface: most operations are synchronous
Fork compatibility: code written for the original may need adjustment on community forks

Architecture

Desktop-oriented: tightly coupled to WinForms/WPF and System.Drawing, which is Windows-only on .NET 6+
Viewer-first design: no headless generation pipeline
Native binary management: cross-platform deployment requires platform-specific PDFium binaries

Feature Comparison Overview

Aspect	PdfiumViewer	IronPDF
Upstream status	Archived (community forks exist)	Active, commercial product
HTML support	None (viewer/renderer only)	HTML5/CSS3/JS via Chromium
Primary focus	Page display and rasterization	PDF generation and manipulation
Installation	Multi-package with native DLLs	Single NuGet, embedded native
Support model	Community-driven via fork repos	Commercial vendor support
Target runtimes	.NET Framework / fork-dependent	.NET Framework 4.6.2+ through modern .NET, cross-platform

Code Comparison

PdfiumViewer — Load and Display PDF in WinForms

using PdfiumViewer;
using System;
using System.Windows.Forms;

namespace DesktopPdfViewer
{
    public partial class MainForm : Form
    {
        private PdfRenderer pdfRenderer;

        public MainForm()
        {
            InitializeComponent();

            // Step 1: Add PdfRenderer control to form
            // Typically done in designer, shown here programmatically
            pdfRenderer = new PdfRenderer
            {
                Dock = DockStyle.Fill
            };
            this.Controls.Add(pdfRenderer);
        }

        private void LoadPdfButton_Click(object sender, EventArgs e)
        {
            try
            {
                // Step 2: Load PDF from file (synchronous call on the caller thread)
                using (var pdfDocument = PdfDocument.Load(@"C:\Documents\report.pdf"))
                {
                    // Step 3: Assign the document to the renderer control for display
                    pdfRenderer.Load(pdfDocument);

                    Console.WriteLine($"Loaded {pdfDocument.PageCount} pages.");
                }
            }
            catch (Exception ex)
            {
                MessageBox.Show($"Failed to load PDF: {ex.Message}", "Error");
            }
        }

        protected override void OnFormClosing(FormClosingEventArgs e)
        {
            // Step 4: Cleanup
            pdfRenderer?.Dispose();
            base.OnFormClosing(e);
        }
    }
}

Technical notes:

Synchronous load: PdfDocument.Load() runs on the calling thread; large files can block the UI unless dispatched off the UI thread
Document loaded for display: not optimized for streamed backend processing
Desktop-oriented: built around WinForms/WPF controls and System.Drawing, not designed for ASP.NET Core or headless services
No generation capability: cannot create PDFs from data, templates, or HTML — that is outside the library's scope
Fork API differences: method signatures may differ between community forks; check the docs for the fork you choose
Native DLL required: pdfium.dll must be deployed via the PdfiumViewer.Native.* packages

IronPDF — Generate PDF from HTML String

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var htmlContent = @"
<html>
<body style='font-family: Arial; margin: 40px;'>
    <h1>Quarterly Report</h1>
    <p>Revenue: $500,000</p>
    <p>Generated: {DateTime.Now:yyyy-MM-dd}</p>
</body>
</html>";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(htmlContent);
pdf.SaveAs("quarterly-report.pdf");

Performance notes:
Chromium engine renders HTML in ~200-500ms for typical single-page documents. For batch scenarios (100+ PDFs), IronPDF supports async/await and parallel rendering. The HTML string to PDF guide covers optimization techniques like caching, image embedding, and resource management.

PdfiumViewer — Extract Page as Bitmap

using PdfiumViewer;
using System.Drawing;
using System.Drawing.Imaging;
using System.IO;

namespace PdfThumbnailGenerator
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                using (var pdfDocument = PdfDocument.Load("contract.pdf"))
                {
                    // Render the first page to a bitmap at 96 DPI.
                    // Signature: Render(pageIndex, dpiX, dpiY, forPrinting)
                    // Some community forks expose alternative overloads; check
                    // the documentation for the fork you depend on.
                    using (var bitmap = pdfDocument.Render(0, 96, 96, false))
                    {
                        bitmap.Save("thumbnail.png", ImageFormat.Png);
                    }

                    Console.WriteLine("Thumbnail created.");
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }
        }
    }
}

Technical notes:

Synchronous rendering: each Render call runs on the calling thread
Per-page calls: rendering N pages typically means N individual Render calls
Bitmap memory: high-DPI renders consume significant memory (Letter size at 300 DPI is roughly a 25 MB uncompressed bitmap)
Output format: bitmap only — no vector output or re-embedding into a PDF
System.Drawing.Common dependency: Windows-only on .NET 6+, which constrains where the same code can run

IronPDF — Generate and Manipulate Multi-Page PDF

using IronPdf;
using System.Linq;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var pageHtmlTemplates = Enumerable.Range(1, 10).Select(i =>
    $"<h1>Page {i}</h1><p>Content for page {i}</p>");

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(string.Join("<div style='page-break-after: always;'></div>", pageHtmlTemplates));

// Add watermark to all pages
pdf.ApplyWatermark("<div style='opacity: 0.3;'>DRAFT</div>");

// Extract specific pages
var subset = pdf.CopyPages(0, 4);  // First 5 pages
subset.SaveAs("contract-summary.pdf");

Performance notes:
Bulk HTML rendering is faster than per-page approaches—IronPDF's Chromium engine processes page-break directives efficiently. Typical 10-page document with simple content renders in ~1 second. HTML to PDF tutorial demonstrates advanced layout techniques (CSS Grid, Flexbox, print media queries).

PdfiumViewer — Search Text via Page-Level Extraction

using PdfiumViewer;
using System;
using System.Text;

class Program
{
    static void Main(string[] args)
    {
        using (var pdfDocument = PdfDocument.Load("legal-document.pdf"))
        {
            string searchTerm = "indemnification";
            int totalMatches = 0;

            var sb = new StringBuilder();
            for (int i = 0; i < pdfDocument.PageCount; i++)
            {
                // GetPdfText returns the raw text of a single page —
                // no per-word coordinates, no layout reconstruction,
                // and no OCR for image-only pages.
                string pageText = pdfDocument.GetPdfText(i);
                sb.AppendLine($"--- Page {i + 1} ---");
                sb.AppendLine(pageText);

                int idx = 0;
                while ((idx = pageText.IndexOf(searchTerm, idx, StringComparison.OrdinalIgnoreCase)) >= 0)
                {
                    totalMatches++;
                    idx += searchTerm.Length;
                }
            }

            Console.WriteLine($"Found {totalMatches} match(es) for '{searchTerm}'.");
        }
    }
}

Technical notes:

GetPdfText(int page) returns raw page text — no per-word coordinates, no layout reconstruction, and no OCR
Image-only / scanned pages return empty text and need an external OCR engine (Tesseract, etc.) to be searchable
The library is Windows-oriented and depends on WinForms / System.Drawing assemblies, which limits where the same code runs headlessly on .NET 6+

IronPDF — Extract and Search Text

using IronPdf;
using System;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var pdf = PdfDocument.FromFile("legal-document.pdf");

// Extract all text from every page
string fullText = pdf.ExtractAllText();

// Search for term
int occurrences = fullText.Split(new[] { "indemnification" }, StringSplitOptions.None).Length - 1;
Console.WriteLine($"Found '{occurrences}' occurrences of 'indemnification'.");

// Extract from a specific page (0-indexed)
string page3Text = pdf.ExtractTextFromPage(2);

Performance notes:
Text extraction uses the underlying PDF text layer, not OCR, so it is fast on text-based PDFs but returns nothing for purely scanned image pages. Scanned-PDF workflows pair IronPDF with an OCR step (Tesseract or similar) as a separate package. The extraction API runs the same way in a console app, ASP.NET Core, or Docker — no UI dependency.

PdfiumViewer — Performance Benchmark Scenario: Load 500-Page PDF

using PdfiumViewer;
using System;
using System.Diagnostics;
using System.Windows.Forms;

namespace ViewerPerformanceTest
{
    public partial class BenchmarkForm : Form
    {
        private PdfRenderer pdfRenderer;

        public BenchmarkForm()
        {
            InitializeComponent();
            pdfRenderer = new PdfRenderer { Dock = DockStyle.Fill };
            this.Controls.Add(pdfRenderer);
        }

        private void LoadLargePdf_Click(object sender, EventArgs e)
        {
            var stopwatch = Stopwatch.StartNew();

            try
            {
                // PdfDocument.Load is synchronous; dispatch off the UI thread
                // (Task.Run, BackgroundWorker) if you want to keep the form
                // responsive while a large file loads.
                using (var pdfDocument = PdfDocument.Load("large-manual-500-pages.pdf"))
                {
                    stopwatch.Stop();
                    Console.WriteLine($"Load time: {stopwatch.ElapsedMilliseconds} ms");

                    pdfRenderer.Load(pdfDocument);
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Load failed after {stopwatch.ElapsedMilliseconds} ms: {ex.Message}");
            }
        }
    }
}

Observations:

Load is synchronous: large files block the calling thread; benchmark on your own hardware
Document is loaded for display: large documents can have a noticeable memory footprint
No built-in cancellation token for Load
Very large documents (1,000+ pages) can be slow to load and view in the renderer control

IronPDF — Performance Benchmark: Generate 500-Page PDF

using IronPdf;
using System;
using System.Diagnostics;
using System.Linq;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var stopwatch = Stopwatch.StartNew();

var htmlPages = Enumerable.Range(1, 500).Select(i =>
    $"<h1>Chapter {i}</h1><p>Content for chapter {i}...</p>");

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(
    string.Join("<div style='page-break-after: always;'></div>", htmlPages));

stopwatch.Stop();
Console.WriteLine($"Generation time: {stopwatch.ElapsedMilliseconds} ms");

pdf.SaveAs("generated-500-pages.pdf");

Observations:

Generation cost scales with HTML complexity (CSS, images, tables) more than raw page count
IronPDF exposes async APIs so generation can run off the UI thread in desktop apps
Optimization patterns: cache external assets, pre-compile templates, parallelize batches with care for engine memory

Architectural comparison:

Scenario	PdfiumViewer	IronPDF
Load and view an existing PDF	Built-in viewer/renderer controls	Not the target use case
Generate a PDF from HTML	Not supported	Core feature
Render a page to bitmap	Yes (via `Render`)	Available via `ToBitmap`
Extract text (programmatic)	Page-level via `GetPdfText`	`ExtractAllText` / `ExtractTextFromPage`
Headless / server execution	Designed around UI controls	Designed for headless use
Async APIs	Limited	Available across the generation pipeline

API Mapping Reference

PdfiumViewer Concept	IronPDF Equivalent	Notes
`PdfDocument.Load(path)`	`PdfDocument.FromFile(path)`	Both load existing PDFs
`pdfRenderer.Load(doc)`	N/A (no viewer control)	IronPDF is backend-focused
`doc.Render(page, dpiX, dpiY, forPrinting)`	`pdf.RasterizeToImageFiles(path, dpi)` / `pdf.ToBitmap()`	Both rasterize, different shapes
`doc.PageCount`	`pdf.PageCount`	Same property
`doc.GetPdfText(page)`	`pdf.ExtractTextFromPage(page)` / `pdf.ExtractAllText()`	Page-level vs. whole-document
`doc.Dispose()`	`pdf.Dispose()`	Both implement `IDisposable`
(not available)	`RenderHtmlAsPdf()`	IronPDF core feature
(not available)	`PdfDocument.Merge()`	Combine PDFs
(not available)	`pdf.Form`	Form read / write / flatten
(not available)	`pdf.SecuritySettings`	Password protection and permissions
`PdfViewer` control	(not available)	IronPDF has no WinForms/WPF UI control

Comprehensive Feature Comparison

Feature	PdfiumViewer	IronPDF
Status
Upstream project	Archived 2019-08-02	Actively developed
Community forks	Yes (bezzad, PdfiumViewer.Updated, others)	N/A (single product)
API stability across forks	May vary	Documented per release
Support model
Documentation	Fork-dependent	Vendor docs and API reference
Issue channels	GitHub issues per fork	Commercial vendor channels
Commercial support	Not available	Available
Content creation
HTML to PDF	No	Yes (core feature)
URL to PDF	No	Yes
Generate from scratch	No	Yes
Merge PDFs	No	Yes
Split PDFs	No	Yes
PDF operations
Display in WinForms/WPF	Yes (core feature)	No UI control
Render page to bitmap	Yes (`Render`)	Yes (`ToBitmap`, `RasterizeToImageFiles`)
Extract text	Page-level via `GetPdfText` (no per-word coords, no OCR)	`ExtractAllText` / `ExtractTextFromPage`
Form handling	View only	Read, write, flatten
Digital signatures	No API	Yes
Encryption	No API	Yes
Watermarks	No API	Yes
Security
Password-protected PDFs	Can open with password	Open and manipulate, can set passwords
Certificate signatures	No	Yes
Redaction	No	Yes
Runtime characteristics
Thread model	Synchronous; UI thread must dispatch large work	Async APIs available
Native binaries	Separate `PdfiumViewer.Native.*` packages	Embedded with the IronPdf package
Cross-platform	Windows-oriented; `System.Drawing` is Windows-only on .NET 6+	Windows, Linux, macOS, Docker
Server / cloud usage	Not the target use case	Designed for it
Development
Async/await	Limited	Available
Headless operation	Built around UI controls	Yes
Deployment	Desktop apps	NuGet, Docker, cloud

Installation Comparison

PdfiumViewer (community fork example):

Install-Package PdfiumViewer.Updated  # .NET 6+
Install-Package PdfiumViewer.Native.x86_64.v8-xfa  # Native binaries

using PdfiumViewer;
// Requires WinForms or WPF application
// Add PdfRenderer control to form

IronPDF:

Install-Package IronPdf  # Single package, all platforms

using IronPdf;
// Works in console, ASP.NET, Azure Functions, etc.

Conclusion

PdfiumViewer is good at the job it was designed for: embedding a PDF viewer control in WinForms/WPF desktop applications, with page-level rendering and GetPdfText for raw text extraction. For teams whose product is a Windows desktop UI that already has PDFs to display, community forks like PdfiumViewer.Updated or bezzad/PdfiumViewer can still serve that role. The upstream archive in 2019, multi-fork ecosystem, and tight coupling to WinForms/System.Drawing are the points to weigh against that.

Migration starts to make sense when:

Server-side or headless PDF generation is on the requirements list (web apps, APIs, background workers)
Document creation from templates, HTML, or data is needed
Cross-platform deployment is on the roadmap (Linux, Docker, cloud)
PDF manipulation beyond viewing is required (merge, split, forms, signatures, watermarks)
Architecture is shifting from desktop to web or microservices

IronPDF replaces the generation side of that equation with PDF rendering from HTML strings, URLs, and files via a Chromium engine. It does not ship a WinForms/WPF viewer control, but it does handle the document lifecycle: create from modern HTML/CSS/JS, manipulate (merge, split, forms, encryption, signatures), extract (text, images, metadata), and print to physical printers. Installation is a single NuGet package with embedded native dependencies, and IronPDF runs in console apps, ASP.NET Core, Azure Functions, AWS Lambda, and Docker containers across Windows, Linux, and macOS on .NET Framework 4.6.2+ through modern .NET.

The two libraries optimize for different things — PdfiumViewer for immediate on-screen display, IronPDF for headless document creation — so the right answer often depends on which side of that line the product roadmap is sitting on.

What's your experience with desktop PDF viewer controls versus headless generation libraries? Share your performance benchmarks in the comments.

Related resources:

When Azure Functions Fight Back: Signs You've Outgrown Them

Martin Oehlert — Fri, 15 May 2026 09:41:53 +0000

Your queue handler hit the 10-minute Consumption ceiling last week. You restructured it to checkpoint, and the next month-end batch still creeps over. The question now is not how to wring one more workaround out of Functions. It is when the next workaround stops being cheaper than moving the job onto a different host. Four signals push the answer past "still cheaper": performance walls, complexity sprawl, coupling patterns the platform makes worse, and a cost crossover that arrives sooner than most teams plan for.

Performance walls you will hit

Four limits decide how far Functions can carry the workload: how long any one invocation can run, how much memory it can use, how many sockets it can hold open, and what its file system actually persists.

Execution timeout per plan

The numbers from the hosting plan timeout reference:

Cross-cutting cap: HTTP triggers that do not respond within 230 seconds are cut off by the Azure Load Balancer with HTTP 502 regardless of functionTimeout. The function keeps running but cannot return a response. Sources: HTTP trigger limits, Web request times out in App Service. For longer work, Microsoft points at the Durable Functions async HTTP pattern.

host.json: functionTimeout describes what happens at the cap: "When an execution exceeds this duration, a timeout error occurs and the language worker process restarts." The worker is killed, and in-flight invocations on it are lost. What the trigger does next is per binding:

Service Bus: PeekLock with autoComplete = true. On host crash the lock expires, and on next visibility the message reappears with DeliveryCount incremented. After MaxDeliveryCount (default 10) it lands in <queue>/$deadletterqueue (Service Bus dead-letter queues).
Storage Queue: visibility timeout per message. On host crash the storage-default 10-minute timeout takes over. After 5 failed attempts the message moves to <queue>-poison (Storage queue trigger: Peek lock).
Blob trigger: same five-attempt default, with failed blobs landing in webjobs-blobtrigger-poison (Poison blobs).
HTTP: caller already saw the 502 at 230 s. No automatic retry.
Timer: per Timer trigger: Retry behavior, "the timer trigger doesn't retry after a function fails."

A subtle one to flag: only Cosmos DB, Event Hubs, Kafka, and Timer support host-level retry policies ([FixedDelayRetry], [ExponentialBackoffRetry]). For Service Bus and Storage Queue, the binding's native retry semantics are the only mechanism (Azure Functions error handling and retries). Decorating a Service Bus trigger with [ExponentialBackoffRetry] does nothing.

The fix that lets you stay (when it can)

Most "we hit the timeout" stories are workloads that can be split into chunks with a checkpoint between them. A queue-triggered batch that processes 50,000 items in 50 ms each runs 42 minutes. The same handler that processes 500 at a time and writes a cursor blob between chunks survives any number of restarts. From the companion sample:

[Function(nameof(DrainBatchFunction))]
public async Task Run(
    [QueueTrigger("batches", Connection = "AzureWebJobsStorage")] BatchCommand command,
    CancellationToken cancellationToken)
{
    await cursors.CreateIfNotExistsAsync(cancellationToken: cancellationToken);

    var checkpoint = cursors.GetBlobClient($"batch-{command.BatchId}.cursor");
    var lastCommitted = await ReadCursorAsync(checkpoint, cancellationToken);

    await foreach (var chunk in source.ChunksAfterAsync(
                       command.BatchId, lastCommitted, _chunkSize, cancellationToken))
    {
        await ProcessAsync(chunk, cancellationToken);

        // Commit the cursor *before* the next chunk; if the worker is killed
        // immediately after this upload, the next attempt resumes here.
        await checkpoint.UploadAsync(
            BinaryData.FromString(chunk.LastItemId.ToString(CultureInfo.InvariantCulture)),
            overwrite: true,
            cancellationToken);
    }
}

The shape is what matters: chunk, process, commit cursor, repeat. Each chunk must be small enough that the worst-case batch (500 items at 50 ms = 25 s) finishes well inside the timeout. The cursor write is the moment durability shifts. On retry, ReadCursorAsync resumes at the last committed item instead of restarting at item 1.

This pattern keeps you on Functions. When the single chunk itself runs longer than the timeout (a 12-minute database query, a multi-gigabyte file copy, a 30-minute model inference), the workload has outgrown the platform. No chunk size helps.

Memory ceilings

Per-instance memory from the service limits table:

Two surprises in that list. Flex Consumption has a 512 MB SKU. Most teams reading the marketing page assume Flex starts where Premium does. And from the trigger's perspective, OOM and timeout look the same: the OS terminates the worker, the host restarts, and the per-binding retry semantics from the previous section decide whether the input is replayed or dropped. The closest official reference is the host health monitor, which can recycle the host preemptively when performance counters stay above 80% within the health-check window.

The blob trigger has a documented memory amplifier worth knowing. Microsoft's Blob trigger: Memory usage and concurrency warns that "the runtime must load the entire blob into memory more than one time during processing" if you bind to a non-streaming type, and concurrency multiplies the effect. Bind to Stream for anything past a few MB.

SNAT ports and connection exhaustion

Two distinct outbound limits, easy to confuse.

SNAT port budget per instance. From Troubleshoot intermittent outbound connection errors: "Each instance on Azure App service is initially given a preallocated number of 128 SNAT ports." Ports apply to the same destination tuple (address + port) and are reclaimed by the load balancer four minutes after the connection closes. Microsoft's recommendation is to keep usage under 100 outbound connections per unique remote endpoint per instance.

Total outbound TCP connections per instance. Consumption is capped at 600 active (1,200 total) per instance, and the runtime logs Host thresholds exceeded: Connections at the limit. Flex, Premium, and Dedicated are listed as "unbounded" (Dedicated still subject to App Service worker-size caps).

The fastest way to walk into both limits is the canonical Functions anti-pattern: new HttpClient() inside a function body. Each invocation creates a new socket pool, and sockets sit in TIME_WAIT after disposal, compounded by the four-minute SNAT reclaim. At any reasonable RPS, the 128-port budget for a destination host is exhausted, and the function sees intermittent connect failures or SocketException. The AZF0002 analyzer flags the call site at build time.

The recommended fix is IHttpClientFactory, registered once in Program.cs. From the companion sample:

var builder = FunctionsApplication.CreateBuilder(args);
builder.ConfigureFunctionsWebApplication();

builder.Services
    .AddOptions<PaymentsOptions>()
    .Bind(builder.Configuration.GetSection(PaymentsOptions.SectionName))
    .ValidateDataAnnotations()
    .ValidateOnStart();

builder.Services
    .AddHttpClient<IPaymentsApi, PaymentsApi>((sp, client) =>
    {
        var options = sp.GetRequiredService<IOptions<PaymentsOptions>>().Value;
        client.BaseAddress = new Uri(options.BaseAddress);
        client.Timeout = TimeSpan.FromSeconds(options.TimeoutSeconds);
    })
    .AddStandardResilienceHandler();

The factory caches HttpMessageHandler instances (default lifetime 2 min per HttpClient lifetime management) and rotates them so DNS changes are picked up. The AddStandardResilienceHandler call layers in retry, circuit breaker, and timeout policies from Microsoft.Extensions.Http.Resilience without an extra DI dance. The function takes IPaymentsApi on its primary constructor and never calls new HttpClient() again.

One caveat from HttpClient guidelines: Recommended use: the factory shares a CookieContainer across pooled handlers. If your client depends on cookies, prefer a singleton with an explicit SocketsHttpHandler that sets PooledConnectionLifetime instead.

Database connections do not get the same fix

ADO.NET pools per process, and Functions runs one process per instance. Microsoft's SqlClient guidance is direct: "ADO.NET implements connection pooling by default. But because you can still run out of connections, you should optimize connections to the database."

The math is the trap. Each Consumption instance carries its own pool (default Max Pool Size = 100), and the platform can spin up to 200 Consumption instances (service limits). At full scale-out: 200 instances * 100 connections = 20,000 potential connections against the database. Premium is capped at 100 instances, Flex at 1,000. Most managed databases fall over well below that.

The fix lives at the database, not in Functions. Lower the pool size per instance, cap the application's max scale-out, or front the database with a connection pooler (PgBouncer, RDS Proxy equivalents on Azure Database for PostgreSQL Flexible Server).

Local file system

Three behaviours worth distinguishing.

Per-instance ephemeral temp. From Operating system functionality in App Service: %SystemDrive%\local is reserved for temporary local storage, "not persistent across app restarts." Plan-by-plan capacity ranges from 0.5 GB (Consumption) to 21-140 GB (Premium / Dedicated). Scale-out does not just reset temp. It makes the data invisible: instance A writes /tmp/cache.json, and instance B never sees it.

Persisted shares. Premium and Dedicated can mount Azure Files (SMB or NFS). Flex Consumption supports SMB and read-only Blobs but not NFS (Choose a file access strategy). SMB cold-start latency is documented at 200-500 ms on first execution.

Read-only file systems. When WEBSITE_RUN_FROM_PACKAGE is set, "the wwwroot folder is read-only and you receive an error if you write files to this directory" (Run from package: General considerations). The same page is explicit: "Don't add the WEBSITE_RUN_FROM_PACKAGE app setting to apps on the Flex Consumption plan." Flex's deployment model treats the package as read-only by design. Container Apps follows container-image semantics: image layers are read-only.

The Durable Functions provider doc gives the blunt warning: "Storing payloads to local disks is not recommended, since on-disk state isn't guaranteed to be available" (Azure Storage representation in a task hub). Anything you want to read on a different instance, or after a restart, belongs in Blob, Cosmos, or another external store.

Complexity signals that indicate a problem

Performance walls fail the workload outright. Complexity signals fail it slowly: the function count keeps climbing, the orchestration diagram keeps growing legends, and at some point you cannot describe the system without a whiteboard. None of the limits below are timeouts. They are the shape of the architecture telling you it has outgrown the deployment unit.

Durable Functions sub-orchestration sprawl

Microsoft lists three legitimate uses for CallSubOrchestratorAsync (Sub-orchestrations: When to use):

Compose reusable workflow building blocks shared across parents.
Fan out parallel instances of the same orchestrator and wait for all.
Organise a large orchestration into named, testable pieces.

If a sub-orchestration is not doing one of those three jobs, it is decoration, and the cost compounds. The same docs add a hard constraint: "Sub-orchestrations must be defined in the same app as the parent orchestration." The cross-app workaround is the HTTP 202 polling pattern, a different programming model with no parent/child semantics, no shared retry policy, and no automatic exception propagation. The reason is the task hub model: "If multiple apps use the same task hub, they compete for messages, which can result in undefined behavior, including orchestrations getting unexpectedly stuck."

The decision worth surfacing in your design review: task hub partition count is immutable after creation. Default 4, max 16. From Performance and scale: Partition count: "You can't change the partition count after you create a task hub. Set it high enough to meet expected scale-out requirements." Most teams discover this when their orchestrator throughput plateaus and they reach for the dial that does not exist.

Sprawl signals inside one app:

Parent depth of 3+ levels where the grandchild does almost no work.
Sub-orchestrators that wrap a single activity call.
Parents fanning out to sub-orchestrators that themselves fan out: one instance ID can spawn dozens of children, each consuming control queue capacity.

Orchestrator code constraints

Orchestrators replay from history every time a new event arrives. The runtime requires deterministic code: the same input must produce the same call sequence on every replay. From Orchestrator function code constraints, the following must not appear inside an orchestrator body:

DateTime.Now / DateTime.UtcNow (use context.CurrentUtcDateTime).
Guid.NewGuid() (use context.NewGuid(), which returns Type 5 UUIDs derived from instance ID).
Bindings, including the orchestration client and entity client bindings. I/O lives in activities.
Static variables and environment variables.
Direct network or HTTP calls.
Task.Run, Task.Delay, Thread.Sleep, HttpClient.SendAsync. Use context.CreateTimer for delays.

The clean rule is one sentence: orchestrators schedule, activities act. Anything that reads time, calls the network, or generates a random value belongs in an activity. The framework throws NonDeterministicOrchestrationException sometimes, but the docs are explicit: "this detection behavior won't catch all violations, and you shouldn't depend on it." Violations ship and break weeks later.

Shared external state as bottleneck

Account-level ceilings from Standard storage account scalability targets:

20,000 RPS per general-purpose v2 account in most regions, and 40,000 RPS in higher-tier regions.
Hitting any of these returns HTTP 503 Server Busy or HTTP 500 Operation Timeout.

Per-service ceilings (the ones that bite first):

Storage Queue: account 20,000 msg/s, single queue tops out at 2,000 msg/s (Queue Storage scalability, Data partitioning strategies).
Storage Table: 20,000 entities/s account-wide, 2,000 entities/s per partition (Table Storage scalability). Throttling shows as PercentThrottlingError. Date-as-partition-key is the canonical anti-pattern.
Cosmos DB hot partition: hard ceiling of 10,000 RU/s per logical partition (Partitioning and horizontal scaling), regardless of total provisioned throughput. Splitting does not help when the key is genuinely hot (Redistribute throughput). The fix is a different partition key.

Durable Functions sits on top of those numbers. Every task hub creates two Azure Tables (<hub>History, <hub>Instances), one work-item queue, one control queue per partition, and blob containers for leases and large messages (Azure Storage representation in a task hub). When several apps point at the same storage account, every one fights for the same per-partition 2,000 entities/s on the History and Instances tables. Microsoft's reliability guidance is direct: "use a separate storage account for each function app. This aspect is especially true with Durable Functions and Event Hubs triggered functions" (Best practices for reliable Azure Functions).

Service Bus session locks

The architectural smell is two or more functions in the same function app triggering on the same session-enabled queue. Sessions hold an exclusive lock per session ID (Message sessions): only one receiver at a time, per-session FIFO, default MaxDeliveryCount = 10. The Functions session host defaults are aggressive (Service Bus host.json settings): maxConcurrentSessions = 2000, maxConcurrentCalls = 16 per session. Thread starvation at high MaxConcurrentSessions is documented in the troubleshooting guide.

Two functions in the same app are not parallelising work over those sessions. They are competing for session locks. SessionLockLost shows up when the lock expires before renewal, the partition rebalances, or the AMQP link is idle for 10 minutes (Service Bus messaging exceptions: SessionLockLost). The fix is one consumer per session-enabled queue per app, period.

Function count vs feature count

Microsoft does not publish a number for "too many functions in one app", but the Function organization best practices describe the failure mode plainly:

Each function that you create has a memory footprint. While this footprint is usually small, having too many functions within a function app can lead to slower startup of your app on new instances.

Connection strings and other credentials stored in application settings gives all of the functions in the function app the same set of permissions in the associated resource. Consider minimizing the number of functions with access to specific credentials by moving functions that don't use those credentials to a separate function app.

A self-test you can run in 10 minutes:

Can you name the feature each function delivers without opening the code?
Does explaining one feature require drawing a diagram of 5+ function boundaries?
Is your function-to-feature ratio above 3:1? (50 functions for 8 features is 6:1.)
Do all functions share the same connection strings whether they use them or not?
Do load profiles inside the app diverge? (Chatty queue trigger next to memory-heavy report function.)
Does shipping one function redeploy 49 others?
Does cold start time grow with every release?
Does the same Durable task hub serve more than one feature area?

Three or more is the smell. Six or more is "this should have been split a quarter ago." The W19 split-apps approach handles the first wave of this. If splitting still leaves you fighting the platform, the article you are reading is the second wave.

Coupling patterns that fight the serverless model

Some of the worst Functions deployments do not look bad on any one screen. The handlers are clean, every function is short, the metrics are healthy. The damage is in the topology: the way the functions wire to each other multiplies cost, slows change, or quietly burns money in a loop. Four shapes show up over and over.

Sequential chains (the service with three methods)

Function A writes a message. Function B is triggered by it. Function C is triggered by B's message. Every input traverses the same three hops, with no branching and no fan-out. It is a workflow, not a serverless decomposition.

Microsoft's Pipes and Filters pattern is explicit on when not to use it: "the processing steps performed by an application aren't independent, or they have to be performed together as part of a single transaction." A three-step lockstep chain meets that condition. The same page points at Compute Resource Consolidation for the consolidation: "You can group filters that should scale together in the same process."

Cost per hop is five charges:

Source-function invocation (per-execution + GB-second).
Queue write (one transaction).
Queue read by the next function (another transaction).
Serialize + deserialize (CPU on both sides).
New consumer invocation (per-execution + GB-second again).

A three-function chain triples that. The corrected shapes are documented: collapse to one Functions invocation that calls the three operations as private methods (single trigger, single execution, no inter-function queues), or move to Durable Functions function chaining if the steps are genuinely separate but coordinated. The orchestrator keeps durable state and tracks the choreography explicitly.

Shared database schemas across Function Apps

Microsoft's Data considerations for microservices is unambiguous:

Two services shouldn't share a data store. Each service manages its own private data store, and other services can't access it directly.

Services can safely share the same physical database server. Problems occur when services share the same schema, or they read and write to the same set of database tables.

Two Function Apps on the same Azure SQL server with separate schemas is fine. Two Function Apps writing the same Orders table is the antipattern.

The cost surfaces at migration time. Additive changes (new column, new table) work. Destructive changes (rename, drop, type change, NOT NULL on a populated column) require all N apps to agree on a release order: forward-compat code shipped in advance to every app, or a coordinated cutover that removes the ability of any one app to deploy independently. Two-phase migrations (expand-and-contract) become the default. The blue/green compatibility window is the intersection of every app's deploy windows. Each schema version must be readable and writable by every prior version of every consumer that might still be running (multitenant antipatterns).

If three apps share an Orders table and one ships weekly, one biweekly, one monthly, the slowest cadence sets the floor. A hosted service that owns the schema collapses N consumers to 1, and migrations stop being a coordination problem. The trade is what you give up: per-function scaling and trigger-binding ergonomics. The Saga pattern: Context and problem acknowledges the trade explicitly.

Circular queue dependencies and poison loops

Two defaults to cite side by side, because readers conflate them:

Storage Queue maxDequeueCount = 5. After 5 failures the message goes to <originalqueue>-poison (Storage queue host.json settings).
Service Bus MaxDeliveryCount = 10. After 10 attempts the message goes to the DLQ at <queue path>/$deadletterqueue (Service Bus dead-letter queues). "There's no automatic cleanup of the DLQ. Messages remain in the DLQ until you explicitly retrieve them."

Functions handles the settlement automatically: "By default, the runtime calls Complete on the message if the function finishes successfully, or calls Abandon if the function fails" (Service Bus trigger: PeekLock). The two antipatterns that subvert this safety net:

Retry queue that re-enqueues to the input queue. Handler catches the exception, writes the message back to the input queue with a transient-failure tag, returns success. The runtime never sees a failure, dequeueCount resets each round trip, and the message lives forever. The MessageId changes because the application is publishing a new message each time, so log correlation by ID misses it.
Dead-letter handler that re-triggers the original function. A second function with a trigger on the poison/DLQ subqueue picks up failed messages and calls back into the original function's logic (or worse, writes back to the original input queue). Result: input -> processing -> poison -> handler -> input ad infinitum. Service Bus eventually surfaces QuotaExceeded (messaging exceptions). Storage Queues do not fail nearly as loudly. The loop just costs money until somebody notices the bill.

Microsoft names the failure shape directly. The Choreography pattern carries the warning: "There's a risk of cyclic dependency between saga participants because they have to consume each other's commands."

Detecting poison loops in Application Insights

The End-to-end transaction details view shows a Gantt chart of every server-side telemetry event for a correlated operation_Id across all instrumented components. For a Functions chain, each invocation shows up as a request span with the queue-dependency calls between them, all under the same operation. N+1 invocations of the same function name under the same operation_Id is the loop signature. The Application Map makes the cycle visible at the topology level: a node with a self-edge or a tight A->B->A cycle.

The detection workflow is two clicks: Failures view, drill into a sample exception, the End-to-end transaction view opens with the trace tree expanded. If you cannot tell at a glance whether a transaction is one logical request or three loops of the same one, instrument before you refactor.

Configuration drift

Splitting one Function App into N copies the configuration N times. Each app has its own connection strings, API keys, storage keys in App Settings. Rotating a secret means N updates. Missing one leaves a stale credential in production until the next deploy.

Key Vault references move the storage out of App Settings and into a vault. The syntax (Use Key Vault references as app settings) takes one of two forms:

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)
@Microsoft.KeyVault(VaultName=myvault;SecretName=mysecret)

The failure mode the same page documents: "If a reference isn't resolved properly, the reference string is used instead." Real production failure pattern: the function tries to authenticate with the literal string @Microsoft.KeyVault(...), gets a 401, and the operator stares at App Settings that look correct in the portal. The WEBSITE_KEYVAULT_REFERENCES env var holds resolution status for every reference, and the portal exposes a Key Vault Application Settings Diagnostics detector. Both are worth knowing before the first incident.

The "partially adopted" antipattern is the worst version: some apps reference @Microsoft.KeyVault(...), others have raw values because the migration was incomplete. Rotating the secret in the vault updates the references and leaves the raw-value apps stale. Configuration looks correct in the portal until the next failure surface, usually a 401 from a downstream service hours after rotation.

Azure App Configuration collapses N App Settings stores into one. "Spreading configuration settings across these components can lead to hard-to-troubleshoot errors during an application deployment. Use App Configuration to store all the settings for your application and secure their accesses in one place." App Configuration handles non-secret config and holds Key Vault references for secret values. Key Vault stays the secret store. The trade is one runtime dependency, N role assignments, and refresh semantics that are opt-in (without dynamic refresh, settings are read once at startup). For two-app workloads it might not pay. For ten-app workloads it almost always does (App Configuration: high resiliency).

The cost crossover point

"Functions is too expensive at scale" and "Functions is the cheap option" are both true. They describe different points on the same curve. The crossover happens earlier than most teams plan for, and the worked example below makes it concrete.

A worked example: 10 RPS at 200 ms / 256 MB

Assumptions: 10 RPS sustained for 30 days, 200 ms execution, 256 MB memory. East US 2. Single subscription with the per-month free grants applied. All numbers verified against the Azure Retail Prices API on 2026-05-08.

Volumes:

Executions: 10 * 3,600 * 24 * 30 = 25,920,000
GB-seconds: 0.25 * 0.2 * 25,920,000 = 1,296,000

The Flex number is the trap. Flex bills a 1-second minimum per execution then rounds to 100 ms above that (Flex billing). At 200 ms / 256 MB, every invocation bills as if it ran 1 second, which is 5x the GB-seconds and pushes the bill 9x above legacy Consumption. Teams switching from Consumption to Flex "for the per-function scaling" walk into this and call the platform expensive. Verify on real workload before committing.

The crossover with EP1 is the other number worth keeping in your head. Setting Consumption_total = EP1_floor and solving for RPS at 200 ms / 256 MB:

Cost ≈ 2.592 * R - 6.60 = 145.93
R ≈ 58.8 RPS sustained

At the 200 ms / 256 MB shape, Consumption ties EP1 around 60 RPS sustained. Below that, Consumption wins on cost. Above that, EP1 starts winning and the Premium-only reasons (always-on, VNet integration, longer timeouts) compound the case. The crossover shifts with execution length: at 1 s / 256 MB it falls to about 12 RPS, and at 50 ms it pushes past 240 RPS. Pick the shape that matches your workload before you quote a number.

AKS gets one sentence: if you need Kubernetes primitives, you are no longer comparing against Functions, and the comparison belongs in a different article.

The hidden bill in App Insights

App Insights bills through Log Analytics (App Insights billing) at $2.76 per GB ingested above the 5 GB free grant per workspace. For most apps the default adaptive sampling at 5 events/second per host keeps ingestion under the grant (Sampling in Application Insights). The failure mode is operational: an engineer disables sampling to chase a bug, forgets to re-enable, and the next month's bill arrives. At 100 RPS unsampled with 10 KB telemetry events, ingestion is 86 GB/day, which is 2.6 TB/month, which is roughly $7,180/month at the PAYG rate.

The mitigation is a daily cap, set per workspace. The portal default for a workspace-based App Insights resource is 100 GB/day, but resources created via Visual Studio default to 32.3 MB/day (Daily cap). Whichever number you pick, set it before someone disables sampling.

The other hidden bill: the storage account

Every Function App requires a general-purpose storage account (Storage considerations). With one or two apps, storage is rounding error. With thirty apps after a W19-style split, it becomes a line item:

Queue triggers: every poll is a Class 2 op, roughly one per second when idle. Idle alone is 86,400 polls/day * 30 / 10,000 * $0.004 ≈ $1/month per queue. Real processing adds put + get + delete = 3 ops per message.
Durable task hubs: orchestration and history tables grow into millions of rows with replays, plus control queues, work-item queues, and instance tables. A busy task hub easily reaches $20-50/month before the orchestrator's compute cost.
Internal runtime traffic: lease blobs for the scale controller, host locks. Negligible per app, multiplied by N apps it shows up.

Microsoft's own guidance is to put each app on its own storage account, especially for Durable Functions and Event Hubs triggers. That doubles or triples your storage line item, and it is still the right call.

People-time

The cost crossover argument rarely decides the migration. People-time almost always does.

Debugging across N function apps requires correlated query plumbing in App Insights plus a mental model of which app owns which trigger.
Each function app is its own deployment unit, so coordinated releases need a release pipeline that understands ordering and rollback.
An on-call alert that fires "queue X is backing up" requires the operator to know which app owns queue X, which trigger, and which version is deployed.
Configuration drift compounds with app count, as the previous section already showed.

Cognitive load scales super-linearly with app count. It shows up as slower MTTR, not as a Functions bill line item, and that is exactly why it stays invisible until the team is exhausted.

Making the decision: stay, refactor, or migrate

Most "outgrowing Functions" complaints are organisational, not technical. Apply the W19 split-apps approach first, then revisit. The four concrete signals that say you can stay: no timeout pressure (longest job under half the plan limit), no memory pressure (peak under 60% of the instance ceiling), SNAT and connection issues fixed by IHttpClientFactory, function-to-feature ratio under 3:1. If all four hold, the platform is not the problem.

Refactor within Functions

This is W19 territory: split into multiple apps, extract a shared library, isolate triggers by scaling profile. If you are on Consumption, the next step before Premium is Flex Consumption (per-function scaling, longer timeouts, larger SKUs). The caveat from the cost section bears repeating: Flex's 1-second billing floor punishes sub-second functions. Verify on real workload before committing.

For workloads that bump the timeout but can be split, the checkpoint pattern from the Performance walls section keeps you on Functions: chunk, process, commit cursor, repeat. That keeps the trigger ergonomics, the deployment unit, and the scale controller. The cost is one cursor blob per active batch.

Extract specific functions

The middle ground. The function app stays, and one or two functions move out, usually because they hit a wall the rest of the app does not.

Long-running jobs. Hosted service in App Service, or a Container Apps job. Same business logic, no per-invocation cap. The companion sample shows the same payment-settlement workload as a BackgroundService next to its Function App original. The diff is the hosting wrapper, not the algorithm:

public sealed class SettlementWorker(
    QueueClient queueClient,
    IPaymentSettler settler,
    IOptions<QueueOptions> queueOptions,
    SettlementWorkerStatus status,
    ILogger<SettlementWorker> logger) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await queueClient.CreateIfNotExistsAsync(cancellationToken: stoppingToken);

        while (!stoppingToken.IsCancellationRequested)
        {
            var response = await queueClient.ReceiveMessagesAsync(
                maxMessages: _options.MaxBatchMessages,
                visibilityTimeout: TimeSpan.FromSeconds(_options.VisibilityTimeoutSeconds),
                cancellationToken: stoppingToken);

            if (response.Value.Length == 0)
            {
                await Task.Delay(_options.IdlePollingDelayMs, stoppingToken);
                continue;
            }

            foreach (var message in response.Value)
            {
                await ProcessAsync(message, stoppingToken);
            }
        }
    }
}

Same IPaymentSettler from the shared library, same queue, no per-invocation timeout. The trade is paying for an always-on worker (App Service) or accepting cold-start on first replica scale-out (Container Apps with KEDA).

Stateful workflows hitting Durable limits. Cross-app sub-orchestration is impossible, and shared task hub contention is real. Logic Apps Standard or a hosted workflow engine (Temporal, Elsa, Conductor) trades the binding ergonomics for a workflow surface that scales the way Durable does not.
CPU- or memory-bound work above EP3. Container Apps with the Dedicated workload profile, or AKS if Kubernetes is already a platform decision in your org.

Full migration

Rare. Criteria: timeout + memory + connection + cost crossover all present, all blocking, and the W19 organisational fixes have been applied without relief. The migration path is contract-first: extract HTTP triggers into thin wrappers, push business logic into testable libraries (a *.Core project consumed by both the Function App and the destination host), then move binding by binding.

The companion sample lays this out concretely. Settlement.Core is consumed unchanged by Settlement.FunctionApp (the timeout-wall starting point), Settlement.AppService (always-on, adds HTTP endpoints), and Settlement.ContainerApp (KEDA-scaled, scale-to-zero, no web host). The diffs are pure hosting concerns. The algorithm and the contract are identical. Reading the three side by side makes the migration question stop being abstract: you are pricing one wrapper against another, not rewriting the workload.

Decision matrix

The cost crossover at the bottom of the table is the one most teams reach for first. The decision rarely turns on it. It turns on people-time and on whether the abstraction is fighting your design or supporting it. When the abstraction is supporting the design, the right answer is almost always "stay and clean up the wiring."

Wrap-up

The four signals from the opening map to the four sections you just read. Timeouts, memory, sockets, and file system are the platform telling you the workload is too big. Sub-orchestration sprawl, session-lock contention, and high function-to-feature ratios are your team telling you the deployment unit is too big. Sequential chains, shared schemas, and poison loops are the topology making both worse. The cost crossover decides whether the right move is a different plan, a different host, or a different problem statement. None of the signals on its own says "migrate." Two of them at once says "look harder." Three of them blocking says "the abstraction is no longer paying its freight."

When you last looked at outgrowing Functions, did you stay and refactor, or did you extract the workload to a different host?

Azure Functions Beyond the Basics
Continues from Azure Functions for .NET Developers (Parts 1-9)

Part 1: Running Azure Functions in Docker: Why and How

Part 2: Docker Pitfalls I Hit (And How to Avoid Them)

Part 3: Scaling Azure Functions: Consumption vs Premium vs Dedicated

Part 4: Structuring Complex Function Apps: Project Organization

Part 5: When Azure Functions Fight Back: Signs You've Outgrown Them (this article)

CVE-2026-35433 | .NET Elevation of Privilege Vulnerability | R.A.H.S.I. Framework™ Analysis

Aakash Rahsi — Fri, 15 May 2026 03:29:05 +0000

CVE-2026-35433 | .NET Elevation of Privilege Vulnerability | R.A.H.S.I. Framework™ Analysis

🛡️Let's Connect & Continue the Conversation

🛡️Read Complete Article |

CVE-2026-35433 | .NET Elevation of Privilege Vulnerability | R.A.H.S.I. Framework™ Analysis

R.A.H.S.I. analysis of CVE-2026-35433, a .NET elevation of privilege flaw affecting runtime trust and patch strategy.

aakashrahsi.online

🛡️Let's Connect |

Hire Aakash Rahsi | Expert in Intune, Automation, AI, and Cloud Solutions

Hire Aakash Rahsi, a seasoned IT expert with over 13 years of experience specializing in PowerShell scripting, IT automation, cloud solutions, and cutting-edge tech consulting. Aakash offers tailored strategies and innovative solutions to help businesses streamline operations, optimize cloud infrastructure, and embrace modern technology. Perfect for organizations seeking advanced IT consulting, automation expertise, and cloud optimization to stay ahead in the tech landscape.

aakashrahsi.online

.NET is not only a developer runtime.

It is a trust layer inside enterprise applications, desktop workloads, cloud services, automation pipelines, and business platforms.

CVE-2026-35433 is a high-severity .NET elevation of privilege vulnerability linked to improper input validation.

Under the R.A.H.S.I. Framework™, this CVE should be assessed as a runtime-trust and privilege-boundary issue.

1. Runtime Trust Risk

.NET applications often run inside business-critical environments where local execution paths, dependency behavior, and application context can influence privilege boundaries.

When input validation fails, the impact can move beyond a single application and affect the trust model around the host workload.

2. Privilege Boundary Exposure

Elevation of privilege does not always begin with admin access.

This CVE highlights why local execution surfaces, user-assisted flows, runtime permissions, and application identity must be treated as part of the enterprise attack surface.

3. Patch Confidence and Validation

Patching is essential, but patching alone is not governance.

Security teams should validate runtime coverage across endpoints, servers, CI/CD agents, packaged applications, and legacy .NET Framework dependencies.

Key Takeaway

Privilege boundaries are only as strong as the runtime layers that enforce them.

Security teams should:

Update affected .NET and .NET Framework deployments
Inventory .NET 8.0, .NET 9.0, .NET 10.0, and relevant .NET Framework assets
Validate patch coverage on endpoints, servers, and build agents
Restrict local user rights and remove unnecessary accounts
Monitor privilege changes, unusual process launches, and application anomalies
Review dependency, runtime, and application hardening controls

R.A.H.S.I. Framework™ View

When a runtime layer can be abused to cross privilege boundaries, application security becomes identity, endpoint, and governance security.

.NET Design Patterns Deep Dive: What Still Matters in 2026

Vikrant Bagal — Thu, 14 May 2026 15:44:02 +0000

Design patterns have been a cornerstone of object-oriented software development for decades. Yet, with the evolution of .NET — from .NET Framework to .NET 10, C# 14, and the rise of cloud-native architectures — the relevance of each pattern has shifted dramatically. This deep dive explores which design patterns remain essential in modern .NET development, which have become anti-patterns, and how to apply them effectively for performance, maintainability, and scalability.

Why Design Patterns Still Matter

In 2026, the .NET ecosystem is richer than ever. From high‑performance services to AI‑driven applications, the underlying principles of good software design remain constant: separation of concerns, testability, and adaptability. Design patterns provide a shared vocabulary and proven solutions to recurring problems. However, blindly applying “textbook” patterns can lead to over‑engineered, rigid systems. As the industry has matured, we now recognize that context is king — the right pattern depends on the problem, the scale, and the team’s expertise.

The Three Pillars of Design Patterns

1. Creational Patterns

These patterns control object creation, aiming to increase flexibility and reduce coupling.

Singleton – Ensures a single instance exists globally.
Factory Method – Delegates instantiation to subclasses.
Abstract Factory – Creates families of related objects.
Builder – Separates construction from representation.
Prototype – Creates objects by cloning.

2. Structural Patterns

These patterns define how objects are composed to form larger structures.

Adapter – Bridges incompatible interfaces.
Decorator – Adds responsibilities dynamically.
Facade – Simplifies complex subsystems.
Proxy – Controls access to another object.
Composite – Treats individual and composite objects uniformly.

3. Behavioral Patterns

These patterns manage communication and responsibility between objects.

Strategy – Encapsulates interchangeable algorithms.
Observer – Notifies dependents of state changes.
Command – Encapsulates requests as objects.
State – Alters behavior when internal state changes.
Chain of Responsibility – Passes requests along a chain.

Patterns That Matter in 2026

Singleton: Still Useful, But Use Sparingly

The Singleton pattern is still relevant for resources that truly require a single instance (e.g., logging, configuration). However, modern .NET encourages dependency injection (DI) as the default mechanism for managing lifetimes. Overusing Singleton can break testability and introduce hidden dependencies. Best practice: Use DI containers (like Microsoft.Extensions.DependencyInjection) to register services as singletons when appropriate, rather than implementing a manual Singleton.

Factory Method & Abstract Factory: Essential for Extensibility

With plug‑in architectures and runtime polymorphism, Factory patterns remain vital. In .NET, they’re often implemented via interfaces and DI. For example, a payment gateway factory can switch between Stripe, PayPal, or a mock implementation based on configuration.

public interface IPaymentProcessor { Task<PaymentResult> ProcessAsync(decimal amount); }
public class StripeProcessor : IPaymentProcessor { /* ... */ }
public class PayPalProcessor : IPaymentProcessor { /* ... */ }

public class PaymentProcessorFactory
{
    private readonly IServiceProvider _serviceProvider;
    public IPaymentProcessor Create(string provider) => 
        provider switch
        {
            "Stripe" => _serviceProvider.GetRequiredService<StripeProcessor>(),
            "PayPal" => _serviceProvider.GetRequiredService<PayPalProcessor>(),
            _ => throw new ArgumentException("Unknown provider")
        };
}

Builder: Fluent APIs and Immutable Objects

The Builder pattern shines when constructing complex objects, especially immutable ones. Modern C# records and init‑only properties pair perfectly with builders. Entity Framework Core’s DbContextOptionsBuilder is a prime example.

Repository & Unit of Work: Overused, Still Valuable

The Repository pattern (abstracting data access) and Unit of Work (transaction management) are ubiquitous in .NET applications. However, they are often misapplied — adding business logic inside repositories violates separation of concerns. Use repositories only as a data‑access abstraction; keep business rules in the domain layer.

Strategy: Dynamic Behavior at Runtime

Strategy is one of the most powerful patterns for modern applications. It eliminates long if‑else chains and enables runtime behavior changes. Discount calculations, caching strategies, and serialization formats are classic use cases.

Observer: Event‑Driven Architectures

With the rise of event‑driven systems, the Observer pattern is more relevant than ever. .NET events, IObservable<T>, and message brokers (RabbitMQ, Azure Service Bus) all leverage this pattern for loose coupling.

Decorator: Cross‑Cutting Concerns

Decorator is ideal for adding cross‑cutting concerns like logging, caching, and authentication. ASP.NET Core middleware uses a similar concept, and the HttpClient pipeline employs DelegatingHandler (a decorator‑like pattern) for retries and circuit breaking.

Performance‑Oriented Patterns

High‑performance .NET applications require patterns that minimize allocations, improve cache locality, and reduce GC pressure.

Pooling (ArrayPool, MemoryPool)

Allocating arrays and buffers in hot paths can cause GC pressure. ArrayPool<T> and MemoryPool<T> provide shared pools of reusable buffers. Benchmark results show 50% reduction in allocations and 30% faster execution when using pooled arrays instead of new byte[].

var pool = ArrayPool<byte>.Shared;
byte[] buffer = pool.Rent(4096);
try
{
    // Use buffer
}
finally
{
    pool.Return(buffer);
}

Struct of Arrays (Data‑Oriented Design)

When processing large collections, an “array of structs” leads to poor cache locality. A “struct of arrays” (SoA) layout can improve performance by 10×. This pattern is used in high‑performance game engines and scientific computing.

public class CustomerRepositoryDOD
{
    private double[] _scoring;
    private double[] _earnings;
    private bool[] _isSmoking;
    // ...
}

Stack‑Based Allocation

stackalloc, Span<T>, and ref struct allow stack allocation, eliminating GC overhead. They are essential for parsing, serialization, and network protocols.

Span<byte> buffer = stackalloc byte[256];
// Process buffer without heap allocations

Zero‑Copy Slicing

Span<T> and Memory<T> enable zero‑copy slicing of arrays, strings, and unmanaged memory. This pattern reduces memory copies and improves throughput in high‑volume scenarios (e.g., HTTP request processing).

Real‑World Usage Examples

Microsoft C# Dev Kit – Replaced C++ with C# for Node.js addons using Native AOT, leveraging design patterns for interop and performance.
ASP.NET Core – Uses ArrayPool for Kestrel’s request/response buffers, reducing GC pauses by 80%.
Entity Framework Core – Implements Unit of Work and Repository patterns internally, with DbContext as the unit of work.
.NET Aspire – Employs microservice patterns (service discovery, health checks) with minimal configuration.
Roslyn – Uses object pooling for syntax nodes, dramatically reducing memory allocation during compilation.

Common Pitfalls and Anti‑Patterns

Singleton overuse – Leads to hidden dependencies and hinders testing.
Repository abuse – Placing business logic in repositories creates “fat repositories” and violates domain‑driven design.
Pattern shopping – Applying a pattern because “it sounds cool” without a concrete problem.
Ignoring performance patterns – Allocating excessively in hot paths causes GC‑induced latency spikes.
Neglecting dependency inversion – Tight coupling between layers makes swapping implementations difficult.

Best Practices for Modern .NET

Prefer composition over inheritance – Use interfaces and DI to assemble objects.
Leverage dependency injection – Let the container manage lifetimes; avoid manual Singletons.
Follow the Dependency Inversion Principle – Depend on abstractions, not concretions.
Choose patterns contextually – Use Singleton for truly single resources, Factory for extensibility, Strategy for runtime behavior.
Measure before optimizing – Use profiling tools (dotTrace, PerfView) to identify bottlenecks.
Embrace modern C# features – Span<T>, Memory<T>, ref struct, and record types enhance pattern implementations.
Document pattern usage – Ensure team members understand the why and how.
Continuously refactor – Patterns should evolve with requirements; don’t let them become constraints.

Conclusion

Design patterns are not obsolete — they have evolved. In 2026, the .NET developer’s toolkit includes powerful frameworks, high‑performance primitives, and cloud‑native patterns. By understanding which patterns still matter and applying them judiciously, you can build maintainable, scalable, and performant systems.

The key is to start with the problem, not the pattern. Let the problem guide your choice, and always consider the trade‑offs. With the right patterns, you can harness the full potential of modern .NET.

Connect with me:
[www.linkedin.com/in/vikrant-bagal]

10 .NET Open Source Libraries Every Developer Should Know in 2026

Vikrant Bagal — Thu, 14 May 2026 15:41:55 +0000

The .NET ecosystem keeps evolving, and 2026 is no exception. Whether you're building APIs, CLIs, or cloud-native microservices, the right open source library can save you weeks of work. Here are 10 libraries that are dominating NuGet downloads and GitHub stars this year—spanning battle-tested essentials to rising stars you'll want on your radar.

1. Polly — Resilience Made Fluent

If your app talks to external services, you need Polly. It provides retry, circuit breaker, timeout, bulkhead isolation, and fallback policies—all composed in a fluent API.

var pipeline = new ResiliencePipelineBuilder<HttpResponseMessage>()
    .AddRetry(new RetryStrategyOptions<HttpResponseMessage>
    {
        MaxRetryAttempts = 3,
        Delay = TimeSpan.FromMilliseconds(500),
        BackoffType = DelayBackoffType.Exponential
    })
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions<HttpResponseMessage>
    {
        FailureRatioThreshold = 0.5,
        SamplingDuration = TimeSpan.FromSeconds(30)
    })
    .Build();

Why it matters: Distributed systems fail. Polly makes your app survive those failures gracefully instead of cascading errors to users.

GitHub: App-vNext/Polly

2. Serilog — Structured Logging That Actually Makes Sense

Forget text-based logging. Serilog emits structured events with properties you can query, filter, and aggregate in tools like Seq, Elasticsearch, or Datadog.

Log.Information("Order {OrderId} placed by {UserId} for ${Total:C}", 
    order.Id, order.UserId, order.Total);

Why it matters: In production, you don't need "something went wrong." You need which order, which user, and what amount. Structured logging gives you that.

GitHub: serilog/serilog

3. FluentValidation — Validation as Code, Not Attributes

Data annotations are fine for simple rules. FluentValidation handles the complex ones—cross-field checks, async database lookups, and reusable rule sets.

public class OrderValidator : AbstractValidator<Order>
{
    public OrderValidator()
    {
        RuleFor(x => x.Items).NotEmpty().WithMessage("Order must have at least one item");
        RuleFor(x => x.Total).GreaterThan(0);
        RuleFor(x => x.ShippingAddress)
            .NotNull().When(x => x.RequiresShipping);
    }
}

Why it matters: Clean validation logic lives in its own class, testable and reusable—not scattered across controllers.

GitHub: FluentValidation/FluentValidation

4. MediatR — Decouple Your App with the Mediator Pattern

MediatR implements the mediator pattern, enabling CQRS-style separation without ceremony. Commands and queries flow through a single pipeline.

// Controller stays thin
[HttpPost]
public async Task<IActionResult> Create(CreateOrderCommand cmd)
    => Ok(await _mediator.Send(cmd));

// Handler lives in its own file
public class CreateOrderHandler : IRequestHandler<CreateOrderCommand, int>
{
    public async Task<int> Handle(CreateOrderCommand request, CancellationToken ct)
    {
        var order = new Order(request.UserId, request.Items);
        await _repo.AddAsync(order, ct);
        return order.Id;
    }
}

Why it matters: Controllers stay thin. Business logic stays isolated. And pipeline behaviors give you cross-cutting concerns (logging, validation) for free.

GitHub: jbogard/MediatR

5. Dapper — When EF Core Is Too Much

Dapper is a micro-ORM that extends IDbConnection with simple mapping methods. It's nearly as fast as raw ADO.NET—because it barely adds overhead.

var products = await connection.QueryAsync<Product>(
    "SELECT * FROM Products WHERE CategoryId = @catId",
    new { catId = 5 });

Why it matters: For high-throughput read scenarios, reporting queries, or when you want full control over your SQL, Dapper is the lightweight choice.

GitHub: DapperLib/Dapper

6. Spectre.Console — Beautiful CLIs Without the Pain

Building console apps used to mean fighting with Console.ForegroundColor. Spectre.Console changes everything with tables, progress bars, trees, prompts, and markup formatting.

AnsiConsole.MarkupLine("[bold green]Build succeeded![/]");
var table = new Table().Border(TableBorder.Rounded);
table.AddColumn("Project");
table.AddColumn("Status");
table.AddRow("API", "[green]✓[/]");
table.AddRow("Worker", "[red]✗[/]");
AnsiConsole.Write(table);

Why it matters: If you're building CLI tools, deployment scripts, or developer utilities, Spectre.Console makes them look professional with minimal effort.

GitHub: spectreconsole/spectre.console

7. TickerQ — Source-Generated Task Scheduling

TickerQ is a new entrant that's rapidly gaining traction. It's a reflection-free background task scheduler built with .NET source generators, EF Core integration, and a real-time dashboard.

[TickerTask("daily-report", Cron = "0 8 * * *")]
public class DailyReportTask : ITickerTask
{
    public async Task ExecuteAsync(CancellationToken ct)
        => await GenerateAndEmailReportAsync(ct);
}

Why it matters: No reflection overhead at runtime. Compile-time validation of cron expressions. And a built-in dashboard to monitor task execution.

GitHub: Arcenox-co/TickerQ

8. TUnit — The Modern .NET Test Framework

TUnit is a source-generated test framework designed to replace xUnit and NUnit. No reflection, no AppDomain complexity—tests are discovered at compile time.

[Test]
public async Task Calculator_Adds_TwoNumbers()
{
    var result = Calculator.Add(2, 3);
    await Assert.That(result).IsEqualTo(5);
}

Why it matters: Faster test discovery, parallel execution by default, and a fluent assertion API that reads naturally.

GitHub: thomhurst/TUnit

9. Facet — Source-Generated DTOs and Mappings

Facet generates DTOs, mappings, constructors, and LINQ projections from your domain models at compile time. No runtime reflection, no runtime mapping overhead.

[Facet(typeof(User))]
public partial class UserDto;
// Generates: UserDto with mapped properties, ToDto(), and LINQ projection support

Why it matters: AutoMapper's runtime mapping has a cost. Facet moves that cost to build time, and gives you LINQ projection support out of the box.

GitHub: Tim-Maes/Facet

10. RazorConsole — Agentic TUIs with .NET

RazorConsole is a 2026 standout. It combines .NET Razor templates with Spectre.Console to build interactive terminal UIs—including agentic TUIs that LLMs can drive.

Why it matters: As AI agents increasingly need to interact with developer tools, having a Razor-based TUI layer means agents can render rich output in terminals programmatically.

GitHub: RazorConsole/RazorConsole

The 2026 Trend: Source Generators Win

Notice the pattern? TickerQ, TUnit, and Facet all leverage .NET source generators instead of runtime reflection. This means:

Zero reflection overhead at runtime
Compile-time validation of configurations
Better AOT compatibility for Native AOT scenarios
IDE IntelliSense for generated code

If you're picking libraries in 2026, prefer the source-generated approach. It's the direction the entire .NET ecosystem is moving.

Which of these libraries are you already using? What did I miss? Drop a comment—I'd love to hear what's in your csproj this year.

Structured Output in .NET Agents

Lukas Walter — Thu, 14 May 2026 13:30:00 +0000

This is Part 8 of my series on the Microsoft Agent Framework. You can read the original post over on lukaswalter.dev.

LLMs are good at generating text. But text is a weak boundary for application code.

Ask a model for e.g., a specific coffee recipe, and the response might look slightly different every time:

a markdown list
a numbered list
bold section titles
missing fields
additional explanations
a disclaimer at the end

That is fine for a chat interface.
It is not, when your application needs to save the result, display it on a UI, route a workflow, or pass the output into another system.

At that point, you do not want “some text”.
You want data with a known shape.

Raw LLM Text Is Hard to Automate

The problem with unstructured output is not that it looks messy.
The problem is that your application has to guess what the model meant.

For example, if the model returns a coffee recipe as plain text, your code may need to extract:

brew method
coffee dose
water amount
grind size
water temperature
brewing steps

That usually means parsing strings.
And string parsing breaks easily.

One response might look like this:

1. V60 recipe: Use 20g coffee and 320g water at 94°C. Grind medium-fine.

The next response might look like this:

### V60 Pour-Over

- Coffee: 20 grams
- Water: 320 grams
- Temperature: 94°C
- Grind: medium-fine

Both are readable for humans.
But for software, they are different formats.
This is why raw LLM text is a fragile integration boundary.

Define the Output Shape in C

Instead of asking the model to return free-form text, you can define the shape you expect in C#.

For example:

public sealed class BrewRecipeSuggestion
{
    public string BrewMethod { get; set; } = string.Empty;
    public double CoffeeGrams { get; set; }
    public double WaterGrams { get; set; }
    public string GrindSize { get; set; } = string.Empty;
    public double WaterTemperatureCelsius { get; set; }
    public List<string> Steps { get; set; } = [];
}

If you want multiple results, you can wrap the list in a response type:

public sealed class BrewRecipeResult
{
    public List<BrewRecipeSuggestion> Recipes { get; set; } = [];
}

Now your application has a contract.
The model is no longer just asked to “write an answer”.
It is requested that something be produced that can be represented as a known C# type.

Using `RunAsync<T>`

With .NET agents, this becomes much cleaner.
Instead of calling the agent and receiving plain text:

var response = await agent.RunAsync(
    "Give me three pour-over coffee recipes.");

You can request a typed result:

AgentResponse<BrewRecipeResult> response =
    await agent.RunAsync<BrewRecipeResult>(
        """
        Give me three pour-over coffee recipes.

        Include:
        - brew method
        - coffee dose in grams
        - water amount in grams
        - grind size
        - water temperature in Celsius
        - brewing steps
        """);

BrewRecipeResult result = response.Result;

The important difference is the boundary.
Your application does not receive a string that it still has to interpret.
It receives an AgentResponse<T>, and the typed result is available through response.Result.

That means you can work with the result directly:

foreach (var recipe in result.Recipes)
{
    Console.WriteLine(
        $"{recipe.BrewMethod}: {recipe.CoffeeGrams}g coffee, " +
        $"{recipe.WaterGrams}g water");
}

This is much easier to use in normal application code.
You can render it in a UI, store it in a database, pass it to another service,validate it and even test it.

What the Framework Does for You

When you call RunAsync<T>, the framework can use the target C# type to describe the expected response shape.
The model is guided toward returning data that matches that structure.
The framework then converts the response into the requested C# type.

Conceptually, the flow looks like this:

C# type
   ↓
Expected response shape
   ↓
Model response
   ↓
Deserialization
   ↓
Typed C# object

That removes a lot of boilerplate.
You do not have to manually inspect markdown, split strings, or have to search for labels in generated text.
You get a typed result that fits into the rest of your .NET code.

Still, keep one thing in mind:

Structured output support can vary by agent type, provider, model, and underlying chat client.
So this is not a reason to stop thinking about validation, fallbacks, and testing.

It is a better application boundary.
Not a replacement for engineering discipline.

What Structured Output Does Not Solve

Structured output solves the shape problem.
It does not solve the truth problem.

A model can return a valid BrewRecipeSuggestion object and still be wrong.

For example:

new BrewRecipeSuggestion
{
    BrewMethod = "V60",
    CoffeeGrams = 12,
    WaterGrams = 1000,
    GrindSize = "very fine",
    WaterTemperatureCelsius = 120,
    Steps =
    [
        "Add coffee.",
        "Pour all water at once.",
        "Wait 30 seconds."
    ]
}

This object may be structurally valid.

It has the expected fields.
It can be deserialized.

Your application can work with it as an object.
But that does not mean it is a good recipe. (The ratio is unrealistic.
The water temperature is impossible for normal brewing.
The steps are questionable.)

Structured output can tell you:

The response has the expected fields
The values can be deserialized
The application can work with the result as an object

It does not guarantee:

The facts are correct
The recommendation is useful
The values are reasonable
The user is allowed to perform the action
The result satisfies your business rules

So keep in mind: typed output should usually be the first gate, not the final gate.

A more robust flow looks like this:

Model output
   ↓
Deserialize into known type
   ↓
Validate required fields
   ↓
Validate ranges and enums
   ↓
Check business rules
   ↓
Accept, reject, retry, or escalate

In this coffee example, you might still check the generated recipe:

private static void Validate(BrewRecipeSuggestion recipe)
{
    if (string.IsNullOrWhiteSpace(recipe.BrewMethod))
    {
        throw new InvalidOperationException("Brew method is required.");
    }

    if (recipe.CoffeeGrams <= 0)
    {
        throw new InvalidOperationException("Coffee dose must be greater than zero.");
    }

    double ratio = recipe.WaterGrams / recipe.CoffeeGrams;

    if (ratio is < 12 or > 20)
    {
        throw new InvalidOperationException(
            "Brew ratio is outside the supported range.");
    }

    if (recipe.WaterTemperatureCelsius is < 85 or > 100)
    {
        throw new InvalidOperationException(
            "Water temperature must be between 85°C and 100°C.");
    }

    if (recipe.Steps.Count == 0)
    {
        throw new InvalidOperationException("At least one brewing step is required.");
    }
}

Structured output makes validation easier.
It does not remove the need for validation.

Practical Example: Intent Routing

One useful pattern is intent routing.

Imagine an assistant that can answer questions about coffee brewing and guitar tone.
A user might ask:

How do I get a dirty Hendrix tone on my Strat?

or:

Can you give me a V60 recipe for 18g of coffee?

You could first send the user request to a small routing agent.
That agent should not answer the question.
It should only classify the intent.

For example:

public enum AssistantIntent
{
    CoffeeBrewing,
    GuitarTone,
    Unknown
}

public sealed class IntentResult
{
    public AssistantIntent Intent { get; set; }
    public double Confidence { get; set; }
    public string Reason { get; set; } = string.Empty;
}

Then you can request a typed result:

string userMessage = "How do I get a dirty Hendrix tone on my Strat?";

AgentResponse<IntentResult> intentResponse =
    await intentAgent.RunAsync<IntentResult>(
        $"""
        Classify the user's request.

        Return only the intent.
        Do not answer the user's question.

        Supported intents:
        - CoffeeBrewing
        - GuitarTone
        - Unknown

        User request:
        {userMessage}
        """);

IntentResult intent = intentResponse.Result;

After that, your C# code stays simple:

var response = intent.Intent switch
{
    AssistantIntent.CoffeeBrewing => await coffeeAgent.RunAsync(userMessage),
    AssistantIntent.GuitarTone => await guitarAgent.RunAsync(userMessage),
    _ => await fallbackAgent.RunAsync(userMessage)
};

This is much cleaner than asking the model to return text like:

The user is probably asking about guitar tone.

and then trying to parse that sentence.

The routing decision becomes a typed value.
Your application code can switch on it.
You can log it, test it and add validation around it.

For example:

if (intent.Confidence is < 0 or > 1)
{
    throw new InvalidOperationException(
        "Intent confidence must be between 0 and 1.");
}

if (intent.Confidence < 0.7)
{
    response = await fallbackAgent.RunAsync(userMessage);
}

Again, the typed object does not make the model perfect.
But it gives your application a reliable shape to work with.

Where Structured Output Fits

Structured output is useful whenever the model response has to cross into application logic.

Common examples:

extracting fields from user input
classifying intent
routing workflows
generating UI-ready data
creating database records
preparing tool arguments
returning validation results
producing evaluation summaries
generating configuration-like output

The pattern is always the same:

Do not let free-form text leak into places where your application expects structured data.
Use a typed boundary.

Conclusion

Structured output is one of the most important patterns when combining LLMs with traditional software systems.
Not because it makes the model perfect.
But because it gives your application a clear contract.

Instead of parsing unstable text, your .NET code can work with known types, which makes the system easier to build, test, and reason about.

LLM output should not be treated as a string once it enters your application boundary.
It should become a typed object.
And from there, normal engineering practices apply again.

We now know that structured output defines how an agent answers.
But useful agents also need ways to access capabilities beyond the current prompt.

In the previous post, we looked at local C# function tools: methods exposed directly from your .NET application.

Next, we will move one step further and look at MCP tools and Agent Skills.
MCP tools expose capabilities from external systems through the Model Context Protocol.
Agent Skills package reusable instructions, domain knowledge, scripts, and procedures that can be loaded when needed.

DEV Community: dotnet

MCP (Model Context Protocol) for .NET Devs — What It Is and Why You'll Be Using It Soon

What Is MCP?

Why MCP Matters for .NET Developers

1. Microsoft's Full Backing

2. Standardized AI Communication

3. Production-Ready .NET SDK

The MCP Architecture

Host

Client

Server

Building Your First MCP Server in .NET

What's happening here?

Exposing Your .NET APIs with MCP

HTTP Transport for ASP.NET Core

Real-World Integrations

Security Considerations

Deployment Options

Local Development

Cloud Deployment

The Future Is Here

Getting Started

Stop putting business logic in your integration layer — here's the pattern we built

The problem nobody wants to admit

The principle: your platform owns the rules

Architecture overview

The full flow: JobSyncCompletedRecords

Endpoint

Step by step

The configuration contract

The recipe: creating a new job in 8 steps

Step 1 — Add the enum value

Step 2 — Expose the route

Step 3 — Create the entry method

Step 4 — Implement the per-client action

Step 5 — Add external system integration methods

Step 6 — Insert the DB config

Step 7 — Observability is not optional

Step 8 — Rollout by config

The observability checklist

The checklist before you ship

Technical

Tests

What we gained

What's next

I spent a year building Apache Camel for .NET. Here's the honest state of it.

The gap

What I built

Production state

What's honest

Three questions I don't have the answer to

Links

PDFmyURL vs IronPDF: an unbiased look for .NET teams

Understanding IronPDF

Key Limitations of PDFmyURL

Product Status

Missing Capabilities

Technical Issues

Support Status

Architecture Problems

Feature Comparison Overview

Code Comparison - Checklist Style

✅ Task: Convert HTML String to PDF

✅ Task: Convert URL to PDF

✅ Task: Batch Convert Multiple HTMLs

✅ Task: Add Watermarks to Generated PDFs

✅ Task: Handle Sensitive Financial Data

API Mapping Reference

Comprehensive Feature Comparison

Installation Comparison

Deployment Checklist Comparison

PDFmyURL Deployment Checklist:

IronPDF Deployment Checklist:

When to Stay with PDFmyURL / When IronPDF is Better

Conclusion

A .NET Dinosaur in Web3. Day 6 - Wishlist or… “Dream Coins True”?

Intro

The Goal

The Contract

Hardhat

The full flow: `JobSyncCompletedRecords`