DEV Community: Michael Jordan

Render a PDF to an image in .NET — with a pure-C# PDF engine

Michael Jordan — Wed, 24 Jun 2026 19:51:33 +0000

Most PDF libraries in .NET are wrappers. PDFium, MuPDF, Ghostscript — solid engines, but they ship native binaries you P/Invoke into. That buys you per-RID packages, Native AOT friction, the "works on my box, throws DllNotFoundException in the Alpine container" dance, and a deployment story that's never quite boring.

PdfLibrary takes the other road: the PDF engine and every image codec are pure managed C#. No vendored native PDF library, no native image decoders. I'll be precise about the one native piece (SkiaSharp, for rasterization) further down — because a "no native dependencies" claim that quietly ignores SkiaSharp would be a lie, and you'd find out the first time you deployed.

Here's the part you came for — rendering the first page of a PDF to a PNG:

using PdfLibrary.Structure;
using PdfLibrary.Rendering.SkiaSharp;

using var document = PdfDocument.Load("input.pdf");

document.GetPage(0)                 // 0-based page index
    .Render(document)
    .WithDpi(150)
    .ToFile("page1.png");

That's it. No engine init, no global handle to dispose, no SetDllDirectory.

Install

dotnet add package Lxman.PdfLibrary
dotnet add package Lxman.PdfLibrary.Rendering.SkiaSharp

The core package parses, creates, edits, and optimizes PDFs. The .Rendering.SkiaSharp package is the rasterization backend — add it only when you actually need pixels.

A bit more control

using var document = PdfDocument.Load("input.pdf");
var page = document.GetPage(0);

// High-DPI render with a custom background, straight to an SKImage
using var image = page.Render(document)
    .WithDpi(300)
    .WithBackgroundColor(new SKColor(255, 250, 240))   // antique white
    .ToImage();

// Or render just a region of the page
using var crop = page.Render(document)
    .WithScale(2.0)
    .WithCropBox(100, 100, 400, 600)                   // x, y, width, height
    .ToImage();

.WithScale(1.0) is 72 DPI (1 PDF point = 1 pixel); .WithDpi(n) is the same knob expressed the way you usually think about it.

The honest "no native dependencies" section

This matters, so here's the exact breakdown:

Lxman.PdfLibrary (core) — parsing, content streams, fonts, and all image decoding are 100% managed C#. That includes the codecs people usually reach for a native lib to handle: baseline and progressive JPEG, JPEG 2000, JBIG2, CCITT Group 3/4 fax, LZW, and Flate. Zero native dependencies.
Lxman.PdfLibrary.Rendering.SkiaSharp (rasterizer) — uses SkiaSharp as the 2D canvas to turn the parsed page into pixels. SkiaSharp carries a native component.

So the rule of thumb:

Parsing, text extraction, editing, optimizing → fully managed, ship no native code.
Rasterizing a page to an image → add SkiaSharp.

SkiaSharp is a well-behaved, broadly-supported cross-platform dependency, so this is a very different proposition from bundling and P/Invoking a PDF engine yourself — but it's not nothing, and you should know exactly where the line is.

It's not just a renderer

Rendering is the flashy demo, but the managed core is the actual point. A few things that need only the core package (no SkiaSharp):

Extract text:

using var doc = PdfDocument.Load("input.pdf");
string text = doc.GetPage(0).ExtractText(doc);

Edit an existing document:

using PdfLibrary.Editing;

using var doc = PdfDocument.Load("input.pdf");
var edit = doc.Edit();
edit.Pages.RemoveAt(2);     // delete the 3rd page
edit.Pages.Rotate(0, 90);   // rotate the 1st page 90°
edit.Save("edited.pdf");

Optimize / shrink:

using PdfLibrary.Optimization;

using var doc = PdfDocument.Load("input.pdf");
using var output = File.Create("optimized.pdf");
PdfOptimizer.Optimize(doc, output);   // lossless by default

Threading

PdfLibrary is built for the one-document-per-request model — the standard pattern for ASP.NET Core. Load a PdfDocument per request, render it on its own target, dispose both. Under that model it's thread-safe, and the process-wide caches (glyph paths, font resolution, ICC profiles) are synchronized. The one thing you must not do is share a single PdfDocument (or a SkiaSharpRenderTarget) across threads.

MongoDB-backed ASP.NET Core Identity, without the EF Core detour

Michael Jordan — Wed, 24 Jun 2026 19:42:41 +0000

If you're already running MongoDB and you reach for ASP.NET Core Identity, the
official story points you at Entity Framework Core. That's a fine answer if you
have a relational database. If you don't, you end up bolting a second data
access stack onto an app that has exactly one store. You don't need it.

AspNetCoreIdentity.MongoDriver is a store provider that talks to Mongo through
the official MongoDB.Driver directly — no EF Core, no SQL, no second
persistence model. It implements the Identity store interfaces, ships a
UserStore and RoleStore, and wires up UserManager/RoleManager the way
you already expect.

The 15-line version

builder.Services.AddIdentityMongoDbProvider<MongoUser<Guid>, MongoRole<Guid>, Guid>(identity =>
{
    identity.User.RequireUniqueEmail = true;
}, mongo =>
{
    mongo.ConnectionString = builder.Configuration.GetConnectionString("MongoDb")!;
});

A connection string like mongodb://localhost:27017/Identity creates an
Identity database and stores the collections there. That's the whole setup.
Now inject the managers wherever you need them:

public class AccountController(UserManager<MongoUser<Guid>> userManager) : Controller
{
    // ...
}

They're registered as scoped services — let the container manage their
lifetime. Don't call BuildServiceProvider() yourself, and don't cache the
managers in long-lived objects.

Your key type is yours

The MongoUser and MongoRole classes are generic, so the primary key isn't
forced to be a Guid. Want string keys? Use MongoUser<string>. If you use
string keys and don't assign an Id on create, the store generates an
ObjectId-style string for you.

If you do go with Guid, register the serializer once before the code above so
Mongo stores them in the standard representation:

BsonSerializer.RegisterSerializer(new GuidSerializer(GuidRepresentation.Standard));

Migrations that survive a rolling deploy

Here's the part that usually bites people who hand-roll a Mongo store. On the
first store operation — not during service registration — the library:

applies any pending schema migrations, guarded by a distributed lock so that if several app instances boot at once, the migrations apply exactly once; and
creates its indexes: a unique index on NormalizedUserName, an index on NormalizedEmail, a compound index on Logins.LoginProvider / Logins.ProviderKey, and a unique index on the role NormalizedName.

That distributed lock matters the moment you run more than one instance. Two
pods starting simultaneously won't race each other into a half-applied schema.

Because the NormalizedUserName index enforces real uniqueness, index creation
will fail if your existing data already contains duplicate user names — clean
those up before you upgrade. If you'd rather own these concerns yourself, set
mongo.DisableIndexCreation = true and/or mongo.DisableAutoMigrations = true.
And if you want the work done at startup instead of on first request, resolve
MongoIdentityInitializer and await EnsureInitializedAsync().

It won't silently clobber concurrent writes

Updates and deletes use optimistic concurrency through Identity's
ConcurrencyStamp. If the document changed since you loaded your copy, the
operation returns a ConcurrencyFailure instead of overwriting the other
write. Reload, reapply, retry — the normal Identity dance.

One honest limitation

options.Stores.ProtectPersonalData is not supported. The store doesn't
encrypt personal data at rest, and rather than letting you flip that switch and
quietly store unprotected data anyway, enabling it throws at runtime. If you
need encryption-at-rest for PII, handle it at a different layer.

Try it

dotnet add package AspNetCoreIdentity.MongoDriver

If you're on Mongo and Identity, this is the short path. Issues and PRs welcome.