DEV Community: IronSoftware

Stimulsoft's AllowHtmlTags Is Not a Rendering Engine

IronSoftware — Sun, 30 Aug 2026 16:06:20 +0000

Two ways to get markup into a document, and only one of them is what most people mean by the phrase.

// Report engine: a boolean on a text field, and an interpreter behind it
invoiceHeader.AllowHtmlTags = true;
invoiceHeader.Text = "<b>Invoice</b> <font-size=\"14\">2026-08</font-size>";

// Rendering engine: the page itself, stylesheet and all
using PdfDocument invoice = new ChromePdfRenderer().RenderHtmlAsPdf(invoiceHtml);

Both lines put styled content on a page. The first accepts a fixed list of inline tags inside one field. The second hands the whole document to a browser. Confusing them turns an existing library of HTML templates into a redesign nobody scheduled.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Stimulsoft's 21-tag interpreter and per-runtime SKUs cost a team, and where IronPDF renders the whole stylesheet from one licence.

A Tag Property Is Not a Rendering Engine

Stimulsoft's AllowHtmlTags documentation lists what a text component accepts, namely b, i, u, s, sub, sup, strong, em, strike, color, background-color, font, font-face, font-name, font-family, font-size, font-color, letter-spacing, word-spacing, line-height, and text-align. Twenty-one tags, all inline text formatting, and the documentation is explicit that ordered and unordered list tags are among the exceptions that are not supported. Tags may appear only in the Text property of a Text component, not anywhere else in the report.

As bold, colour, and spacing inside a report field, that is a reasonable feature and what it was built for. As an HTML path, the gaps are structural rather than cosmetic, because what a browser engine accepts includes external stylesheets, CSS layout, and script execution, and none of the three exist here. A team with existing email templates rebuilds the layout inside the designer using report objects, then maintains two versions of the same document, one for the browser and one for the report. IronPDF takes the browser version and stops there.

How Far Does One Report Definition Travel?

The cross-platform claim is the strongest thing about the product, and it holds. The engine is split into separate products by runtime, with Reports.NET for WinForms and classic ASP.NET, Reports.WEB for ASP.NET Core, MVC, Blazor, and Angular across .NET 6 through .NET 10, plus Reports.JS, Reports.JAVA, Reports.PHP, and Reports.PYTHON, and a single .mrt or .mrz definition moves between them without a rebuild. For a team shipping the same report layout to a desktop client and a web front end, that is design work done once instead of twice. IronPDF covers the whole .NET side of that spread from one package, so the template never needs porting between SKUs.

Its standalone Designer is cross-platform too, shipping as a Windows executable, a macOS .dmg, Linux .rpm and .deb packages, and a browser-hosted version, where most competing designers are Windows-only with a separately sold, feature-reduced web viewer alongside. Version 2026.3 landed in July 2026 on a predictable quarterly cadence, adding real-time shared report editing, a Vue.js viewer, IntelliSense in the Windows standalone designer, and new chart types. The runtime grant is perpetual rather than a pure subscription, meaning a licence keeps working after the update-and-support window lapses, and no royalties are owed for the report engine or the embedded designer at runtime. That grant is the ceiling of what the SKU covers, because an IronPDF template is the HTML a team already maintains, with nothing to install on any of the three.

Tag Interpreter Against Browser Engine

Scoped to the slice where both tools produce a file.

Capability (document output only)	Stimulsoft Reports	IronPDF
HTML tags accepted in a text field	21 inline tags, list tags excluded	0 excluded, `<table>`, `<ul>`, Grid, and Flexbox
Encryption and permissions	40-, 128-, and 256-bit with user and owner passwords	128- and 256-bit AES, with permission flags
Certificate-based signatures	Signature fields on export	`PdfSignature` on the returned `PdfDocument`
PDF/A export	Supported, with layers dropped in PDF/A mode	Supported, layers preserved
Merging or stamping an existing PDF	Outside the report engine	`PdfDocument.Merge` and split
Producing a PDF without a designer file	Built around authoring an `.mrt` or `.mrz` template first	Code-first, markup or a URL in, `PdfDocument` out

Table 1. Document output only, Stimulsoft Reports against IronPDF, excluding the designer and data-binding surface.

The PDF/A row is the fairest one in the table, because Stimulsoft supports the format with one documented behaviour to plan around rather than a gap, while IronPDF keeps the layers.

Which SKU Decides Your Operating System?

Three constraints follow from how the product is packaged, and all three are purchase-time decisions rather than configuration.

Reports.NET and Reports.WEB are licensed separately: needing both a desktop and a web front end means buying two products or stepping up to the Ultimate bundle. Tiers run Single for one developer, Team for up to four, Enterprise for up to fifteen, and WorldWide for unlimited, with Team and above including one build server licence. Prices move, so check the current figures. The structure is the part that matters, because the SKU count is set by your architecture rather than your headcount.
The SKU also decides the container story: Stimulsoft.Drawing, the cross-platform drawing engine built on ImageSharp and SixLabors Fonts to replace the Windows-only System.Drawing, ships in the .NET Core product packages, meaning Reports.WEB and Dashboards.WEB, Reports.BLAZOR and Dashboards.BLAZOR, and Reports.ANGULAR. Reports.NET is not among them. Which package was licensed therefore decides whether a Linux container is a supported target at all, and that is an awkward thing to discover after procurement.
A licence key gates initialization: report and dashboard components need a key registered through StiLicense.Key or a LoadFrom* call before they initialize, and Stimulsoft's own evaluation-limitations documentation confirms that without one a watermark prints on every report page and dashboard panel. That makes secret management a startup-path concern, re-verified on every deployment target the report runs on, in a way a runtime key applied once in code is not.

The CVE record needs the same care as the SKU list, because the vendor name spans several codebases. Four advisories attach to the 2023.1 line. CVE-2023-25261 at 9.8 allows arbitrary local file read and write through included source code, against Designer Desktop 2023.1.4 and Designer Web and Viewer Web 2023.1.3. CVE-2023-25260 at 7.5 is local file inclusion in Designer Web, CVE-2023-25262 at 7.5 is server-side request forgery in Designer Web, and CVE-2023-25263 at 5.5 is a static secret letting connection strings stored in .mrt files be decrypted after decompiling the assembly. The first three are scoped to design-time and viewer tooling rather than the engine assembly a compiled application ships. Two older 9.8 entries, CVE-2020-15865 and CVE-2021-42777, both trace by NVD to a 2013-era build, Stimulsoft Reports 2013.1.1600.0, with a server-side C# compilation feature. A trio from 2024 belongs elsewhere again, because CVE-2024-24396 and CVE-2024-24397 name Stimulsoft Dashboard.JS while CVE-2024-24398 names Stimulsoft Dashboard.PHP, so calling all three an npm package problem gets one of them wrong. Setting the misattributed ones aside, what stays on the record is a designer-and-viewer cluster from 2023 with no fixed version listed in NVD or GitHub's database, on a product line that has shipped a dozen quarterly releases since.

What IronPDF Does With the Stylesheet Instead

Which half of the workload is the designer being charged to? Where a finished stylesheet is the input, the report definition drops out entirely.

using IronPdf;

var invoiceRenderer = new ChromePdfRenderer();
invoiceRenderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
// Print media so the template's own page rules and breaks are honoured
invoiceRenderer.RenderingOptions.CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print;

using PdfDocument invoice = invoiceRenderer.RenderHtmlAsPdf(File.ReadAllText("invoice.html"));
invoice.SaveAs("invoice-2026-08.pdf");

IronPDF returns a paginated PDF with the template's tables, lists, and layout intact and its text selectable, with no allowlist to design around and no separate SKU per runtime. Headers, footers, and paper sizes are set on the same renderer, and an MVC project can hand over a Razor view instead of a rendered string.

Most estates running Stimulsoft split the work rather than replace anything. Analyst-built reporting stays in the designer, where cross-tabs, subreports, drill-down parameters, and scheduled distribution live and a rendering library offers nothing. The invoices, receipts, and statements never destined for a designer move to a render call. Stimulsoft's ceiling sits at that seam, since the tag interpreter, the runtime key, and the SKU decision are charged to both halves even when only one of them opens the designer. There is a full walkthrough of the renderer half, and IronPDF has a free trial for putting one of your existing templates through it first.

If you have had to pick between Reports.NET and Reports.WEB for a project that needed both a desktop and a web front end, how did the SKU maths work out? Tell us in the comments, because that decision seems to get made once and then quietly constrain the deployment target for years.

Stimulsoft is a trademark of its owner and this piece is not affiliated with the company. The tag support, packaging, licensing, release, and CVE details above are drawn from Stimulsoft's own documentation, NVD, and the GitHub Advisory Database as they stood at the time of writing. If a detail has changed since, correct us in the comments.

Power BI Paginated Reports: Four Gates Before a PDF

IronSoftware — Sun, 30 Aug 2026 16:04:25 +0000

A Fabric or Premium capacity, provisioned and billed every month, so that an application on a Premium Per User licence can produce one PDF every five minutes. That ratio comes straight from Microsoft's own throttling documentation. Where reporting already lives in Power BI the capacity is already committed and one more export is marginal, but a .NET application that only needs markup turned into a PDF is buying the whole capacity for a job IronPDF 2026.8.1 does in-process.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Power BI Paginated Reports' capacity requirement and asynchronous export job cost a team, and where IronPDF returns the bytes in the same request.

What RDL Pagination and Accessible PDF Buy

Two things here are strong on their own terms.

RDL carries two decades of engineering behind it, the same report definition language that ran SQL Server Reporting Services, so pixel-precise pagination, repeating headers, and multi-column layouts work because that is what the format was designed to do. Paginated reports exist for the documents that have to print identically every time. IronPDF paginates the same documents through CSS page rules, inside the process that already holds the data.

The export surface goes past PDF too. Alongside PPTX, XLSX, DOCX, CSV, XML, MHTML, and six image formats, the service exports Accessible PDF, meeting PDF/UA requirements through a format setting rather than a compliance project. Any team under an accessibility obligation knows what building that support from scratch costs. Subscriptions add scheduled recurring distribution, a report mailing itself to a list every Monday with no code in the path at all, which a rendering library has no equivalent for and is not trying to build. For an organisation already holding a capacity for its dashboards, all of this runs on governed infrastructure inside an existing Microsoft Entra tenant, with no separate report server to patch and no second authentication story to wire up. That tenant is the ceiling of what the service reaches, because IronPDF produces the same accessible PDF without one.

Which Licence Do You Need Before the First PDF?

Paginated reports do not have a list price the way a NuGet package does. Licensing is layered across four thresholds, and collapsing them into one sentence is how most comparisons get this wrong.

Authoring is unlicensed: building a report and publishing it to your own My Workspace requires neither Pro nor Premium Per User, and Microsoft's documentation is explicit that this first step is unlicensed.
Sharing takes a seat: publishing to a shared workspace so colleagues can find it requires a Pro or PPU licence for the publisher.
Viewing depends on the tier: a user without a Pro or PPU licence can open a paginated report only if the workspace sits on a Fabric capacity of F64 or higher, or a legacy Premium P1 or higher. Below that tier, every viewer needs their own Pro or PPU licence.
Programmatic export demands a capacity, always: Microsoft's paginated report export documentation states that the report must reside in a workspace backed by a Premium, Embedded, or Fabric capacity, and that the exportToFile API has limited support in Premium Per User.

That last phrase repays a careful reading, because the sibling documentation for non-paginated Power BI reports is harsher still, stating outright that exporting one of those with exportToFile is not supported for Premium Per User. Paginated reports get the softer treatment, and the softer treatment is one request per five-minute window, with anything more returning a 429. Granting Microsoft that distinction does not change the shape of the commitment, because an ISV exporting on demand needs a capacity SKU rather than a developer licence, and Microsoft does not publish flat list pricing for Fabric capacities, so the number comes from a region-specific and term-specific calculator rather than a page you can budget against.

Three operational constraints follow from the same architecture. Export is asynchronous, so no call returns PDF bytes in the same request. exportToFile starts a job, the application polls a status endpoint honouring the RetryAfter header, and eventually receives a download URL valid for 24 hours, with the whole export capped at 60 minutes to match the life of the user access token. Throttling caps volume at 250 requests per minute without a service principal profile and 25 per minute with one, against a ceiling of 250 concurrent paginated render requests. Every export runs within a Microsoft Entra tenant, which means an ISV shipping document generation inside software on a customer's own infrastructure has no path here at all, because the capability does not exist outside the tenant boundary. That is what shared multi-tenant infrastructure costs, and a reasonable trade when the reporting estate is already there. It is a poor trade when a download-your-invoice button has to become a job queue and a polling loop, which is the case IronPDF answers with an async in-process render and a batch pipeline.

On security the exposure is dependency-shaped. No CVE names paginated reports or exportToFile in the current cloud service. The records in this area attach to Power BI Report Server, the separate on-premises product, which is listed among the affected products for CVE-2019-1332 alongside SQL Server 2017 and 2019 Reporting Services. Clearing the cloud service of a CVE history is fair, and it moves the risk instead of removing it, since data and rendering both sit within Microsoft's infrastructure, so a throttling change or an outage on Microsoft's side becomes part of your document path in a way it never is when IronPDF renders inside your own process.

When Does the Request Turn Into a File?

Scoped strictly to turning application data into a file.

Capability (document output only)	Power BI Paginated Reports	IronPDF
Produces PDF	Yes, plus Accessible PDF (PDF/UA)	Yes, plus PDF/UA and PDF/A
How the call behaves	`exportToFile` starts an asynchronous job, then you poll	`ChromePdfRenderer.RenderHtmlAsPdf` returns a `PdfDocument`
Fixed, pixel-precise pagination	Yes, RDL's core strength	Yes, through CSS page rules
Report design tool required	Power BI Report Builder, Windows only	0, the template is HTML the app already has
Infrastructure required	Entra tenant plus Premium, Embedded, or Fabric capacity	The application process
Runs air-gapped or on a customer's own servers	No	Yes

Table 1. Document output only, paginated reports against IronPDF, excluding interactive reporting and dashboarding.

Both columns end at a PDF. What separates them is everything between the request and the file.

IronPDF Never Leaves the Process

For the application-generated document, meaning an invoice, a statement, a contract, or a shipping manifest, the render happens in the process that already holds the data.

using IronPdf;

var statementRenderer = new ChromePdfRenderer();
// Print media so the template's page rules apply, not its screen layout
statementRenderer.RenderingOptions.CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print;

using PdfDocument statement = statementRenderer.RenderHtmlAsPdf(BuildStatementHtml(customer, transactions));
using PdfDocument packet = PdfDocument.Merge(PdfDocument.FromFile("cover.pdf"), statement);
packet.SaveAs($"statement-{customer.Id}.pdf");

IronPDF returns the bytes from one call in the same request, with no capacity provisioned, no tenant in the path, and no polling loop between the button and the download. Rendering options cover page geometry, headers, and footers, and an MVC template can go over as a Razor view rather than a rendered string.

Self-service reporting an analyst builds alone, with parameter prompts, drill-through, and a subscription mailing a distribution list, has no counterpart here. Power BI Paginated Reports' ceiling is not capability but reach, because it ends at the tenant boundary, and a document produced for a customer running your software on their own hardware sits outside it. Teams needing both keep both, and the renderer-side pattern is worked through end to end if that split is on the table. IronPDF has a free trial if you want to time an in-process render against your current export job before deciding.

If you are exporting paginated reports on a schedule today, what does your capacity cost per document once the monthly bill is divided by the number of PDFs it produced? Post it in the comments, since that number seems to surprise people who have never worked it out.

Power BI, Microsoft Fabric, and Microsoft Entra are Microsoft trademarks and this piece is not affiliated with Microsoft. The licensing, throttling, export, and CVE details above are drawn from Microsoft Learn and NVD as they stood at the time of writing. Fabric capacity pricing varies by region and commitment term, so check Microsoft's calculator rather than any figure quoted secondhand. If a detail has changed since, correct us in the comments.

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

IronSoftware — Sat, 29 Aug 2026 01:16:26 +0000

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.

SSRS in 2026: The Report Server You Still Have to Run

IronSoftware — Sat, 29 Aug 2026 01:16:16 +0000

Strip a report server down and there are three jobs inside it. Something authors a layout. Something binds data to that layout and paginates it. Something turns the paginated result into a file and delivers it. SQL Server Reporting Services does all three, and the price of the first two is a Windows service, a catalog database, and a web portal that has to be patched, backed up, and staffed for as long as the reports exist. When a team's actual requirement is only the third job, turning markup into a PDF, the other two arrive anyway.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where SSRS's Windows-only host and SOAP-era export path cost a team, and where IronPDF returns the same PDF from one in-process call on any operating system.

What Are the Three Jobs Inside a Report Server?

The first two jobs are where SSRS earns its install base.

One RDL definition exports to HTML4.0, HTML5, MHTML, IMAGE, EXCELOPENXML, WORDOPENXML, CSV, PDF, XML, and NULL through rs:Format, authored once. SSRS reaches all of them from one file, though that file is a report definition its PDF path cannot skip and IronPDF does not require, which is one dependency fewer in the box. Around that sits the distribution layer, which covers email and file-share subscriptions, report history, execution snapshots and caching, and role-based folder security in the portal. Data-driven subscriptions and scale-out web-farm deployment sit in Enterprise. For a shop already licensed for SQL Server Standard, most of that carries no additional line item, and that is the ceiling of what the report server covers, because IronPDF produces one of those ten formats without the Windows host, catalog database, or portal the other nine arrive attached to.

The commitment question is what that infrastructure costs after the person who configured it moves on. A report server is a stateful service with its own database, authentication surface, and patch cadence, and those obligations persist whether it serves analyst-authored cross-tabs or a nightly invoice run nobody has opened in the designer since 2019. The equivalent obligation for IronPDF is a NuGet package version.

Why Does SSRS Still Need a Windows Host?

SSRS now has a documented end state. The current build is SSRS 2022, version 16.0.1118.33, published 4 February 2026, and Microsoft's Reporting Services consolidation FAQ states that starting with SQL Server 2025, on-premises reporting consolidates under Power BI Report Server and that no new versions of SQL Server Reporting Services will be released. SSRS 2022 keeps receiving security updates and support through 11 January 2033, in line with the SQL Server 2022 lifecycle. The same FAQ describes PBIRS as a superset of SSRS, so there is a migration target, but it is still a migration with a date on it.

Neither product leaves Windows. Microsoft's unsupported-features table for SQL Server on Linux lists Reporting Services outright, with guidance to run SSRS on Windows and host only its catalog databases on SQL Server on Linux. A team standardising on Linux containers keeps one Windows host in the topology specifically to turn a report into a PDF, and that host is a deployment surface, a licence, and a patching obligation nothing else in the stack needs.

The HTML story inside a report is narrower than the export list suggests. A report textbox interprets a fixed tag set of <a href>, <font>, <h1> through <h6>, <div>, <span>, <p>, <li>, <b>, <i>, <u>, <s>, <ol>, and <ul>, and Microsoft's documentation on importing HTML into a paginated report states that any other markup is ignored during processing, with malformed HTML falling back to plain text. The same page states that relative CSS length units are ignored and not supported, naming em, ex, px, %, and rem, so a print stylesheet built on rem or percentage widths is not degraded here, it is dropped.

On security the record is short and old, though not empty. CVE-2020-0618 is the one that still matters, an 8.8-severity remote code execution flaw where an untrusted ViewState parameter is deserialized through LosFormatter, patched 11 February 2020, and added to CISA's Known Exploited Vulnerabilities catalog on 18 September 2024, four years after the fix shipped. Alongside it sit CVE-2019-1332 at 6.1, a reflected cross-site scripting issue affecting SQL Server 2017 and 2019 Reporting Services and Power BI Report Server, and CVE-2020-1044, an attachment upload validation bypass that Microsoft scores 4.3 and NVD scores 6.5. Older GDI+ entries from 2009 attach to SQL Server 2000 Reporting Services SP2 rather than anything currently deployed, so the modern record is thin. Setting the miscounted historical entries aside, what a team still signs up for is an internet-facing ASP.NET application whose attack surface someone has to own until 2033.

How Does IronPDF Replace the SOAP Contract?

Producing a PDF from code has not modernised alongside the rest of the stack. It is a URL query string built from rs:Format=PDF against ReportServer, or a SOAP call to ReportExecutionService.Render against ReportExecution2005.asmx. SSRS has shipped an OpenAPI-compliant REST API since 2017, but Microsoft's reference scopes it to catalog operations covering folders, datasets, subscriptions, and refresh plans, with no render or export operation listed. Calling SSRS for a PDF from a .NET 8 or .NET 10 service means one of those two older paths.

The same job in-process is a method on an object your application already owns.

using IronPdf;

var invoiceRenderer = new ChromePdfRenderer();
// Print media, not screen, so the stylesheet's page rules actually apply
invoiceRenderer.RenderingOptions.CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print;

using PdfDocument invoice = invoiceRenderer.RenderHtmlAsPdf(File.ReadAllText("invoice.html"));
invoice.SaveAs("invoice-2026-08.pdf");

IronPDF writes a single searchable PDF with the template's own fonts, margins, and page breaks applied, and the same call runs on Windows, on Linux, and inside a Docker image. There is no catalog database in the path, no ASMX endpoint to authenticate against, no host that has to be Windows, and the relative CSS units a report textbox discards are applied normally.

Teams already producing markup from MVC hand IronPDF the Razor view itself, and the page furniture a report definition would carry is set through rendering options on the same renderer.

The Document Step, Row by Row

Narrowed to the one step both tools perform, producing a file.

Capability (document output only)	SSRS 2022	IronPDF
PDF output from code	`rs:Format=PDF` URL or SOAP `ReportExecutionService.Render`	In-process `ChromePdfRenderer.RenderHtmlAsPdf`
HTML in the document body	14 documented tags, others ignored during processing	0 excluded, full HTML, CSS, and JavaScript
Relative CSS units such as `rem` and `%`	Ignored and not supported	Applied as written
Host operating systems	1, Windows	3, Windows, Linux, and macOS from one package
Merging or stamping an existing PDF	Outside the report engine	`PdfDocument.Merge` and stamp
Report designer, subscriptions, scheduled distribution	Yes, the platform's core value	0 to licence, patch, or staff

Table 1. Document output only, SSRS 2022 against IronPDF 2026.8.1, excluding the designer, portal, and distribution surface.

The row that decides most projects is the fourth. One supported host operating system against three is a deployment topology rather than a feature gap, and it is fixed on the day the report server goes in.

Which Half of the Work Goes Where?

Where that stops is upstream. If an analyst authors the report, if a subscription mails it to a distribution list every Monday, or if one definition has to reach Excel, Word, and CSV as well as PDF, a rendering library has none of it and is not growing any of it. Most SQL Server shops end up running both, with SSRS keeping the analyst-authored, parameterised work and application code calling IronPDF for the invoices, contracts, and labels a designer was never in the loop for.

For a team weighing that split, the reporting-tool replacement walkthrough covers the same pattern end to end, and IronPDF has a free trial if you want to run one of your existing report outputs through a render call first.

If you are running SSRS today, how much of it is analyst-authored reporting and how much is an application generating documents that happen to go through the report server because it was already there? Tell us in the comments, because that ratio is the part nobody seems to measure until a migration forces it.

SQL Server, SSRS, and Power BI Report Server are Microsoft trademarks and this piece is not affiliated with Microsoft. The lifecycle dates, platform support, HTML and CSS behaviour, and CVE details above are drawn from Microsoft Learn, NVD, and CISA as they stood at the time of writing. If a detail has changed since, correct us in the comments.

DevExpress Reporting in 2026: Where HTML-to-PDF Lives

IronSoftware — Thu, 27 Aug 2026 20:13:07 +0000

Four names circulate for what people mean by DevExpress reporting, and picking the wrong one costs a subscription. XtraReports is the API and namespace. DevExpress Reporting is the marketing name for the same product, and the docs use both interchangeably. DevExpress Report Server is a separate hosting service for publishing and scheduling, priced separately. The Office File API is a fourth product entirely, and it is the one holding the general-purpose HTML-to-PDF converter. Buying Reporting and expecting the fourth thing is a procurement mistake, not a coding one.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where DevExpress Reporting's second purchase for a working HTML-to-PDF converter costs a team, and where IronPDF renders the same page from one package.

Which DevExpress Product Are You Buying?

Inside DevExpress Reporting there are two ways to get HTML-flavoured content into a report, and neither is a browser. The first is XRLabel.AllowMarkupText, a small markup dialect covering line breaks, colour, bold, and size. The second is XRRichText, which imports HTML and RTF through the DevExpress word-processing document model.

// Two entry points, two different engines, neither a browser
var summaryLabel = new XRLabel { AllowMarkupText = true, Text = "<b>Q3</b> summary" };
var bodyBlock = new XRRichText();
bodyBlock.Html = File.ReadAllText("statement-body.html");

Both put content on the page. Neither guarantees the result matches what a browser draws, and DevExpress says so directly. Its HTML support limitations page states that the component is not designed to fully support the HTML format, that interpretation is limited and optimised for documents rather than web pages, and that it can display a document differently from a browser even when every tag imported. Some HTML tags and CSS attributes have no counterpart in the Open XML and RTF models underneath.

For a report built from DevExpress's own controls that is a non-issue. For a layout designed as a web page it is a rewrite, because the document-to-PDF path for Word content is a different problem from rendering a stylesheet, and IronPDF is the one of the two built for the stylesheet.

What Redistribution Grants You

Two things about DevExpress's commercial terms hold up under a direct read.

Its EULA states that the company charges no royalties for redistribution of components integrated into applications you engineer, and rights of use survive a lapsed subscription, so a team that stops renewing keeps a working licensed build and loses only updates and support. The End-User Report Designer is redistributable on the same terms, so shipping report authoring to your own customers adds no per-deployment fee. That is a materially different commitment profile from a model metering by server or by end user. IronPDF charges per developer once and redistributes with no royalty on the same basis, without a designer to licence alongside it.

Platform reach is the second. The current line supports WinForms, WPF, ASP.NET Web Forms, MVC, ASP.NET Core, Blazor Server, Blazor WebAssembly, and .NET MAUI for Android and iOS, and the Report Designer runs inside Visual Studio, VS Code, and JetBrains Rider. Version 26.1 shipped in June 2026 on the usual twice-yearly cadence, targeting .NET 8 through .NET 10 alongside .NET Framework 4.6.2 and later, with PDF/UA-2 export added to the PDF engine. Cross-tabs, subreports, chart types in the dozens, and parameter-driven queries against a live data source sit on top of that, and that spread is the ceiling of what the reporting subscription reaches, because IronPDF covers the same targets from one package with no designer to install per IDE.

Where Does the HTML-to-PDF Converter Live?

The one place DevExpress documents complete HTML-to-PDF conversion is RichEditDocumentServer.ExportToPdf, which lives in DevExpress.RichEdit.Core and is documented under the Office File API rather than under Reporting. A team already paying $799.99 per developer in the first year for Reporting, with a $399.99 renewal, is looking at a second subscription to get a general-purpose converter, and it still runs through the same word-processing engine with the same document-not-web-page limitations.

Deployment adds a second surprise. The default bitmap path in XRPdfContent, CreateDXBitmap, is documented as not working in Linux environments or on certain Azure hosting plans. A fix exists, adding DevExpress.Pdf.SkiaRenderer and, on Linux, SkiaSharp.NativeAssets.Linux, but the default configuration does not apply it and a deployment has to know that before the first container ships. IronPDF reaches Linux and Azure App Service from one package and one call, the same ones it uses on Windows, so the difference is not capability but how much environment-specific knowledge the team carries forward.

One upgrade trigger gets exaggerated, so here it is precisely. Reporting is sold standalone, and buying it does not require Universal. What holds up is that the Reporting subscription's WinForms integration covers ReportPrintTool and ReportDesignTool only, and DevExpress's own documentation states that adding further DevExpress UI controls, meaning new panels, buttons, or menus, requires a subscription including those controls. Customising the designer chrome therefore means WinForms at $1,099.99 first year and $549.99 renewal, or Universal at $2,299.99 first year and $1,149.99 renewal.

One CVE, Two Scores, and No Fixed Version on Record

Two CVEs name the reporting component, and both deserve care instead of a headline number.

CVE-2023-35814 is described by NVD as a failure in DevExpress before 23.1.3 to properly protect XtraReport serialized data in ASP.NET web forms, classed CWE-502. The scores diverge sharply, because NVD's primary assessment is 9.8 critical while the CNA's own secondary assessment on the same record is 3.5 low. The practical answer sits in the affected-version list rather than either score, covering everything before 21.2.12 plus the 22.1, 22.2, and 23.x lines up to the 23.1.3 fix.

CVE-2021-36483 is the older one. NVD rates it 8.8 high, published 4 August 2021, and describes insecure deserialization in DevExpress.XtraReports.UI through v21.1, with references to DevExpress Support Center tickets and ZDI-22-341. NVD lists no fixed version for it. That is a statement about the public record, not a claim the vendor ignored it, and anyone still on a 21.x build should treat the deserialization path as reachable rather than wait for a database field to fill in. Beyond those two, NVD carries other CVEs against DevExpress products naming no specific component, so confirm the affected assembly before citing one. Either way, deserialization surface is a category of exposure that a PDF pipeline built on rendering and encryption never opens.

Document Output at Two Subscription Prices

Scoped to document output alone.

Capability (document output only)	DevExpress Reporting	IronPDF
PDF from a designed report	Native `XRDocument` export	Renders markup, a URL, or a Razor view through `ChromePdfRenderer`
HTML and CSS to PDF	`AllowMarkupText` dialect or `XRRichText`, no browser engine	Chromium rendering of HTML, CSS, and JavaScript
Razor view or URL rendered directly	Bound into a report definition first	Direct, via `RenderUrlAsPdf` or a `.cshtml` view
Editing an existing third-party PDF	Export pipeline only	Merge, split, stamp, fill forms
Per-developer cost for the HTML-to-PDF path	$799.99 first year for Reporting, plus a second subscription for the converter	1 licence, 1 product, 0 converters to add

Table 1. Document output only, DevExpress Reporting against IronPDF, excluding the designer, scheduler, and data-binding surface.

The last row is the one an architect signs off on. Every other row is a capability question, while that one is a renewal repeating annually for as long as the pipeline exists.

IronPDF Needs No Report Project

When the content is already markup and the deliverable is a file, the report definition is the step that disappears.

using IronPdf;

var reportRenderer = new ChromePdfRenderer();
// Print media so the template's @page rules and page breaks are honoured
reportRenderer.RenderingOptions.CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print;
reportRenderer.RenderingOptions.MarginTop = 20;

using PdfDocument quarterly = reportRenderer.RenderHtmlAsPdf(quarterlyHtml);
quarterly.SaveAs("quarterly-2026-q3.pdf");

The PDF IronPDF returns keeps selectable text and the source stylesheet's layout intact, including the CSS constructs that importer has no counterpart for. Teams generating markup from MVC can render the Razor view itself, and page furniture is set through rendering options.

Everything upstream of that call belongs to DevExpress. A business user designing their own report, a parameter-driven query against a live data source, a cross-tab or a subreport all belong to the platform. DevExpress Reporting's ceiling is that all of it is priced into the export path too, including for a workload that never opens the designer. The pattern for the renderer half is worked through end to end. IronPDF has a free trial for running one of your existing report outputs through it first.

If you have shipped DevExpress Reporting to a Linux container, did the Skia packages come up during evaluation or during the first failed deploy? Drop a comment, because that ordering seems to decide how people remember the experience.

DevExpress and XtraReports are trademarks of their owner and this piece is not affiliated with the company. The pricing, licensing, HTML support, Linux export, and CVE details above are drawn from DevExpress's own documentation and NVD as they stood at the time of writing. If a detail has changed since, correct us in the comments.

FastReport.OpenSource in 2026: The PDF Is an Image

IronSoftware — Thu, 27 Aug 2026 18:12:36 +0000

An auditor asks for the invoice raised to one customer in March 2021. Someone searches the archive, finds the file, opens it, and cannot search inside it. Copy does nothing. The indexer that was supposed to make this instant has no text to index, because every page in that PDF is a picture of a page. Nothing failed. The document was generated exactly as configured, seven years earlier, by a report engine whose PDF plugin rasterizes instead of writing selectable text. This is a retention-horizon problem, and it does not surface during evaluation.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where FastReport's rasterised open-source PDF export costs a team years later, and where IronPDF writes selectable vector text on every call.

Why Is the MIT Edition's PDF an Image?

The open-source edition's PDF export is not a limited text exporter. It is a different mechanism. PDFSimpleExport draws each report page into a Bitmap and embeds the result, and the plugin's own NuGet listing points to the paid line in its description, telling developers that if the export is not enough and they need a full-featured PDF export with encryption, digital signing, and font embedding, they should look at FastReport .NET Core. That is a documented upgrade path, and Fast Reports put it in the package blurb where a developer will actually read it.

What gets missed is downstream, because the file opens correctly in every viewer. Text inside it cannot be selected, searched, copied, or indexed, which rules out the archive-search case above, full-text search over generated documents, and any accessibility obligation depending on a screen reader reaching the words. File sizes run heavier than a text-based PDF of the same content, which compounds over a retention period. Because the pages are images, the source itself notes that pages exceeding 2GB as bitmaps will not export at all.

Rasterizing a page is reasonable when it is chosen. Thumbnails and previews want exactly that, and rasterizing on demand is a one-line operation. The difference is that a chosen rasterization keeps the text-based original, which is why IronPDF rasterizes from a text PDF rather than instead of one, and no compression pass recovers text that was never written.

Which Exporter Writes Text and Which Writes Pixels?

Scoped to how each option gets a PDF out.

Aspect (PDF output only)	FastReport .NET (commercial)	FastReport.OpenSource	IronPDF
What produces the file	A `.frx` template exported through `PDFExport`	The same `.frx` workflow via the `PdfSimple` plugin	`ChromePdfRenderer` against markup, a file, or a URL
How pages are written	Vector content with embedded fonts	Each page drawn to a `Bitmap` and embedded	Vector content with embedded fonts
Text in the output	Selectable and searchable	Not selectable, the page is an image	Selectable, searchable, extractable
Format conformance	PDF 1.5 and 1.7, PDF/A, PDF/X	Basic PDF container	PDF/A-3 and PDF/UA, selectable PDF version
Cost to reach selectable text	$499 to $1,499 per developer depending on SKU	Not reachable on this edition	1 licence, 0 editions to choose

Table 1. PDF output only, the two FastReport editions against IronPDF, excluding the report designer and data connectivity.

The second and third rows are the ones to sit with, because they are a property of the file that outlives the decision by years.

What Ships in the MIT Edition

FastReport.OpenSource is not a cut-down demo, and treating it as one misreads the product. It is MIT-licensed with Fast Reports named as copyright holder, the core package has logged 2.9 million downloads on nuget.org with the PDF plugin adding another 1.9 million, and version 2026.2.3 published on 16 June 2026, so it is maintained rather than parked. Inside it are a WinForms designer, C# and VB.NET scripting, interactive reports with hyperlinks and bookmarks, 13 band types, Table, Matrix, barcode and gauge objects, and connectors for MS SQL, PostgreSQL, SQLite, MySQL, MongoDB and a dozen more sources. It ships in 29 languages with full source on GitHub, and almost none of that is held back for the paid tier. None of it changes the export path, where IronPDF writes the vector text the MIT plugin cannot.

The security record is short and closed. Exactly one CVE has been filed against FastReport's own code, CVE-2020-27998, scored 9.8 by NVD and published 29 October 2020, covering a missing ScriptSecurity feature that let a report template reach GetType, typeof, DllImport, LoadLibrary, and GetProcAddress. GitHub Security Lab documented it as GHSL-2020-143, and Fast Reports fixed it in 2020.4.0. Nothing against the product's own code has followed. One attribution trap circulates in the project's own issue tracker and deserves correcting, because CVE-2024-0056 is a Microsoft advisory against System.Data.SqlClient 4.8.5, reaching FastReport only as a transitive dependency of the FastReport.Data.MsSql connector and resolved by bumping to 4.8.6. Filing it against FastReport's own code overstates the finding, and setting it aside leaves a single closed CVE against a report engine whose script surface still compiles user-supplied code by design. IronPDF compiles no user-supplied script, so that surface does not exist.

Fast Reports also solved a .NET platform problem instead of pointing at a workaround. System.Drawing.Common dropped non-Windows support, and the usual fallback, libgdiplus, carries known rendering defects including wrong text sizing and no right-to-left support. FastReport's answer was FastReport.Core.Skia, a SkiaSharp-based renderer shipped in 2022 and still the recommended path for non-Windows rendering today, rather than the stale System.Drawing.EnableUnixSupport switch that Microsoft's own breaking-change documentation says was removed in .NET 7. Getting font handling right off Windows is hard, and they did the work. That renderer is the ceiling of what the MIT edition reaches, because IronPDF ships its own Chromium build and draws type identically on Windows and Linux.

Selectable Text Without an Edition Decision

For the narrower job, turning a template and a data model into a document with real text in it, the exporter choice does not exist.

using IronPdf;

var invoiceRenderer = new ChromePdfRenderer();
using PdfDocument invoice = invoiceRenderer.RenderHtmlAsPdf(BuildInvoiceHtml(order));
invoice.SaveAs("invoice-2021-03.pdf");

IronPDF writes vector text with embedded fonts, so seven years later the archive search finds it and text extraction in code reads it back. The same renderer takes a Razor view if the markup is already an MVC template, and the call is identical on Windows, on Linux, and in a container with no plugin boundary between one export path and another.

Upstream of that call sits ground a renderer does not contest. There is no report designer here, no drag-and-drop parameter prompts, no cross-tabs or subreports, and no scheduled distribution, so analyst-built reports belong in the FastReport designer. What that designer cannot hand back is a PDF with text in it. The ceiling is on the export path rather than the product, meaning an MIT edition whose PDFs are pictures and a commercial line where selectable text starts at a per-developer licence. Teams owning both usually split it by who authors the document, and the renderer-side pattern is written up in full if that split is on the table. IronPDF has a free trial for testing text extraction against your own generated output first.

If you are running FastReport.OpenSource today, have you hit the image-PDF wall yet, or are you still ahead of it? Tell us in the comments, because we would like to know whether teams catch this during evaluation or years into a retention window.

FastReport is a trademark of its owner and this piece is not affiliated with the company. The package, licensing, export behaviour, and CVE details above are drawn from Fast Reports' own documentation and NuGet listings, NVD, and GitHub Security Lab as they stood at the time of writing. If a detail has changed since, correct us in the comments.

Telerik Reporting in 2026: What $499 a Year Commits You To

IronSoftware — Thu, 27 Aug 2026 18:11:18 +0000

$499, $599, or $999 per developer per year. Those are the three Telerik Reporting subscription tiers on Progress's own purchase page, separated only by support response time and incident count. Lite gives 72-hour response and up to 10 incidents, Priority drops that to 24 hours with unlimited incidents, and Ultimate adds phone and remote assistance. Runtime redistribution carries no royalty at any tier. The number that decides an architecture is rarely the sticker price. It is what the licence turns into once it lives in a build pipeline, and how much of it a workload that only needs HTML turned into a PDF ever touches.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Telerik Reporting's build-time licence key and table-less HtmlTextBox cost a team, and where IronPDF renders the same markup with a key applied at runtime.

What $499 a Year Buys

Eight output formats from one definition. One report definition renders to PDF, Word, Excel, PowerPoint, MHTML, CSV, RTF, and every standard image format through a single ReportProcessor call, so a team that needs the same layout in four formats has bought the whole matrix once. IronPDF covers one of those formats and covers it without the report definition the other seven are authored into.

Viewer coverage is wide. HTML5 and JavaScript, ASP.NET Core, MVC, Web Forms, native and wrapped Angular, React, native and wrapped Blazor, WPF, WinForms, and WinUI all ship in the box, so a report authored once embeds in almost any .NET front end already in the estate. The Web Report Designer is included in the subscription and runs against a REST service on .NET Framework 4.6.2 or .NET 8 and later, so non-developers can adjust a report without a desktop install. IronPDF reaches those same front ends by returning a file, so there is no viewer control to match per framework.

The cadence is quarterly and predictable. The current release, 2026 Q3 (20.2.26.812), went out 11 August 2026 and added Aztec barcode encoding, faster Excel generation, and public nuget.org availability alongside the private Telerik feed. That cadence is the ceiling of what the subscription buys, because IronPDF shipped 2026.8.1 on 3 August 2026 and moves with the framework rather than a quarterly train.

The PDF Path, Side by Side

Scoped strictly to producing a document file.

Capability (document output only)	Telerik Reporting	IronPDF
Renders a defined layout to PDF	`ReportProcessor.RenderReport` against a report definition	`ChromePdfRenderer.RenderHtmlAsPdf` against markup or a URL
HTML in the document body	`HtmlTextBox` tag allowlist, no `table` tag	Chromium rendering of full HTML, CSS, and JavaScript
Input types the render call accepts	1, a report definition	4, an HTML string, a file, a URL, or a Razor view
Post-render document work	Bundled document-processing libraries	`PdfDocument.Merge`, split, stamp, encrypt, rasterize
Headless rendering in a container	SDK for .NET 8 to 10, Linux via SkiaSharp	1 package, .NET Framework 4.6.2 to .NET 10
Licence checkpoint	Per-developer key validated at build time from 2025 Q1 onward	1 key, applied at runtime in code

Table 1. Document output only, Telerik Reporting against IronPDF, excluding the designer and data-binding surface.

The two products overlap on one row of a much longer feature list, and on that row the constraints run in opposite directions.

What Else Does the Export Path Charge For?

Each is a property of the export path, not a missing reporting feature.

Telerik's HtmlTextBox has no table tag: the report item accepts font, strong, b, em, i, u, sub, sup, a, ol, ul, li, div, span, p, br, center, and img, with inline images added in 20.0.26.211, plus a limited CSS subset covering borders, padding, alignment, and font properties. Progress's own formatting documentation states that the HtmlTextBox does not support the table tag and directs developers to the native Table, Crosstab, and List report items instead. An invoice built as an HTML table is a rebuild rather than a paste, where IronPDF renders that same table, and the CSS around it, exactly as the browser drew it.
The licence became a build dependency: from 2025 Q1 (19.0.25.211) onward, Telerik Reporting validates a per-developer key at build time, read from a telerik-license.txt file, an environment variable, or the project root. Progress documents build errors and warnings in the TKL series, and an invalid or expired licence puts a watermark on every rendered page. A deployed application keeps running after a subscription lapses, but rebuilding and republishing it does not, which turns renewal into a CI/CD concern rather than only a purchasing one. IronPDF applies its key at runtime in code instead, so the build machine never needs to know.
Telerik's designers stay on Windows: the Visual Studio integrated designer targets .NET Framework projects, and Progress documents that it cannot be extended to support SDK-style projects or .NET Core and .NET 5 and later targets. The standalone desktop designer requires Windows. The rendering engine itself reaches Linux through SkiaSharp, so the constraint lands on authoring, and a team with developers on macOS still keeps a Windows machine in the loop to edit a report, which is a machine an IronPDF template never requires.

How Long Did the 2024 CVE Run Last?

Telerik Reporting's own-code vulnerability record concentrates in a single year and then thins out. During 2024 Progress patched CVE-2024-1801 and CVE-2024-1856, both insecure deserialization and both fixed in 2024 Q1 (18.0.24.130), CVE-2024-4200 and CVE-2024-4202, fixed in 2024 Q2, CVE-2024-6096 at 9.8 critical covering object injection and insecure type resolution, fixed in 18.1.24.709, and CVE-2024-7840 and CVE-2024-8014, fixed in 18.2.24.924. CVE-2024-8048, also fixed in 18.2.24.924, is scoped by NVD to the standalone desktop Report Designer rather than the engine or REST services, and CVE-2024-0832 is specific to the Telerik Reporting installer.

Two corrections apply to how this record usually gets summarised. The run did not stop in September 2024, because CVE-2024-6097, a 5.3-severity absolute-path information disclosure, was published 12 February 2025 and fixed in 2025 Q1 (19.0.25.211), and its NVD description carries no designer-only scope limit. The older CVE-2017-9140, a 6.1 cross-site scripting issue, sits in Telerik.ReportViewer.WebForms.dll and was fixed in 11.0.17.406.

A pair of neighbouring products invite mix-ups here and both deserve naming. Telerik Report Server is a separate product on its own version line with its own advisories, including one on CISA's Known Exploited Vulnerabilities catalog, and none of that belongs to Reporting. Telerik UI for ASP.NET AJAX is a different product again, and it is the one carrying the long history of actively exploited flaws in Telerik.Web.UI.dll, while Reporting's Web Forms viewer ships in a different assembly. Setting both of those aside, what remains against Reporting's own code is a real 2024 deserialization cluster a team has to stay current with, which is the maintenance side of the subscription arriving on top of the licence fee. IronPDF deserializes no report-definition object graph, so the surface it does carry is encryption and signing rather than type resolution.

Can IronPDF Take the Markup You Already Have?

When the content for the document already exists as HTML, whether from a template engine, an email body, or an MVC view, the render step does not need a report project in front of it.

using IronPdf;

var statementRenderer = new ChromePdfRenderer();
// A4 with real margins, because no report definition is setting page geometry here
statementRenderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
statementRenderer.RenderingOptions.MarginTop = 20;

using PdfDocument statement = statementRenderer.RenderHtmlAsPdf(statementHtml);
statement.SaveAs($"statement-{customerId}.pdf");

IronPDF hands back a paginated PDF with selectable text and the template's own CSS table layout intact, with no markup rewritten into report items. The same object renders a Razor view directly, and page furniture is configured through rendering options.

Certificate-based signing sits on the same returned object rather than a separate export profile.

A business user opening the report, changing a grouping and rerunning it, or an interactive viewer with parameter prompts and drill-down, is outside what a rendering library does. Telerik Reporting's ceiling is scope, because it stops being the cheaper option once a workload never opens a designer, never binds a parameter, and needs a single format. Plenty of .NET shops run both for exactly that reason, and there is a worked walkthrough of the renderer-side pattern if you want the shape before deciding. IronPDF has a free trial if you would rather run one of your existing report layouts through it.

Where does your team draw that line? We are curious how many people are paying a per-developer reporting subscription mainly to reach an export method, so drop a comment if that describes your estate.

Telerik and Progress are trademarks of Progress Software Corporation and this piece is not affiliated with the company. The pricing, release, licensing, HtmlTextBox, and CVE details above are drawn from Progress's own documentation and NVD as they stood at the time of writing. If a detail has changed since, correct us in the comments.

Winnovative vs IronPDF: The Per-Object Licence Trap

IronSoftware — Fri, 21 Aug 2026 21:09:00 +0000

Does a single Winnovative licence key cover an entire deployment, or does it need setting again on every PdfConverter and Document object in the codebase? Winnovative's own FAQ carries a standing entry for teams who set the key once and still saw a demo watermark on a second object nobody remembered to touch. Its Next converter renders through a Chromium engine, though neither the vendor's site nor its NuGet listings say which build, and the copyright line still reads Copyright 2007-Winnovative Software Solutions, the longest continuous run of any budget .NET PDF vendor in this series. Age and stability aren't the issue. The licence scope and the engine version are.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Winnovative's per-object licence key and a la carte component pricing cost a team, and where IronPDF covers a whole deployment with one application-level key.

Everything below comes from Winnovative's own site, its licence agreement, its FAQ, and the National Vulnerability Database's CVE records, checked directly.

Rendering HTML through the Next engine looks like this, the same render-then-save shape covered in IronPDF's own HTML to PDF tutorial.

// Install-Package Winnovative.Pdf.Next.HtmlToPdf.Windows
using Winnovative.Pdf.Next;

using var converter = new HtmlToPdfConverter();
using var pdfDocument = await converter.ConvertUrlAsync("https://example.com/invoice");
pdfDocument.Save("invoice.pdf");

That saves invoice.pdf next to the executable, rendered from the live page rather than a static snapshot of the markup.

Which Winnovative Licence Does This Deployment Need?

Behind that call, the Next line runs on Windows, Linux, and macOS, on both x64 and ARM64, with Azure and Docker support documented, and it carries real Task-based async with cancellation tokens. The catalogue is also the widest of the three Romanian-built .NET PDF vendors in this wave, alongside EvoPdf and SelectPdf, reaching into a standalone Excel library and chart controls. Pricing is a la carte too, the PDF merge component alone costs $250 rather than a full suite.

None of that tells a procurement review the one thing it needs to sign off, and three basics turn out to be hard to find before a purchase order gets signed.

The Next engine's version and release history are both unpublished: release notes carry no dates, a NuGet publish timestamp is the only way to place a version in time, and the Chromium build behind Next isn't listed anywhere, so a security review checking engine currency against Chromium's own advisory schedule has nothing first-party to check.
The licence key has to be set on every object, not once for the whole application: Winnovative's own API reference states that the LicenseKey property of each PdfConverter and Document object needs the purchased key, matching the FAQ entry above.
Buying components one at a time can cost close to double the bundled price: HTML to PDF Converter at $450, PDF Merge at $250, PDF Security at $250, and PDF to Text at $250 add up to $1,200 at the deployment tier, against PDF Toolkit PRO's $650 bundle for equivalent capability.

The cross-platform reach and async support are there, and buying the right bundle upfront avoids the stacking problem. What it costs is diligence, reconstructing information a vendor normally publishes and pricing the bundle against the a la carte total first.

Does IronPDF Answer Those Same Questions?

Winnovative's own code has a clean record. NVD returns zero results for a Winnovative keyword search, the GitHub Advisory Database lists no advisories, and Snyk reports no direct vulnerabilities. Current releases carry recent NuGet dates, Next at 20.36.0 and Classic at 20.0.2, and the combined download count across roughly 60 packages sits around 1.18 million, the smallest of the three budget .NET PDF converters in this wave against EvoPdf's roughly 6.5 million and SelectPdf's roughly 9.4 million. EvoPdf, built by the same company, publishes 24-hour and 72-hour support response targets, while Winnovative's own site publishes none, an absence rather than evidence support doesn't respond.

This render call answers those same open questions before it ever runs.

// Install-Package IronPdf
using IronPdf;

var renderer = new ChromePdfRenderer();
PdfDocument pdf = await renderer.RenderUrlAsPdfAsync("https://example.com/invoice");
pdf.SaveAs("invoice.pdf");

That saves invoice.pdf next to the executable, matching what the Next engine just rendered.

One licence key covers the whole application rather than every object instance, and IronPDF's documentation states the Chromium version directly rather than leaving it open. The same rendering behaves identically across host platforms, checkable against any cross-platform HTML to PDF comparison.

For one narrow capability priced against the bundle correctly, Winnovative Next is the cheaper way in. Everywhere a procurement review needs a dated release history or a published engine version to sign off, IronPDF publishes both before the review starts, with one licence key covering the whole application.

How Do Winnovative and IronPDF Line Up?

With both engines answered, here's how the specifics line up side by side, pulled directly from Winnovative's own materials.

Capability	Winnovative	IronPDF
Cross-platform support	Windows, Linux, macOS, x64 and ARM64	Windows, Linux, macOS
Async API	Native `Task`-based, with cancellation	Native async/await throughout
Release notes	Undated (NuGet publish date is the only proxy)	Dated changelog
Rendering engine version	Chromium build not published	Chromium version documented
Licence key scope	Per-object, every `PdfConverter` and `Document` instance	Application-level
Published support response target	None found	See ironpdf.com
Refund policy	Declined by default, case-by-case exceptions by email	See ironpdf.com terms
Pricing model	A la carte, roughly 10 narrow components plus 3 bundles	Single license covering the full API
Entry list price	$250 for one narrow component, for example PDF Merge	Quote-based, see ironpdf.com

One key, or a licence per feature?

What Winnovative doesn't offer is the paperwork a procurement review usually wants, covering dated releases, a published engine version, a support commitment, and pricing that avoids stacking above the bundle price when components get bought one at a time. That's a diligence gap rather than a defect in the code, and an email to sales usually closes it since the answers exist even when the site doesn't publish them. IronPDF's own licensing terms are published rather than answered case by case.

If you've priced Winnovative's a la carte components against its bundles before signing anything, we'd like to hear how the math worked out in the comments, particularly whether the stacking caught you before or after the invoice arrived.

Winnovative is a trademark of its owner, and this piece is not affiliated. The details above are drawn from Winnovative's own site, its licence agreement, its FAQ, and the National Vulnerability Database as they stood at the time of writing. If a detail has changed since, correct us in the comments.

Spire.PDF's License Key Trial vs IronPDF's Setup

IronSoftware — Fri, 21 Aug 2026 16:31:00 +0000

Download Spire.PDF, wire up the first HTML-to-PDF conversion, and the PDF that comes back has a red evaluation warning stamped across it. That's not a bug. It's the default state of every e-iceblue trial until a license key gets applied, and the path from that first download to a clean output file runs through more steps than the quickstart page implies.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Spire.PDF's evaluation watermark and per-evaluation license key request cost a team, and where IronPDF renders the same page from one bundled package.

We went through e-iceblue's own documentation, its GitHub repositories, its support forum, and its published licensing terms for this one, not an older comparison's assumptions about where the product stands in August 2026. If you want the broader picture of choosing a .NET PDF library before narrowing to Spire.PDF's specific approach, or just the general pattern for rendering HTML to PDF in C#, both live on Iron Software's site.

What does the trial gate?

Every e-iceblue product runs in evaluation mode until a license is applied, and clearing that gate happens in code rather than through a settings screen in the installer.

// Install-Package Spire.PDF
using Spire.Pdf.License;

LicenseProvider.SetLicenseKey("YOUR-TEMPORARY-KEY");
LicenseProvider.LoadLicense();

That call has to run before the first render, and e-iceblue retired the older shared Spire.License.LicenseProvider namespace that still turns up in search results and older tutorials in favor of the product-specific one shown above. Getting a working key during evaluation means emailing support or posting on e-iceblue's own forum for a temporary license, usually valid for one month, or filing a separate enterprise request for a longer window if the team qualifies for one. It's a step a developer has to discover before the first clean PDF comes out, and the quickstart doesn't mention it.

The license that finally clears the watermark has its own ceiling, too. Developer Small Business licenses one developer at one location for internal use, and the terms state directly that it doesn't cover a public-facing website, a Docker container, or any SaaS, PaaS, or IaaS deployment. Shipping past that requires stepping up to the OEM tier before the application can go live, a second licensing conversation most teams don't plan for until the deployment plan is already set.

What does Spire.PDF get right?

Spire.PDF's Chrome-based converter is a real browser under the hood, not an approximation of one.

// Install-Package Spire.PDF
using Spire.Pdf;

var converter = new ChromeHtmlConverter(@"C:\Program Files\Google\Chrome\Application\chrome.exe");
var options = new ConvertOptions();

converter.ConvertToPdf("https://example.com/invoice", "invoice.pdf", options);

ChromeHtmlConverter drives an actual, already-installed copy of Chrome, executing JavaScript and laying out dynamic content the way Chrome itself would, and e-iceblue told forum users on 17 January 2025 that new feature work is landing on this path rather than the older Qt-based converter. The rest of the library covers more ground than most budget competitors attempt. Beyond HTML input, Spire.PDF converts to and from Word, Excel, PowerPoint, SVG, PostScript, PCL, Markdown, JSON, and raster images, on top of merge, split, form filling, and watermarking on existing PDFs, all from one package. e-iceblue's lighter NuGet package extends that further, with no evaluation warning at all, just its 10-page and 3-page caps enforced in the library's own code rather than a marketing rounding. What all three of those share is the same shape underneath, real capability sitting behind a second piece of infrastructure that the API call alone doesn't provide.

How do Spire.PDF and IronPDF compare?

With those strengths on the table, here is how the two libraries line up across the capabilities that matter for a rendering pipeline.

Capability	Spire.PDF	IronPDF
Rendering engine included in the package	Not included, `ChromeHtmlConverter` drives a customer-installed Chrome, or a downloaded Qt plugin	Yes, `ChromePdfRenderer` ships with Chromium bundled in the NuGet package
Applying a license in code	`Spire.Pdf.License.LicenseProvider.SetLicenseKey` plus `LoadLicense`, requested per evaluation	One key set once, no evaluation watermark to clear afterward
Linux and Docker HTML-to-PDF	Supported, needs a virtual display server and a manual dependency install	Supported without extra setup
Entry-level tier	e-iceblue's page-capped NuGet package, 10 pages per document and 3 pages on conversion output	Trial key covers the full API, delivered by email on signup
Public website or cloud deployment	Requires the OEM tier	Included at every commercial tier
OCR	Sold as a separate e-iceblue product	Available through IronOCR
Export format range	Word, Excel, PowerPoint, SVG, PostScript, PCL, Markdown, JSON, images	Built around PDF creation and editing from HTML, images, and existing PDFs
Entry list price	$999, Developer Small Business, one developer, one location, internal use only	Quote-based

Where does container setup add friction?

Neither rendering engine ships pre-installed, and each one asks for a different kind of setup before it runs anywhere outside a developer's own Windows machine.

The legacy converter needs a plugin fetched separately per platform: the Qt-based plugin has to be downloaded for Windows x86, Windows x64, macOS, or Linux, unzipped next to Spire.Pdf.dll, and pointed at through HtmlConverter.PluginPath, with the Microsoft Visual C++ 2015 Redistributable installed alongside it.
The Chrome-based converter needs Chrome itself: ChromeHtmlConverter drives a copy of Chrome that has to already be on the machine at a path supplied in code, which means provisioning it, patching it, and keeping it at a version the library was tested against, on every machine the code runs on.
Linux and Docker need a virtual display server before either engine renders anything: e-iceblue's own support guidance calls for getting Xvfb running and routing the process through xvfb-run, alongside a dependency list that includes libgdiplus, xfonts-base, xfonts-75dpi, dbus, libnss3-dev, libasound2, and libegl1. Support threads from January 2025 describe the Qt path as closely tied to the host system environment, and show conversions failing outright in containers missing one of those packages.

Cross-platform builds add one more wrinkle worth planning around. Targeting .NET 6 or later without Windows means dropping System.Drawing.Common for the netstandard2.0 build built on SkiaSharp, which drops the System.Drawing.Printing.PrintSettings class along the way.

Does Spire.PDF carry any CVEs?

Spire.PDF's own code has a clean record across the databases that would show one. NVD returns zero results for a Spire.PDF or e-iceblue keyword search, the GitHub Advisory Database lists no advisories against the NuGet package, and Snyk reports no direct vulnerabilities. For a closed-source product with no public advisory feed, that means no CVE in the library's own code turns up across any of the three, not that none could ever exist.

Maintenance is active. Spire.PDF for .NET sits at version 12.8.3, published 14 August 2026. That lighter package lags several releases behind at 12.4.0 from April 2026 and carries no support of any kind. Spire.PDF also has no OCR and no redaction built in. e-iceblue sells OCR as a separate product line entirely, so a pipeline that needs both scanned-document text extraction and PDF generation ends up licensing and integrating two products from the same vendor instead of one.

No key to renew, no watermark

The same job, turning a URL into a PDF with JavaScript rendered, looks different from the first line here.

// Install-Package IronPdf
using IronPdf;

IronPdf.License.LicenseKey = "IRONPDF-MYLICENSE-KEY1A";

var renderer = new ChromePdfRenderer();
PdfDocument pdf = renderer.RenderUrlAsPdf("https://example.com/invoice");
pdf.SaveAs("invoice.pdf");

Setting that key happens once at startup, using the licensing setup IronPDF documents, and Chromium ships inside the package itself, so there's no separate Chrome install to provision, no Qt plugin to unzip per platform, and no Xvfb setup to script into a Dockerfile before a Linux container can render the same page. The trial key itself arrives differently too. IronPDF's key lands by email as soon as the signup form is submitted, not after a support ticket or a forum post asking for a temporary one.

A project that never exceeds that lighter package's 10-page ceiling gets real, usable capability inside that cap. Where the calculus shifts is deployment count. The more machines and containers a rendering pipeline runs on, the more that second-binary tax compounds, and that's the point where bundling the engine starts saving more than it costs.

Is the watermark worth working around?

A project small enough to live inside Spire.PDF's lighter, page-capped package still comes with setup attached, a license key to request, and a browser or display server to keep patched before Linux or Docker enters the picture. For a pipeline that's already past the page cap and running across more than one machine, IronPDF's bundled Chromium and single license key remove that entire layer of setup instead of adding one.

Has your team requested a temporary Spire.PDF license during evaluation, or gone straight for a paid tier to skip the watermark? We would like to hear how that request-and-wait step played out in the comments.

Spire.PDF is a trademark of its owner, and this piece is not affiliated. The details above are drawn from e-iceblue's public documentation, its support forum, and public vulnerability databases as they stood at the time of writing. If a detail has changed since, correct us in the comments.

SharpShooter Reports in 2026: What Still Works

IronSoftware — Fri, 21 Aug 2026 13:14:00 +0000

The confusion with SharpShooter Reports rarely starts with the reporting engine. It starts with the designer. A team inherits a WinForms application where someone embedded Perpetuum Software's report designer inside the host app so business users could build their own layouts without opening a ticket. Nobody currently on the team installed it, nobody kept the setup notes, and the .NET Framework project underneath it is the one nobody wants to move.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where SharpShooter Reports's decade-stale release record and missing current-.NET path cost a team, and where IronPDF renders the same report to PDF on today's .NET from one package.

We checked this against Perpetuum Software's own changelog pages, published system requirements, its reseller listing on ComponentSource, and NVD's CVE records directly.

What does SharpShooter Reports still do well?

SharpShooter Reports' most durable capability, and the one thing IronPDF does not attempt, is a bundled, end-user-facing report designer with its own scripting support. A non-developer can build or adjust a report layout inside the application itself, without a code change or a redeploy, which is exactly why so many of these installs are still running. Its export matrix is wide for a single report definition, covering PDF, HTML, EMF, BMP, JPG, GIF, TIFF, PNG, XLS, Excel XML, CSV, TXT, and RTF from the same report, and .NET Framework support reaches back to version 2.0, the reason it still runs inside WinForms estates current libraries will not touch. Both capabilities sit inside a product whose own vendor stopped publishing anything past 2015, and that gap is what the rest of this piece works through.

That places it as a report designer and document-automation component rather than a PDF rendering library, with a visual layout surface, data binding to arbitrary sources, and scripting hooks IronPDF was never built to have. The surrounding platform, the .NET Framework runtime and its tooling, is aging out from underneath a product no longer being actively developed to follow it.

Rendering on current .NET

That aging platform is exactly where a current renderer takes over. Set the designer's own job aside, and what is left is one export step, and on current .NET it reads like this.

// Install-Package IronPdf
using IronPdf;

var renderer = new ChromePdfRenderer();
using var pdf = renderer.RenderHtmlAsPdf(reportHtml);
pdf.SaveAs("report.pdf");

That renders the report step's HTML into a PDF and writes it to disk, whether the source is a static template or generated from application data.

Where IronPDF is not the answer is the report designer itself. If end users or business analysts are still opening SharpShooter's designer and adjusting report layouts without a developer involved, that capability has no code-only replacement. Moving off it means finding a different designer-driven tool, or accepting that layout changes become a code change and a deploy, a tradeoff worth weighing as part of the migration plan.

Full API documentation covers every option on the renderer, and the NuGet installation path targets current .NET directly, no separate designer runtime required.

If the migration also needs to combine or split existing report output, or lock the result down with edit and print restrictions, both are one call on the same renderer.

Where does the vendor record go quiet?

The rendering path is settled. The product behind the designer is not, and its paper trail stops abruptly.

No vendor-documented release in over a decade: Perpetuum Software's own changelog pages for both Reports.Win and Reports.Enterprise end at version 7.3.1, dated 8 September 2015. A 7.5.0 build circulates through reseller ComponentSource, but no release notes for it exist anywhere, so there is no way to confirm what changed or when it shipped.
No .NET path exists beyond Framework: system requirements list .NET Framework 2.0 and higher, with IDE support ending at Visual Studio 2017, and no .NET Core, .NET 5 or later, or container deployment documented anywhere in the product's history.
The distributor already marked it discontinued: ComponentSource states that SharpShooter Collection has been discontinued. New and additional licenses can still be purchased, but without further product updates or support, and the Lite and Express editions are no longer supported at all.

The same quiet extends to security tracking. NVD returns zero results for a SharpShooter keyword search, and a search for Perpetuum returns exactly one CVE, 2026-28100, belonging to LambertGroup's UberSlider PerpetuumMobile, an unrelated WordPress and jQuery slider plugin, not Perpetuum Software's reporting components. A decade without a documented release means there is no active patch pipeline behind the product, so the absence of CVEs reflects nobody publicly disclosing one against inactive software, not the confirmed record an actively maintained library earns.

That leaves one place the two products still meet on the same ground, the PDF each one produces.

Capability	SharpShooter Reports	IronPDF
PDF output from a report or template	Yes, through the bundled designer's export	Yes, through `ChromePdfRenderer.RenderHtmlAsPdf` on an HTML template
End-user report designer, no code change required	Yes, the product's core value	No built-in designer, layout comes from the HTML and CSS you control in code
.NET Framework 2.0+ support	Yes	No, targets current .NET only
Current .NET (6, 8, 9, 10) support	Not documented, no path published	Yes, through the `IronPdf` NuGet package
Cross-platform and container deployment	Not documented	Yes, Windows, Linux, macOS, and containers
Product line last documented	`Reports.Win` and `Reports.Enterprise`, version 7.3.1, dated 8 September 2015	`IronPdf` NuGet package, version `2026.7.2`, shipped June 2026

Keep the designer, or move the render?

A decade past its last documented release, SharpShooter Reports has no path forward. No current .NET support, no cross-platform story, and a distributor that already called the product line discontinued.

When the report-authoring workflow still matters to the people using it, that capability needs a real replacement. If what is left is a data-bound template that needs to become a PDF, a currently maintained renderer picks that up directly.

Is the SharpShooter designer still something your end users actually open, or has your application quietly settled into generating fixed-layout PDFs from code? That answer changes what the right migration looks like, so tell us which one matches your situation in the comments.

If a data-bound HTML template is the last piece left in your pipeline, IronPDF's free trial lets you run the renderer above against your own report output before committing to anything.

SharpShooter Reports is a trademark of its owner, and this piece is not affiliated. The changelog, system requirements, distributor status, and CVE details above are drawn from Perpetuum Software's own documentation, ComponentSource, and NVD as they stood at the time of writing. If a detail has changed since, correct us in the comments.

Nevron Vision for SSRS vs IronPDF: The Report-Server Bet

IronSoftware — Thu, 20 Aug 2026 20:41:00 +0000

Searching for a Nevron Reporting alternative turns up nothing useful, because no product carries that name. Nevron sells no report designer or report platform, and it does not ship a report writer of its own. What it actually sells is Nevron Vision for SSRS, a set of chart, gauge, map, and barcode Custom Report Items that plug directly into Microsoft SQL Server Reporting Services. Getting that distinction right changes what a fair comparison looks like, because a visualization suite and a rendering library are built to answer different questions entirely.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Nevron Vision for SSRS's report-server deployment cost a team, and where IronPDF renders the same PDF standalone.

We checked Nevron's own product pages, its documentation, and NVD's CVE records directly rather than relying on an older search result's product name, and IronPDF's own documentation gets held to that same standard below.

What Does Nevron's Report-Server Commitment Cost?

Nevron Vision for SSRS is a Custom Report Item, not a standalone renderer. It only runs inside a report that has already been deployed to SQL Server Reporting Services, and there is no direct call that hands back a PDF without that deployment already in place. A team whose actual requirement is turning application data into a PDF is signing up for a full SSRS installation and a Windows Server host as a prerequisite, layered on top of the component license rather than instead of it. That is a real operational commitment, meaning a report server to patch and keep current, plus a rendering pipeline that only exists inside someone else's product.

A .NET application that needs the same output without any of that can skip the report-server requirement entirely with IronPDF, which renders HTML to PDF standalone inside the application process. The same renderer runs on Windows, Linux, and macOS alike, so the deployment target is a normal .NET host rather than a dedicated report server.

Which Job Does IronPDF Replace?

That standalone path is where IronPDF steps into one specific job, turning application data into a PDF outside of SSRS entirely, and the call is direct.

using IronPdf;

var renderer = new ChromePdfRenderer();
var pdf = await renderer.RenderHtmlAsPdfAsync(reportHtml);
pdf.SaveAs("report.pdf");

That call returns a PdfDocument in memory and writes it to disk in the same statement, with no report server or Windows Server host in the path, and no Custom Report Item runtime to keep alive.

The export step is the only piece this replaces. IronPDF has no charting, gauge, or mapping component of any kind, so switching to it replaces none of the Custom Report Item authoring layer. A team that needs Nevron's chart and gauge depth inside an SSRS report keeps using it for that job. The PDF step at the end of that pipeline is the only place this comparison was ever fair to make.

IronPDF produces that PDF from one package with no report-server host in the path. The async rendering pattern above and the ChromePdfRenderer class reference cover the rest of what the standalone path looks like inside a real application.

What Did Nevron Build Into the Visualization Layer?

The Custom Report Items span 2D and 3D charting, gauges, choropleth maps, and 28 linear barcode types alongside QR, DataMatrix, and PDF417, dropped straight into the SSRS report designer the same way Microsoft's own native chart and gauge items are. The broader Nevron Open Vision codebase behind that authoring layer spans WinForms, WPF, Blazor WebAssembly, and macOS from a single presentation layer, and recent releases have pushed further still, adding LiDAR point-cloud import and GPU shader optimization. Nevron Software has been building this line since 1998, and it has kept shipping through every major .NET platform shift since, a 28-year track record most components in this space cannot claim. All of that authoring depth lives inside the report designer, though, and none of it is a path to a PDF by itself. The Custom Report Items produce the visualization. Something else in the stack still has to render the report that contains them.

Where Does a PDF Come Out of Each Stack?

The table below stays narrowly on the one place these two products actually overlap, producing a PDF, since a full feature comparison would mean judging a visualization suite against a rendering library on terms neither was built for.

Capability	Nevron Vision for SSRS	IronPDF
PDF output	Yes, through SSRS's own `PDFRenderer` rendering extension	Yes, direct with `ChromePdfRenderer.RenderHtmlAsPdfAsync`
Report-server host required	Yes, runs only inside a report deployed to SSRS	No, standalone through the `IronPdf` package in any .NET app
Source of a report's visual content	Charts, gauges, and maps authored as Custom Report Items in the designer	HTML and CSS rendered through `ChromePdfRenderer`, the same layout engine as Chrome
Documented SQL Server compatibility	2008 through 2019, plus Power BI Report Server	No SQL Server or report-server version to match
Cross-platform or container deployment	Not documented for the SSRS host	Yes, Windows, Linux, macOS, and containers
Licensing model	Per developer, plus a per-web-server deployment fee	Commercial, licensed by deployment, with support and updates included

What Does the License Cost Over Time?

Nevron's developer licenses are priced and sold per developer, with an additional per-web-server fee once a report goes to deployment beyond the licensed seats, a structure that scales differently than a per-application or a flat per-server license. That is worth modeling against actual team size and deployment topology before committing to a tier, and the current figures belong on nevron.com rather than a reseller listing, since list prices move. IronPDF is commercial and licensed by deployment instead, which changes the modeling question from developer headcount to how many applications and servers actually render a PDF.

Where Is Nevron's Compatibility Ceiling?

The documented supported-server list for the SSRS product runs SQL Server 2008 through 2019, plus Power BI Report Server. SQL Server 2022 does not appear on that list, which is worth confirming directly with Nevron before a new deployment standardizes on it, since the vendor's own written compatibility claims do not currently extend that far.

The security record is clean rather than thin. An NVD keyword search for Nevron returns exactly one result, CVE-2002-0110, and that CVE belongs to Nevrona Designs' MiraMail, an unrelated company with a similar name, not Nevron Software. No GitHub Advisory or Snyk entries exist against Nevron's own components either.

Maintenance is active on the current line. Nevron Open Vision for .NET shipped a 2026.1 release in the first half of 2026, and Nevron's own guidance on the older Nevron Vision for .NET line is that it remains supported while active development has moved to Nevron Open Vision for .NET going forward. A team standardizing on the platform today has a clear signal about which package a Visual Studio project should reference. Existing projects should be checked against the current line, since new development can drift onto the legacy one without anyone noticing.

Which piece of the stack do you actually need?

When in-report visualization inside SSRS is the actual requirement, that's not a reason to move off Nevron. It is a reason to be precise about which piece of a reporting pipeline each tool owns, and what standing up the report-server side of that pipeline commits a team to for as long as the license runs. A deployment decision turns on that distinction more than on any feature checklist, and we keep coming back to it for exactly that reason.

Is your team running Nevron for the visualization, the PDF output, or both, and if you split those two jobs across two tools, what would actually get easier? The comments are open if you want to compare notes on how that report-server commitment played out in practice.

If the deployment question is whether a .NET application can produce that same PDF without any of the SSRS stack, IronPDF has a free trial so the snippet above can run against a real report before anything gets licensed.

Nevron and Nevron Vision for SSRS are trademarks of Nevron Software, and this piece is not affiliated with the company. The compatibility, licensing, and CVE details above are drawn from Nevron's own documentation and NVD as they stood at the time of writing. If a detail has changed since, correct us in the comments.

Fluent by Apryse: Word Templates vs Rendered PDFs

IronSoftware — Thu, 20 Aug 2026 16:06:00 +0000

// Install-Package FluentEngine
using net.windward.api.csharp;
using WindwardInterfaces.net.windward.api.csharp;

Report.Init();
using var template = File.OpenRead("Invoice-Template.docx");
using var output = File.Create("invoice.pdf");
Report report = new ReportPdf(template, output);

using var data = new AdoDataSourceImpl("System.Data.SqlClient", connectionString);
report.ProcessSetup();
report.ProcessData(data, "SQL");
report.ProcessComplete();

That call merges the SQL rows into Invoice-Template.docx and writes invoice.pdf, with no HTML or CSS in the path, and a layout change happens by editing that Word document, not by a code deploy. Fluent does not render a PDF the way a rendering library does, a misconception that trips up most comparisons of the two. It merges live data into a Word, Excel, or PowerPoint template a business analyst designed and still owns. IronPDF instead renders HTML and CSS a developer wrote and checked into source control. The vendor's naming history makes the two engines easy to confuse by accident, since Windward Studios built this engine in 1996, PDFTron acquired the company on 8 April 2021, PDFTron itself became Apryse on 8 February 2023, and Windward Core was renamed Fluent in 2023. The old name never left the code, either, since the current NuGet package installs as FluentEngine, the config section is still <WindwardReports>, and the REST client class is WindwardRestApi.Api.WindwardClient. Both search terms point to the same product.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Fluent's .NET Framework-only embedded engine cost a team on current .NET, and where IronPDF renders the same report from one package.

What does adopting Fluent on current .NET cost?

Apryse's documentation states the embedded engine supports .NET Framework only, with no embedded SDK for .NET Core or .NET 5+. Both FluentEngine and the legacy WindwardEngine package target net451 and depend on IKVM.WINDWARD, a Java-to-.NET compatibility layer, not a native .NET Core build. A team on current .NET gets routed to the REST engine instead, and that is not a clean upgrade path, since the actively developed Java RESTful Engine needs JDK 17 and Tomcat 10.1, while the .NET REST engine is labeled Legacy in Apryse's docs and still depends on classic ASP.NET MVC/WebApi 5.2.7. Either route adds infrastructure a .NET-only shop wasn't running, and Fluent Designer compounds it for a Mac-standardized team, since it runs only as a Windows Office add-in with no Mac support and no browser path.

The one disclosed security event in Fluent's history belongs to that same Java REST engine, not the core product. A keyword search of NVD for windward returns no results and the GitHub Advisory Database lists nothing either, though Fluent is closed source with no public advisory feed, so the zero count means nothing was publicly disclosed rather than audited. Log4Shell, CVE-2021-44228 and CVE-2021-45046, affected the Java and Java RESTful engines from version 20.2.0 onward through the bundled Log4j dependency, and Apryse patched it in 21.5.2, since the vulnerability lived entirely in that Java dependency chain and left the .NET engines and Designer unaffected.

None of this changes Fluent's value case. The template-ownership model and output matrix hold regardless of engine. What changes is that a .NET Core or .NET 5+ shop adopting Fluent today is choosing between an unsupported embedded engine and a REST engine needing either a Java stack or a deprecated ASP.NET dependency, worth knowing before building a template-authoring workflow around it.

Where does a rendering call replace a template engine?

Against that engine question, the same reporting job looks like this when it's driven from application data instead of a template file.

// Install-Package IronPdf
using IronPdf;

var renderer = new ChromePdfRenderer();
PdfDocument pdf = renderer.RenderHtmlAsPdf(reportHtml);
pdf.SaveAs("report.pdf");

That call renders whatever HTML the application already builds and writes report.pdf, with no separate engine choice and no template file to maintain. Without standing up Tomcat or a JDK, RenderHtmlAsPdf is a direct fit on net8.0 through net10.0, and the same call runs unchanged on Linux if the deployment target isn't Windows. Reports already rendering as Razor views convert the same way, and the Razor-to-PDF path covers a reporting layer inside an ASP.NET Core app.

Where IronPDF is not the answer is business-user template authoring, no-code data connectors, and a central template repository, none of which a rendering library is built to do. If a report's content needs to stay editable by business users, that workflow stays on Fluent regardless of .NET version, and some teams run both for the two halves of a pipeline they have.

How do Fluent and IronPDF compare?

Set side by side, and scoped strictly to document output since Fluent's designer, connector catalogue, and template manager have no equivalent in a rendering library, the two divide like this.

Capability	Fluent (Windward)	IronPDF
PDF output mechanism	Merges data into a `ReportPdf` template job	`ChromePdfRenderer.RenderHtmlAsPdf` renders markup directly, no template file
Business-user template authoring	Word, Excel, PowerPoint, no code	HTML and CSS control layout, authored and versioned with the app
.NET target for the embedded engine	`net451` only, via `FluentEngine`	Native `net8.0`, `net9.0`, and `net10.0`
Local install off Windows	Java RESTful Engine or legacy ASP.NET MVC/WebApi 5.2.7	One `IronPdf` package across Windows, Linux, and macOS
Data-source connectors	150+, no code required	Renders whatever HTML the application already builds from any data source
Template design tooling	Windows desktop, Microsoft Office required	`ChromePdfRenderer` runs headless in CI, no desktop app needed

The table draws on Apryse's own Fluent documentation and NuGet listings. Those 150+ connectors span SQL and NoSQL databases alongside SaaS platforms like Salesforce, Dynamics, and SharePoint, and the same template outputs to native Word, Excel, or PowerPoint alongside PDF/A and PDF/UA-compliant PDF, with Fluent Manager as a central repository on top. Owning that workflow, letting a business analyst edit a report without a code deploy, is a different job from what a rendering library does, and a real one for a team built around it.

A template engine, or a renderer?

What complicates adopting Fluent today on current .NET is the engine question. The embedded engine doesn't run past .NET Framework, and the alternative is either a Java stack or a docs-labeled Legacy path. Know which engine a given .NET version actually supports before building a template-authoring workflow around a choice unavailable on the target runtime. Full API coverage is in IronPDF's documentation, and there is a free trial so the rendering path above can be tested against a real report first.

Did your team hit the .NET Framework ceiling before or after building templates out in Fluent Designer, and did you end up standing up the Java REST engine or staying on the legacy .NET one? We would like to hear which way it went in the comments.

Fluent, Windward, and Apryse are trademarks of Apryse Software Inc, and this piece is not affiliated with the company. The details above are drawn from Apryse's Fluent documentation, its NuGet listings, and NVD as they stood at the time of writing. If a detail has changed since, correct us in the comments.