GroupDocs.Assembly for .NET 26.6 Release Notes

GroupDocs.Assembly for .NET 26.6 is built on the latest underlying document engines and ships with a new, modular package layout. The NuGet package is now split into a lightweight router plus per-target-framework runtime packages, adding .NET 6, .NET 8, and .NET 10 builds. Underlying document generation engines have been refreshed to their current releases to deliver the best performance, stability, and security available across all supported document formats.

Full list of changes in this release

Enhancements

NuGet package split — per-target-framework runtime packages

To keep the package well under NuGet’s 250 MB limit as more target frameworks are added, GroupDocs.Assembly is now published as a lightweight router metapackage plus one runtime package per target framework:

• GroupDocs.Assembly — the router (a few KB). You still install this; nothing changes for consumers.
• GroupDocs.Assembly.Net40Client — .NET Framework 4.0 Client Profile assemblies
• GroupDocs.Assembly.Net462 — .NET Framework 4.6.2 assemblies
• GroupDocs.Assembly.NetStandard20 — .NET Standard 2.0 assemblies (Mono, Unity, Xamarin, .NET Core 3.x)
• GroupDocs.Assembly.Net60 — .NET 6 assemblies
• GroupDocs.Assembly.Net80 — .NET 8 assemblies
• GroupDocs.Assembly.Net100 — .NET 10 assemblies

When you install GroupDocs.Assembly, NuGet automatically resolves the runtime package matching your project’s target framework. Install command, namespaces, types and public API are unchanged — you’ll just see one extra package (the runtime package for your TFM) under Dependencies.

# Unchanged — the router picks the right runtime package for your TFM
dotnet add package GroupDocs.Assembly

# Or, if you prefer, install a specific runtime package directly
dotnet add package GroupDocs.Assembly.Net80

Upgrade the underlying document generation engines

The bundled document generation engines have been updated to their latest releases to deliver the best performance, stability, and security across all supported templates and output formats. Template processing, expression evaluation, data-source binding and output rendering across every supported format are now produced by these updated engines.

Note: Because the underlying rendering and serialization engines changed, regenerated documents may differ slightly at the byte/pixel level (anti-aliasing, content-stream packing, text layout, serialization details) while remaining visually and functionally equivalent. If your pipeline compares generated output byte-for-byte against stored baselines, refresh those baselines after upgrading. See Important Notes for Generated Documents below for the specific areas to expect drift in.

Verification. Existing assembly code continues to compile and run; template syntax, expression evaluation, data-source binding and the public API are all source-compatible with the prior release.

using GroupDocs.Assembly;

DocumentAssembler assembler = new DocumentAssembler();
assembler.AssembleDocument(
    "template.docx",
    "output.docx",
    new DataSourceInfo(customer, "customer"));

Security

Resolve System.Formats.Asn1 security advisory

Microsoft’s security advisory GHSA-447r-wph3-92pm flags a high-severity vulnerability in System.Formats.Asn1 versions <= 8.0.0. The package was previously being pulled in transitively at version 7.0.0 through some of the underlying runtime dependencies.

26.6 forces NuGet to resolve the patched System.Formats.Asn1 9.0.5 for all modern target frameworks:

• The GroupDocs.Assembly.Net60, GroupDocs.Assembly.Net80, and GroupDocs.Assembly.Net100 runtime packages declare System.Formats.Asn1 9.0.5 as a dependency. Consumer projects that install GroupDocs.Assembly therefore also resolve the patched version and no longer see the advisory in their own builds.
• Consumers do not need to change any code; the next NuGet restore picks up the safe version automatically.

There is no behavioural impact — the patched version is binary-compatible with the previously resolved one.

Fixes

UTC (Z) dates shifted by host timezone when parsed from JSON

ASSEMBLYNET-118. JsonDataSource previously parsed ISO-8601 instant strings with a trailing Z (e.g. "2024-11-03T23:00:00Z") by dropping the Z and treating the remaining timestamp as wall-clock time in the host’s default timezone. On a UTC hosts the symptom was invisible because the local-time interpretation coincided with the intended UTC instant.

Scope.

• Affects ISO-8601 strings with trailing Z and any explicit ±HH:mm / ±HHMM / ±HH offset.
• Does not affect strings without a timezone designator — those continue to be treated as local time, same as prior releases.
• Does not affect any other public API (XmlDataSource, CsvDataSource, template-side [date]:"format" rendering of already-typed DateTime values).

Public API and Backwards Incompatible Changes

Important Notes for Generated Documents

Migrating from netstandard2.0 to net6.0 or later (optional)

Consumers who choose to migrate from .NET Standard 2.0 to a native modern TFM (net6.0, net8.0, or net10.0) as part of the upgrade should be aware of one indirect change. Migration is optional in 26.6 — the netstandard2.0 runtime package is still shipped and continues to work — but customers who can move to a native TFM benefit from a smaller install footprint and direct platform-imaging stack.

• On netstandard2.0, the runtime image-rendering stack uses a SkiaSharp-based drawing path with a managed PNG encoder and Skia’s font metrics.
• On net6.0/net8.0/net10.0, image rendering uses System.Drawing.Common, which delegates to the platform’s native imaging stack — GDI+ on Windows, libgdiplus on Linux/macOS.

Generated documents that embed rasterised images, charts rendered to PNG, or text in non-standard fonts may show sub-pixel position, anti-aliasing, or PNG-byte differences compared to the same input processed by the previous netstandard2.0 assembly. The output is functionally equivalent — same pixels at typical viewing zoom levels, same characters, same layout — but byte-comparison against pre-upgrade reference files will fail. Consumers who maintain reference files for regression testing should refresh those files after migrating off netstandard2.0.

This is not a change introduced by GroupDocs.Assembly itself; it reflects the different imaging stack available to the consumer’s chosen TFM.

Presentation output — minor serialisation shifts in PowerPoint files

The refreshed presentation rendering engine produces PowerPoint output that is functionally identical but byte-different from prior versions for the same template + data:

• Default chart-axis attributes (e.g. c:orientation val="minMax") are now emitted explicitly where prior versions omitted them as schema defaults — charts render identically in PowerPoint.
• docProps/app.xml HeadingPairs capitalisation changed (Fonts used → Fonts Used).
• ppt/viewProps.xml includes an extra empty <p:guideLst /> element inside notesViewPr.
• Embedded chart data XLSX (ppt/embeddings/Microsoft_Excel_Worksheet*.xlsx) re-serialised via the newer spreadsheet engine.

Consumers who byte-compare generated PPTX files against pre-26.6 baselines should expect failures and refresh their reference files. Consumers who validate output by opening the PPTX in PowerPoint or by structured field assertion are unaffected.

Barcode rendering — stricter minimum-size validation ⚠️ may break existing templates

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

System.InvalidOperationException : Size of barcode is too small.
Please, increase the xDimension or resolution.

The new validator rejects barcode dimensions that older versions silently accepted. The fix is template-side: increase the barcode’s xDimension (the 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.

Spreadsheet output drift — chart and image serialisation

The spreadsheet rendering engine refresh produces XLSX output that is byte-different from prior versions for the same template + data, primarily around chart serialisation. Affected areas:

• Chart axis <c:title> emission changed in some configurations — the element is now omitted when the source template’s axis title is implicit, where older versions emitted an empty title element. Charts that explicitly carry an axis title in the source template are unaffected; the change surfaces only on a small number of templates that relied on the implicit-empty-title behaviour.
• Chart axis numFmt precision — the value-axis numFmt formatCode flipped from General to 0% for certain percentage-typed columns where the source format was already a percentage. Visual rendering of the chart is unchanged.
• Chart point and series defaults — newer chart types (donut, treemap, sunburst, waterfall, funnel, box-and-whisker, histogram) get tighter default styling out of the box. If a template inserts one of these chart types via assembly tags, the rendered output uses the engine’s newer defaults rather than the older fall-back defaults.
• Embedded image bytes — the chart-image renderer produces PNGs with a different encoder build than older versions. Visually identical, byte-different.
• _files_files redundant subfolder — the xlsx resource-save layout no longer creates a redundant _files_files inner subdirectory. Consumers who programmatically walk the resource folder tree should expect a flatter structure.

Generated spreadsheets render and calculate the same as before. Customers with byte-comparison or exact-folder-structure validation pipelines should refresh their references. Customers who inspect saved files visually or by reading cell values via the engine API are unaffected.

Spreadsheet — Pcl (Printer Command Language) is now a valid save format

The refreshed spreadsheet rendering engine added Pcl to its supported save formats. Customers who previously caught an InvalidOperationException for Pcl on spreadsheet templates should remove that error-handling branch — saving to Pcl now succeeds.

Word document output — numeric formatting precision drift

The word-processing rendering engine refresh changed the rounding behaviour of one numeric format token. Templates that format a number like 123.456 using a "#.##" / "0.##" token previously rendered 123.46 (rounded to 2 decimals) and now render 123.456 (trailing digits preserved).

Templates that need explicit two-decimal precision should use "0.00" or "F2" instead of the optional-digit "#.##" / "0.##" patterns. Documents that rely on the previous rounding behaviour will see different rendered numbers; the underlying data is unchanged, only the textual representation differs.

This affects any template using the optional-digit format token — typical impact sites include invoice totals, currency-rounded subtotals, percentage columns, and any computed numeric field that does not explicitly pin its precision.

Email output — engine refresh and serialisation changes

The refreshed email rendering engine produces .eml / .msg / .mhtml output that is functionally equivalent for the same input — same body, same attachments, same recipients, same headers — but byte-comparison against pre-upgrade reference files will fail because:

• MIME structure and header serialisation were adjusted for round-tripped .eml / .mhtml / .msg.
• Stricter character-encoding handling on saves to .eml.
• The Outlook .msg writer may emit different property ordering.

Consumers who maintain reference .eml / .msg files for regression testing should refresh those files. Consumers who validate by reading the message back via the email engine and asserting on parsed fields (subject, body, recipients) are unaffected.

Locale-driven time-format zero-padding on .NET 6.0+

Independent of the engine refresh: on .NET 6.0 and later, the runtime’s ICU-backed culture data zero-pads the hour for some locales where older .NET Framework versions did not. Templates that hardcode expected datetime strings against a specific format may need updating. Templates that use the consumer’s CultureInfo.CurrentCulture end-to-end will render whatever the runtime emits. This is a .NET / ICU change, not a GroupDocs.Assembly change — but it surfaces visibly on the modern-runtime TFMs that 26.6 promotes consumers onto.