Fluent by Apryse: Word Templates vs Rendered PDFs

// 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.