[Release] GroupDocs.Assembly for .NET 26.6

GroupDocs.Assembly Product Family
1

Dear GroupDocs users, we’re pleased to announce GroupDocs.Assembly for .NET 26.6. This release restructures the NuGet packaging to add .NET 6, .NET 8, and .NET 10 builds, refreshes all bundled document generation engines, patches a high-severity transitive security advisory, and fixes a customer-reported issues.

:rocket: NuGet package split — .NET 6, .NET 8, and .NET 10 support added

The package is now published as a lightweight router metapackage plus a dedicated runtime package per target framework:

Package Target Framework
GroupDocs.Assembly Router install this as before
GroupDocs.Assembly.Net462 .NET Framework 4.6.2
GroupDocs.Assembly.NetStandard20 .NET Standard 2.0
GroupDocs.Assembly.Net60 .NET 6
GroupDocs.Assembly.Net80 .NET 8
GroupDocs.Assembly.Net100 .NET 10

NuGet resolves the correct runtime package automatically. The install command, namespaces, types, and public API are unchanged — you’ll just see one extra transitive package under Dependencies.


# Unchanged install command — NuGet picks the right runtime package for your TFM

dotnet add package GroupDocs.Assembly

Deprecation notice: GroupDocs.Assembly.Net40Client and GroupDocs.Assembly.NetStandard20 will be removed in ~3 months (planned: September 2026). Migrate to Net462 for .NET Framework or Net60/Net80/Net100 for .NET Core / .NET 5+. No code changes are required. If this timeline is a blocker for your project, please open a topic on the forum before the deprecation lands. (ASSEMBLYNET-115)

:wrench: Engine upgrades

All bundled document generation engines have been updated to their latest releases for the best performance, stability, and security across every supported template and output format.

Engine Template/output formats
Word-processing DOC, DOCX, DOT, DOTX, RTF, ODT, TXT, HTML, MHTML, XPS, PDF
Spreadsheet XLS, XLSX, XLSM, XLSB, XLTX, XLTM, XLAM, ODS, CSV, TSV, MHTML, HTML, XPS, PDF
Presentation PPT, PPTX, PPS, PPSX, ODP, XPS, PDF
Email EML, EMLX, MSG, MHTML
Barcode embedded barcode rendering inside every template family

Template syntax, expression evaluation, data-source binding, and the public API remain source-compatible. The one visible effect is byte-level serialisation drift on regenerated documents — same input still produces the same document, but reference files used for exact byte-comparison against pre-26.6 baselines will need refreshing (see the full release notes for the per-format detail). (ASSEMBLYNET-117)

:lock: Security — System.Formats.Asn1 advisory resolved

Microsoft’s high-severity advisory GHSA-447r-wph3-92pm affects System.Formats.Asn1 <= 8.0.0, which was previously being pulled in transitively at version 7.0.0. The Net60, Net80, and Net100 runtime packages now declare the patched System.Formats.Asn1 9.0.5 directly, so consumers receive the safe version automatically on the next NuGet restore. The patched version is binary-compatible with the previously resolved one — no code changes required. (ASSEMBLYNET-116)

:bug: Fix — UTC (Z) dates dropped when parsed from JSON

JsonDataSource previously parsed ISO-8601 instant strings with a trailing Z (e.g. "2024-11-03T23:00:00Z") by dropping the offset designator and interpreting the value as local time. On non-UTC hosts this silently shifted the resulting DateTime by the host’s UTC offset; on UTC hosts the symptom was invisible.

26.6 honours the offset designator (Z or any explicit ±HH:mm / ±HHMM / ±HH) and returns the canonical UTC value. Strings without a timezone designator continue to be treated as local time, preserving prior behaviour for everything else. XmlDataSource, CsvDataSource, and template-side [date]:"format" rendering of already-typed DateTime values are unaffected. (ASSEMBLYNET-118)

:warning: Behaviour change — stricter barcode size validation

The refreshed barcode engine enforces a stricter minimum barcode size. Existing templates that worked under older versions may now throw at assembly time:


System.InvalidOperationException : Size of barcode is too small.

Please, increase the xDimension or resolution.

The fix is template-side: increase the barcode’s xDimension (narrowest bar width) or Resolution in the source template. Templates that already produce visually scannable barcodes typically pass the new validator without changes. If you operate a large template library and cannot adjust all templates at once, consider gating the upgrade per template set after running each set through 26.6 to identify which need re-sizing.

:link: Resources

As always, if you run into any issues or have questions after upgrading, please open a new topic and we’ll be happy to help. Templates with tightly sized barcodes should be tested against 26.6 before rolling out in production; customers still on Net40Client or NetStandard20 are encouraged to plan their migration ahead of the September 2026 removal.