DEV Community: Michael Jordan

A Pure-C# PDF Toolkit for .NET: Read, Create, Edit, Optimize, Render, Fill Forms — and No Native Dependencies

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 entire PDF engine — parsing, content streams, fonts, and every image codec (baseline and progressive JPEG, JPEG 2000, JBIG2, CCITT G3/G4 fax, LZW, Flate) — is pure managed C#. No vendored native PDF library, no native image decoders.

The first version of this post had an honest asterisk: rendering a page to pixels went through SkiaSharp, which carries a native component, and I wasn't going to pretend otherwise. 2.0 removed the asterisk. Rendering is now a small geometry-only interface the core hands flattened paths to — bring your own target, or use the in-box WPF one, which is managed WPF and ships no native code. The packages you install now have zero native dependencies. More on that below.

And rendering was always the flashy demo, not the point. So let me actually show you the toolkit.

What it does

One core package — Lxman.PdfLibrary — covers the whole document lifecycle, all managed:

Read & extract — parse any PDF 1.x or 2.0; pull text, with positions if you want them.
Create — build documents from scratch with a fluent builder.
Edit — add / remove / reorder / rotate pages, stamp, watermark, annotate, set metadata.
Optimize — losslessly shrink: compression, object/xref streams, font subsetting, optional image recompression.
Fill forms — read and fill AcroForm fields, regenerate appearances, flatten.

Pixels are the one thing that lives in a separate package, because most of the above never needs them.

Extract text

using PdfLibrary.Structure;

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

Edit a document

using PdfLibrary.Structure;

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.Pages.Move(5, 0);      // move the 6th page to the front

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

Fill a form

New and front-and-center in 2.0. Set field values, optionally flatten, save:

using PdfLibrary.Structure;
using PdfLibrary.Editing.Forms;

using var doc = PdfDocument.Load("form.pdf");
var edit = doc.Edit();

((PdfTextField)edit.Forms["applicant.name"]!).Value = "Ada Lovelace";
((PdfButtonField)edit.Forms["subscribe"]!).Check();

edit.Forms.Flatten();   // optional: bake the values into the page
edit.Save("filled.pdf");

Setting a value regenerates the field's appearance stream, so it renders correctly in any viewer afterward. (There's also a pure-WPF viewer in the repo that overlays native controls on the form fields so a person can fill them by hand and hit Save — but that's a post of its own.)

Render — and the "no native dependencies" story

Here's the 2.0 change worth understanding. The core flattens everything — including text, down to glyph outlines — and calls a small interface, IRenderTarget, with nothing but geometry: fill this path, stroke this path, draw this image, set this clip. About seventeen methods, none of which require any PDF knowledge to implement. The hard part — operators, fonts, color, clipping — stays in the core.

That makes rendering bring-your-own:

On Windows, install Lxman.PdfLibrary.Rendering.Wpf and render a page to a retained WPF DrawingGroup — vector, so it's crisp at any zoom — then host it or rasterize it. Managed WPF, no native code.

  using PdfLibrary.Rendering.Wpf;

  using var doc = PdfDocument.Load("input.pdf");
  DrawingGroup page = doc.GetPage(0).RenderToDrawing(scale: 2.0);
  // host `page` in an Image/DrawingImage, or render it into a
  // RenderTargetBitmap and PngBitmapEncoder it to a file.

Anywhere else, implement IRenderTarget against a canvas you already have — SkiaSharp, ImageSharp, System.Drawing, a printer, an SVG writer, a game engine. The repo ships an SVG target as a worked example; it's small.

So the honest breakdown, 2.0 edition:

Parse, extract, create, edit, optimize, fill forms → fully managed, ship no native code.
Render to a vector visual or a bitmap on Windows → Lxman.PdfLibrary.Rendering.Wpf, still no native code.
Render to a raster image cross-platform → you bring the canvas. WPF won't help you on Linux; that's the one line to be precise about. But "implement ~17 geometry methods" is a very different proposition from bundling and P/Invoking a native PDF engine.

No P/Invoke, no SetDllDirectory, no DllNotFoundException at 2am.

Threading

PdfLibrary is built for the one-document-per-request model — the standard ASP.NET Core pattern. Load a PdfDocument per request, work with it, dispose it. 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 across threads. (WPF rendering additionally wants an STA thread, as WPF always does.)

Install

dotnet add package Lxman.PdfLibrary
# rendering on Windows (optional):
dotnet add package Lxman.PdfLibrary.Rendering.Wpf

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.