Latest Release (July 2026)

GroupDocs.Assembly for .NET 26.7 refreshes the underlying document generation engines and fixes two template-expression resolution issues — one affecting data models built from interfaces, and one affecting custom KnownTypes functions that take a single DataRow.

Full list of changes in this release

Major Changes

• Upgrade the underlying document generation engines ⚙️
• Template expressions could not use members inherited from a base interface 🐛
• Custom KnownTypes function taking a single DataRow was not resolved from a JSON object node 🐛

Upgrade the underlying document generation engines

The bundled Word, Spreadsheet, Presentation, Email and Barcode engines have been refreshed to their current releases for the best performance, stability and security across every supported format. Template syntax, expression evaluation, data-source binding and the public API stay source-compatible — the only visible effect is byte-level serialisation drift on regenerated outputs. See the full release notes for the per-format details.

Template expressions could not use members inherited from a base interface

When data was exposed through interfaces, a template expression that read a member declared on a base interface failed — the common case being the logical-NOT operator on a Boolean flag (e.g. items.Where(x => !x.Disabled) where Disabled was declared on a base interface). The engine built its bindings from the element’s interface type only, which does not report members inherited from base interfaces, so the member fell back to an untyped binding. Inherited interface members now resolve and evaluate with their declared type, and the x.Disabled == false workaround is no longer required. Class-based (POCO) models were never affected.

Custom KnownTypes function taking a single DataRow was not resolved from a JSON object node

A custom static function registered through DocumentAssembler.KnownTypes that declares a single System.Data.DataRow parameter was not resolved when called with a JSON object node such as root, because the object node was exposed as an enumeration of DataRow that did not convert to a single DataRow during overload resolution. The single-row path is now tried when normal overload resolution finds no match, so these calls resolve and the IEnumerable/object workaround is no longer required; calls that already resolved keep their existing binding.