Download Latest Version 0.105.0 source code.tar.gz (9.2 MB)
Email in envelope

Get an email when there's a new version of ClosedXML

Home / 0.104.1
Name Modified Size InfoDownloads / Week
Parent folder
0.104.1 source code.tar.gz 2024-09-30 9.0 MB
0
0.104.1 source code.zip 2024-09-30 10.2 MB
0
README.md 2024-09-30 20.7 kB
0
Totals: 3 Items   19.3 MB 0

Release notes from 0.102.1 to the 0.104.1.

Summary of breaking changes is available at docs.closedxml.io: * Migration from 0.102 to 0.103 * Migration from 0.103 to 0.104 * New calculation engine just works in a different way and will behave slightly differently.

OpenXML SDK

OpenXML SDK has released version 3. The 0.104.0 uses it as a dependency.

XLParser replaced with ClosedParser

The XLParser has been replaced with ClosedParser. The key benefits are * performance - ~2μs/formula, it's likely formulas will be parseable on the demand, necessary for construction of dependency tree * A1/R1C1 parsing parity - both modes can be parsed with no problems * AST oriented - it's likely a construction of AST in memory won't even be necessary, just use AST factory to evaluate formula directly

There is also a visualizer to display AST in a browser at https://parser.closedxml.io

image

Formula Calculation

In previous version, formulas used to be calculated recursively. Each formula checked it's supporting cells for other formulas and if there were some, they were recursively evaluated. There was some logic to decrease number of evaluations. That works for a very simple cases, but isn't very good for various non-happy paths (i.e. cells weren't calculated when they should be).

This version has replaced it with a standard * dependency tree for checking which formulas are dirty and need to be recalculated * calculation chain that manages dependencies and order of formulas during calculation

For more info, see docs, the Microsoft has a page about principles Excel Recalculation and there is one with API at docs.closedxml.io.

image

Structured references

New parser also allows a basic evaluation of structured references. Format of structured reference must use official grammar, not Excel friendly names (e.g. Pastry[@Name] is user-friendly name for Pastry[[#This Row],[Name]]). It's now possible to 

:::csharp
using var wb = new XLWorkbook();
var ws = wb.AddWorksheet();
ws.Cell("A1").InsertTable(new Pastry[]
{
    new("Cake", 14),
    new("Waffle", 3),
}, "Pastry");

ws.Cell("D1").FormulaA1 = "SUM(Pastry[Price])";
ws.Cell("D3").FormulaA1 = "\"Pastry \" & Pastry[[#This Row],[Name]]";
wb.RecalculateAllFormulas();

Console.WriteLine($"Expected: {17}, Actual: {ws.Cell("D1").Value}");
Console.WriteLine($"Expected: \"Pastry Waffle\", Actual: {ws.Cell("D3").Value}");

Expected: 17, Actual: 17 Expected: "Pastry Waffle", Actual: Pastry Waffle

Renaming sheet updates formulas

When a sheet is renamed, a formula referencing the sheet is also updated. This is a part of long term effort to fix effects of structural changes of a workbook. It will be a long road (e.g. sheet still delete doesn't swicth to #REF!),** but is one of basic features that should be working acorss the board.

:::csharp
using var wb = new XLWorkbook();
var sheet = wb.AddWorksheet();
var anotherSheet = wb.AddWorksheet("Another");
sheet.Cell("A1").FormulaA1 = "Another!B4";
anotherSheet.Name = "Changed";
Console.WriteLine(sheet.Cell("A1").FormulaA1);

Changed!B4

Workbook structure

Internal structure has been cleaned up and optimized.

The dirty tracking has been moved out of cells to formulas and thus memory taken up by a single cell value is now only 16 bytes instead of 24 (?) bytes in 0.102. Of course there are some other structures around that take up memory as well, but the single cell value is now 16 bytes (I hoped for 8, but not feasible with double, DateTime and TimeSpan as possible cell values - all take up 8 bytes... not enough bits).

The same string in different instances is now not duplicated, but only one instance is used. As seen on following test, it can lead to significant decrease in memory consumption. 250k rows with 10 text rows (same string, different instance): 117 MiB om 0.103 vs 325 MiB in 0.102.1.

InsertData performance

Insert 250k rows of 10 columns of text and 5 columns of numbers (gist).

Description Rows Columns Time/Memory to insert data Save workbook Total time/memory
0.103.0-beta 250 000 15 1.619 sec / 117 MiB 6.343 sec 477 MiB
0.102.1 250 000 15 7.160 sec / 325 MiB 6.676 sec 692 MiB

Loading of cells is now done through streaming

Basically workbooks with a large amount of cells should see ~15%-20% speedup (as long as there are mainly values, not styles or OLAP metadata....).

Reading the 250k from previous chapter:

Description Rows Columns Time to load data Used memory
0.103.0-beta 250 000 15 15.648 sec 236 MiB
0.102.1 250 000 15 20.460 sec 329 MiB

Of course, this includes all stuff from 0.103.0-beta. Version 0.103 never got a non-beta release.

Pivot tables

The internal structure of pivot tables, along with most other features, has been completely overhauled. This update should significantly reduce crashes when loading and saving workbooks containing pivot tables.

The main issue with the previous internal structure was that it didn't align with the structure used by OOXML. This was problematic because we need to support all valid files. As a result, we have to handle a wide range of inputs and correctly convert them to our internal structure, which is rather hard. A more clear 1:1 mapping with OOXML is much simpler and more reliable.

AutoFilter

The Autofilter feature has been revamped, which includes some API changes. Its behavior is now more closely aligned with how Excel operates. The XML documentation provides detailed explanations, and there is a dedicated documentation page. Several bugs have also been fixed.

For more details, refer to the Autofilter section of the migration guide.

Source link

Although ClosedXML still doesn't have source package (Fody static weaving causes pdb mismatch and nuget will refuse symbol package), there is a source link info in the package.

SourceLink basically takes a repository and a commit from the package and retrieves source from directly from forge (in this case GitHub).

CommonCrawl dataset

When workbook is a valid one, ClosedXML shouldn't throw on load. That is a rather high priority (more than saving or manipulation). Unfortunately, that is hard to find such areas that cause most problems.

One of activities that was going in a background is trying to use excel files around the internet (found by CommonCrawl) to evaluate how bad it is. There aren't results yet, but it is something that is going on.

What's Changed

Technical debt

Performance improvements

Features

Bugfixes

Documentation

Breaking changes

AutoFilter

Formulas

Functions

Dependencies

Fixes

Pivot tables

New Contributors

Full Changelog: https://github.com/ClosedXML/ClosedXML/compare/0.104.0-preview2...0.104.0-rc1

Source: README.md, updated 2024-09-30