ActiveReports in 2026: Three Report Models, One-Way Door

Pick Section, Page, or RDL on the first day of a project and you have made a decision the platform will not hand back cleanly. All three are supported. All three are documented. Conversion between them exists. What conversion does not do is round-trip, and the losses are specific enough that the choice behaves less like a setting and more like an architecture. That is a normal cost for a reporting platform and an odd one for a service whose only real output is a PDF built from markup.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where ActiveReports' one-way report-model choice and Professional-tier gating cost a team, and where IronPDF produces the same document with no model to pick.

One naming note first, because it affects what you can even search for. The product was built by Data Dynamics, acquired by GrapeCity in 2008, and GrapeCity became MESCIUS in 2023. Documentation, release notes, and vulnerability records are indexed under all three names.

Section, Page, and RDL Are Not Interchangeable

The three models are deliberate rather than historical. A Section report is banded and event-driven, with script-level layout control. A Page report fixes control position and size for pixel-accurate output. An RDL report lets controls grow and paginate continuously and shares a wire format with Microsoft's RDL, which helps if an SSRS estate already exists nearby.

Converting between them is where the commitment shows. MESCIUS documents the Section-to-Page and Section-to-RDL paths as one-directional, and its migration documentation lists what does not survive.

• The whole report collapses into one control: the entire Section report is converted to an RDL report as the BandedList control, with PageHeader and PageFooter sections created automatically and required to stay even when empty.
• Three control types drop to basic behaviour: support for Chart, Subreport, and RichTextBox controls during conversion is limited to basic functionality, unused database fields are not imported, and calculated fields become simple expressions.
• Some things do not come across at all: ActiveReports does not carry PageBreak, CrossSectionLine, or CrossSectionBox controls into the converted report, and cannot bring PageTotal and PageCount summary functions or Visual Basic functions with them.
• Run-time layout control goes away: manipulating the report or its controls at run time through events, and changing Size, Location, ShrinkToFit, or Margins during execution, is not carried into the Page or RDL model.

A team that picks Section for its scripting power and later needs RDL's continuous pagination is therefore rebuilding rather than converting. In a workload where the only requirement is a document coming out the other end, that entire decision tree is overhead, because IronPDF treats page breaks as a CSS property rather than a report model.

What the Authoring Layer Buys

That same decision tree is also the product's strongest argument.

Three distinct authoring shapes beat one model stretched to cover everything, and the export pipeline matches that range. From a single definition, ActiveReports produces PDF with PDF/A archival conformance, digital signatures, AcroForms, and encryption, plus XLSX, DOCX, HTML, the major image formats, and structured JSON, XML, and CSV. Version 20, released 26 February 2026, added .NET 10 and Visual Studio 2026 support, a Direct2D print pipeline, design-time support for code-based Section reports in .NET 8 and later projects, and a redesigned configuration system. MESCIUS has also committed publicly to shipping a service pack or hotfix each November or early December to track new .NET and Visual Studio releases. IronPDF reaches PDF/A, signing, AcroForms, and encryption from one licence, with no tier holding the signature back.

The tier line is where cost enters. MESCIUS lists ActiveReports.NET Standard at $899 per developer annually and Professional at $1,399, and Professional is where the embeddable end-user report designers, the standalone desktop designer, the JS-based web report viewer, and advanced PDF exports with timestamps and digital signatures live. Standard excludes all of it. For a PDF-only deployment that never opens a designer, the interesting question is which of those two invoices the workload actually justifies, and that tier split is the ceiling of what the platform covers, because IronPDF answers the same requirement on one.

Which ActiveReports Version Closes the Two Critical CVEs?

Two confirmed critical vulnerabilities sit on the product's current record, both against ActiveReports.NET specifically, and the public databases disagree about their status in a way that matters operationally.

CVE-2025-6810 is a deserialization flaw in the ReadValue method and CVE-2025-6811 is the same bug class in the TypeResolutionService class. Both are CWE-502, both scored 9.8 by the Zero Day Initiative as CNA, and both published by NVD on 7 July 2025 against version 18.1.1. NVD's entries list no affected range beyond 18.1.1, no fixed version, and no vendor advisory. The current information sits with ZDI instead, where advisories ZDI-25-448 and ZDI-25-449 record that the issues were reported to the vendor on 8 November 2024, went to coordinated public release on 19 December 2025, and were updated on 19 May 2026 to note that MESCIUS published a fix in ActiveReports v20 on 18 May 2026.

Read those two records together and the practical instruction is to check the installed version against v20 directly rather than trusting NVD's fixed-version field, which is still blank. Anything on 18.1.1 or an early 19.x build should be treated as reachable. Nothing else is confirmed against the product's own code in NVD, the GitHub Advisory Database, or Snyk, and the vendor did ship a fix. What a team signs up for is the ongoing job of tracking a vendor fix through a database that has not caught up, on a deserialization surface IronPDF's rendering and encryption path never exposes.

Where the Two Meet on the File

Scoped to the step where a document becomes a file.

Capability (document output only)	ActiveReports.NET	IronPDF
Produces a PDF	Native export, all editions	ChromePdfRenderer.RenderHtmlAsPdf from markup, a file, or a URL
HTML in the document body	FormattedText and RichTextBox tag interpreter, unlisted tags ignored	Chromium rendering of the HTML and CSS a template already uses
Digital signatures and advanced PDF export	Professional tier, $1,399 per developer per year	1 licence, PdfSignature included
PDF/A archival export	Yes	Yes, PDF/A conversion on the same object
Password protection and permission flags	Native	Native, on the returned object
Editing or merging a third-party PDF	Report-to-PDF pipeline, no manipulation API	PdfDocument.Merge, split, stamp, re-save
Report designer, parameter prompts, scheduled distribution	Yes, the platform's core value	0 designer tiers to buy into

Table 1. Document output only, ActiveReports.NET against IronPDF, excluding the designer, data binding, and scheduling.

The HTML row understates the distance. MESCIUS's own documentation says the FormattedText control supports almost all HTML tags and attributes from the XHTML 1.1 specification with some extensions partially supporting HTML5, and that valid tags outside the supported list are ignored. A template written against a 2026 stylesheet is not partially rendered by that interpreter, it is quietly filtered, where IronPDF renders the same file as the browser drew it.

No Report Model, No Conversion to Regret

When the deliverable is a document and the content already exists as markup, there is no model to pick and no conversion to plan for.

using IronPdf;

var invoiceRenderer = new ChromePdfRenderer();
using PdfDocument invoice = invoiceRenderer.RenderHtmlAsPdf(invoiceHtml);

// Distribution copy, restricting edits without blocking the recipient from opening it
invoice.SecuritySettings.UserPassword = distributionPassword;
invoice.SaveAs("invoice-2026-08.pdf");

IronPDF returns a password-protected PDF with selectable text and the template's own layout, from one call on Windows, on Linux, and in a container. The .cshtml case is one call away too, since the same renderer takes a Razor view directly.

Everything before that step is ActiveReports territory and stays there. There is no report designer here, no RDL support, no parameter prompts, no cross-tab or drill-down authoring, and no scheduled distribution. The ceiling on ActiveReports is narrower than a feature list suggests, because the model choice, the tier decision, and the tag interpreter all apply equally to a pipeline that only calls the export method. Most teams running both split it that way, and the renderer-side pattern is worked through here. IronPDF has a free trial for putting one of your existing report outputs through it before deciding.

Has anyone here actually converted a Section report to RDL in anger? Tell us in the comments how much of it survived, because the documented loss list and the lived experience of that migration are not always the same length.

ActiveReports, MESCIUS, and GrapeCity are trademarks of their owners and this piece is not affiliated with the company. The pricing, migration behaviour, release, and CVE details above are drawn from MESCIUS's own documentation, NVD, and the Zero Day Initiative as they stood at the time of writing. If a detail has changed since, correct us in the comments.