List & Label vs a Single .NET Library

List & Label is not one product a team licenses. It is a Designer, an optional report server, a Web Report Designer, and a stack of connectors, priced per developer per year. A team that needs little more than data in and a PDF out ends up renting the whole ecosystem to use one corner of it.

List & Label has been shipping since 1992, so plenty of the .NET teams running it today never actually chose it. They inherited it, along with a Designer surface nobody on the current team was hired to learn. The useful way to weigh it against a code-first library like IronPDF is not feature by feature. It is by what each choice puts into the deployment, what it bills every year to keep, and what it costs to walk away from once the author has moved on.

For transparency, our team at Iron Software develops IronPDF. We evaluate architecture and long-term costs, highlighting when List & Label might be the better option.

The smallest thing worth looking at first is how little it ships when IronPDF turns data into a document. There is no Designer to install and no project file to inherit, so a first report is one NuGet package and a handful of lines.

// dotnet add package IronPdf
using IronPdf;

License.LicenseKey = "YOUR-LICENSE-KEY"; // a 30-day trial key works here
var renderer = new ChromePdfRenderer();

PdfDocument notice = renderer.RenderHtmlAsPdf(
    "<h1>Renewal Notice</h1><p>The layout lives in HTML the team already reads, not a designer file one person owns.</p>");
notice.SaveAs("renewal-notice.pdf");

Nothing there is a .lst or .lsr file a new hire has to open in a separate application. ChromePdfRenderer hands the markup to an embedded Chromium build and returns a PDF, so the layout a team maintains as HTML is the layout that ships. Whether that reads as a lean deployment or a missing safety net depends on who authors the reports, which is what the rest of this turns on.

The Ecosystem You Deploy, and the Package You Deploy

The deployment surface is the part teams underestimate, because it stays invisible until an audit or a container rebuild forces someone to list it.

A List & Label deployment carries more than a rendering call. It carries the report definitions, the .lst and .lsr and .lld files that only combit tooling opens. It carries the Report Designer somewhere in the organisation, because a format nobody can edit is a liability rather than an asset. When reports show inside the app, it carries a viewer component across whichever targets a team supports, WinForms, WPF, or the browser-based Web Report Viewer. Each of those is a real capability, and each is one more thing to version, patch, and keep compatible across .NET upgrades for years.

An IronPDF deployment carries the library and a Chromium engine it manages for the team. The report definitions are HTML and CSS files that live in the same repository as the rest of the code, readable in any pull request and blamed in git like anything else. Turning an HTML file into a PDF on the server is the same call whether the markup is a string or a file on disk. The honest trade is that Chromium is memory-hungry by design, so the real capacity question is not whether a page renders correctly but how many concurrent renders a container takes before a team pays for a bigger box. List & Label's report engine is lighter per render. Neither answer is free, and the right one depends on throughput rather than a benchmark headline.

List & Label and IronPDF, Feature by Feature

Here is the head-to-head, kept accurate rather than flattering, with the rows that commit a team the longest sitting near the bottom. The row count leans toward List & Label on purpose, because a fair comparison names what the incumbent does that a library does not.

Dimension	List & Label (combit)	IronPDF
Authoring model	WYSIWYG Report Designer plus Web Report Designer	HTML, CSS, JavaScript, plus Razor
Report definition	.lst and .lsr binaries, combit tooling only	.html or .cshtml, plain text and diffable
Rendering engine	Proprietary report-band engine	Chromium, the engine behind Chrome
End-user self-service authoring	Yes, desktop and browser designers	No
Data-provider breadth	40 plus built-in providers, plus a custom interface	You bind data in your own code
Interactive viewer	Yes, Web Report Viewer and Ad-hoc Designer	No, generation only
Scheduling and distribution	Yes, combit Report Server	Your own job runner calls the renderer
PDF depth (merge, sign, PDF/A, PDF/UA)	Export-focused	Extensive
Deployment surface	Designer, optional Report Server, viewer components	Library plus a managed Chromium engine
Cross-platform (Linux, Docker, macOS)	Cross-platform edition, Enterprise only	Full, included in every tier
Licensing model	Per developer, per year (EUR)	Perpetual, per developer

Table 1. A capability comparison rather than a scoreboard, where List & Label leads on authoring, data breadth, and distribution while IronPDF leads on rendering fidelity, manipulation depth, and deployment simplicity.

Per-Developer, Per-Year, and the Three-Year Math

Cost is where the two models diverge most, and the shape of the bill matters more than any current figure, because figures move and the shape is what a team lives inside.

List & Label is sold per developer, per year, across three editions, priced in euros on the combit pricing pages. Standard lands around EUR 740 per developer for the first year and roughly half that on renewal, Professional near EUR 1,390 first year adds the bilingual designer and 2D barcodes, and Enterprise near EUR 1,990 first year adds cross-platform support, the Web Report Designer, and the Report Server. Every developer who touches the codebase needs a seat, so the tool bills for people who will never open the Designer on purpose, and volume discounts start at three or more developers.

IronPDF uses perpetual per-developer licensing instead, where a version is bought once and owned, with a full-function trial to evaluate first and no renewal required to keep the version bought. Because exact numbers age, the live tiers sit on the IronPDF licensing page rather than in a snapshot here. The trade cuts both ways. An annual subscription keeps a team on combit's newest Designer release automatically and never strands anyone on an unsupported version, and it also never stops charging, so a five-person team pays five seats every year whether or not the reporting changed. A perpetual license is a larger one-time commitment that then belongs to the team, and a version that ages unless a later purchase refreshes it. Where the crossover lands is a function of team stability, and a small, steady team that stopped changing its reports tends to come out ahead on perpetual across a three-to-five-year horizon.

When List & Label Is the Right Call

IronPDF does not win every scenario, and stating the cases where List & Label is the better buy matters more than winning the comparison, because a migration that fights the actual requirement costs more than the license it was meant to save.

• ✅ Non-developers design the reports. The desktop WYSIWYG Designer, shipping since the 1990s, hands layout to business analysts and customers through a code-free workflow, and a developer-written HTML template does not give that authorship back.
• ✅ A scheduled distribution server is a hard requirement. The combit Report Server schedules jobs and delivers output over email, FTP or SFTP, Amazon S3, OneDrive, Google Drive, Dropbox, or webhooks from a browser console, which a rendering library does not pretend to offer.
• ✅ You want a modern in-browser design surface. The Web Report Designer is a web-component designer that drops into React, Angular, or Vue front ends and redistributes to end users royalty-free.
• ✅ Deep, pre-built connectors save real work. More than forty providers cover SQL Server, PostgreSQL, MySQL, Oracle, DB2, and MongoDB, plus a custom IDataProvider for anything left over, and recent versions add an AI$() formula built on Microsoft's Semantic Kernel for translation or summarization inside the layout.

When two or more of those describe the project, staying on List & Label is the cheaper decision over any horizon, and the recurring subscription is buying something the team genuinely uses.

Porting a .lst Report to HTML

A large share of production reporting is not interactive at all. It is a scheduled job or an API endpoint turning data into a PDF nobody opens in a designer. When that is the real workload, the concept mapping off the proprietary format is small, and the mapping doubles as the exit cost of leaving it behind.

What leaves the deployment	List & Label	IronPDF
Report definition	.lst or .lsr binary	.html or .cshtml in source control
Load and render	ll.Design.LoadFromFile(path)	Build the HTML string or file directly
Export to PDF	ll.Export(ExportTarget.Pdf, ...)	renderer.RenderHtmlAsPdf(html).SaveAs(path)
Export to bytes	Export to a stream target	RenderHtmlAsPdf(html).BinaryData
Async rendering	Not the primary workflow	await renderer.RenderHtmlAsPdfAsync(html)
Page header and footer	Report bands	RenderingOptions.TextHeader or HtmlHeader
Page numbers	Field bound to page info	{page} and {total-pages} placeholders
Data binding	IDataProvider in the Designer	Your own template, Razor or loops

Table 2. What actually leaves the deployment on the way out of the proprietary format, direct where the models line up and candid where re-authoring is the real cost.

The first question a migrating team asks is whether footers and page numbers still work, so the sample below wires both in before anything else. The rows would come from EF Core, Dapper, or any data layer already in the app.

// CustomerStatement.cs (.NET 10)
using IronPdf;
using System.Text;

var lineItems = new[]
{
    new { Description = "Consulting, October",  Hours = 24, Rate = 185.00m },
    new { Description = "Consulting, November", Hours = 31, Rate = 185.00m },
    new { Description = "On-site workshop",     Hours = 8,  Rate = 225.00m },
};

// Build the report body as ordinary HTML and reuse existing site CSS if you like.
var body = new StringBuilder(
    "<h1>Customer Statement</h1>" +
    "<table><thead><tr><th>Description</th><th>Hours</th><th>Rate</th><th>Total</th></tr></thead><tbody>");

foreach (var item in lineItems)
    body.Append($"<tr><td>{item.Description}</td><td>{item.Hours}</td><td>{item.Rate:C}</td><td>{item.Hours * item.Rate:C}</td></tr>");

body.Append("</tbody></table>");

var renderer = new ChromePdfRenderer();

// A running footer with real page numbers, the report-band equivalent.
renderer.RenderingOptions.TextFooter = new TextHeaderFooter
{
    LeftText        = "Confidential, Contoso Consulting",
    RightText       = "Page {page} of {total-pages}",
    DrawDividerLine = true
};
renderer.RenderingOptions.MarginTop = 20;
renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

PdfDocument statement = renderer.RenderHtmlAsPdf(body.ToString());
statement.SaveAs("customer-statement.pdf");

TextHeaderFooter supplies the running band, and the {page} and {total-pages} placeholders resolve per page at render time, so pagination is handled without extra work. Richer layouts swap TextFooter for an HtmlHeaderFooter and use full markup, and the headers and footers how-to goes deeper on both. When the original reports were already close to HTML in spirit, Razor views render straight to PDF with the same shape.

For a batch job, the rendering is async so a worker can stream a run of statements without blocking, and the loop owns nothing but code the team can read.

using IronPdf;

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.TextFooter.RightText = "Page {page} of {total-pages}";

foreach (var account in await billing.GetActiveAccountsAsync())
{
    string html = StatementTemplate.Build(account); // Razor or plain string composition
    PdfDocument pdf = await renderer.RenderHtmlAsPdfAsync(html);
    pdf.SaveAs($"statement-{account.Number}.pdf");
}

For most tabular output, invoices, statements, audit summaries, translating a layout into HTML is a small task once the data is reachable in code. Reports with heavy grouping or Designer-built subreports carry more of that one-time cost, because those concepts have no one-line HTML equivalent and have to be rebuilt rather than mapped. Two pieces have no automatic equivalent either, end-user self-service authoring and scheduled distribution, so the plan is either a lightweight admin screen for report tweaks or a scheduler the team already runs. IronPDF is also a deeper PDF toolkit past rendering, with PDF/UA accessibility and PDF/A archival compliance for long-term storage. Recent releases also added signing over a hardware token and fine-grained compression, the kind of manipulation a reporting SDK's export pipeline rarely reaches for.

Platform or Package, and When Each Wins

After the deployment, the renewal, and the exit are all on the table, the decision usually resolves into one of three paths.

• 🚀 Stay with List & Label when non-developers design the reports, when a browser-based interactive viewer with an ad-hoc designer is part of the spec, when a scheduled Report Server delivering to email, FTP, or S3 is a hard requirement, or when one engine already spans Delphi, Java, and .NET. The subscription is buying something used.
• 💡 Move to IronPDF when reports are code-driven and HTML-based, when existing web templates can be reused, when the deployment targets Linux or containers, or when a perpetual license beats renewing seats that keep charging after the reports stopped changing.
• ⚠️ Run both, which is more common than teams expect. Some keep List & Label for interactive, business-authored reports and add IronPDF for high-volume, server-side jobs that never touch a designer.

The thread through all three is that the word reporting hides two different commitments, one where a person owns the layout in a design surface and one where code owns it as text, and the commitment a team actually has decides which one is cheaper to carry for years.

What does your production reporting look like once you strip away the demo, are the .lst files still opened and edited by a person each quarter, or have they quietly become a scheduled job writing PDFs that nobody views in a designer? Tell us in the comments, because that answer decides the whole thing.

If it is the second, we think a short prototype is worth running before the next renewal decides for you. Start a trial, point ChromePdfRenderer at one existing report template on current .NET 10, and see how close the first render lands, because that one experiment answers the ownership question better than any table here, including ours.

List & Label and combit are trademarks of combit GmbH. We have no affiliation with combit, and the details above rest on their public documentation. If we have a detail wrong, tell us in the comments and we will correct it.