COMPANY NEWS

Inside Jeff Fritz's beginner .NET workshop: a clean approach to PDF reporting

Updated:

Most developers, the first time they have to add PDF reporting to an internal app, lose a day.

They try the browser print dialog. The output looks wrong. They try a client-side PDF library. The layout breaks. They hand-roll something with positioned text and absolute coordinates. It works for one report and falls apart for the next. By the time they ship the feature, they've burned eight hours on a problem that should have taken twenty minutes.

Jeff Fritz showed a room full of beginners how to do it in twenty minutes.

The workshop

If you don't know Jeff Fritz: he's a Microsoft MVP, a Principal Program Manager at Microsoft, and host of the long-running Fritz and Friends stream. He runs free workshops for developers who are early in their .NET journey, and a few weeks ago he ran one of the most ambitious: a five-hour live build covering HTML, CSS, C#, Blazor, ASP.NET, and .NET Aspire, with the whole group building a working collection-tracking application from the ground up.

Four hours in, the application needed PDF reports. A user should be able to click a button and get a clean, downloadable PDF of their collection. Real-world internal-tool stuff. The kind of feature every product manager eventually asks for and every developer eventually has to ship.

The pattern Jeff teaches is the one most teams should be using, and it's worth unpacking because once you see it, you stop reaching for the wrong tools.

Install IronPDF for Free

Jeff Fritz IronPDF workshop — beginner .NET live build

The five-step pattern

Here's the shape of it. It's deceptively short.

  1. A dedicated Razor page for the report. Jeff creates Report.razor inside the project's Pages directory. Small choice, big payoff, keeping the report as its own page means it can be styled, regenerated, and tested independently of the rest of the UI. The report becomes a first-class part of the application, not a hack bolted onto another view.

  2. Inject the data context. The Entity Framework Core CollectionContext factory comes in through dependency injection, exactly like every other data-fetching point in the application. No special pattern, no workaround, no separate data path just for reports. The report uses the same data the rest of the app uses, the same way.

  3. Render the report as HTML. This is the move that separates a good pattern from a brittle one. Jeff doesn't reach for a PDF-specific layout language. He writes the report as HTML, the same markup he's been using all afternoon and lets the existing styling work. Headers, tables, sections, all in HTML. The fact that the final output is a PDF is a detail that comes later.

  4. Convert HTML to PDF with one line. This is where IronPDF earns its place. ChromePdfRenderer takes the HTML string and produces a real, properly-rendered PDF using a Chrome engine under the hood. CSS that looks right in the browser looks right in the PDF. No separate styling layer to learn, no rendering quirks to debug.

  5. Return it as a file. The browser downloads the PDF cleanly when the user clicks the button. Done. Feature shipped.

The five-step PDF reporting pattern from Jeff Fritz's .NET workshop

That's the entire pattern. Five steps, twenty minutes of stream time, and a feature that holds up in production.

Why this works

The deeper reason this pattern is the right one is durability but the surface reason is that every step maps to something the developer already knows how to do.

Writing the report layout? That's HTML and CSS, same as every other page. Querying the data? Same EF Core pattern. Wiring the page into the app? Same Razor pages, same DI. The only genuinely new step is the conversion to PDF, and that's one line.

Compare that to the alternatives. Print-dialog approaches break the moment a user has a different browser, a different zoom level, or an unexpected printer setting. Client-side PDF libraries force the developer to learn an entirely new layout language. Hand-rolled coordinate-based layout works for one report and collapses on the second. None of those approaches survive contact with a real product.

The server-side HTML-to-PDF pattern survives. The output is consistent, deterministic, and centralised, the same input produces the same PDF every time, on every client, because the rendering happens in one place under one set of rules. For internal tools, customer-facing reports, audit-trail documents, anywhere output consistency actually matters, this is the pattern that holds up.

This workshop teaches it cleanly because it doesn't have time to teach it any other way.

Try it in your own project

IronPDF free trial — build the PDF pattern from Jeff Fritz's workshop

The library Jeff uses for the conversion step, IronPDF, is free to try with a 30-day trial key. Register with a business email, the key arrives in your inbox, and you can build the exact pattern Jeff Fritz teaches in your own project before the afternoon is out. No watermarks during the trial, full feature access, every API available.

If you've been putting off adding PDF reporting because the last time you tried it took a day, this is the version of the project that takes twenty minutes.

Start your free IronPDF trial

Watch the full workshop

Jeff's complete session is on his YouTube channel. The PDF reporting segment begins at 4:56:48, but the earlier modules are worth your time too, they're a clean ramp through the modern .NET stack, and Jeff's teaching is genuinely good.

Watch on YouTube