Add docprops files

[ZeroMD]

Would it be possible to generate the docprops/app.xml and docprops/core.xml files?

See https://docs.fileformat.com/spreadsheet/xlsx/

[sveinungf]

It is not possible in the current version, but I can look into it for a future version.
What kind of information do you need from these files?

[sharpjoe]

I'd like to second this request. We have rolled over to SpreadCheetah (thanks BTW!)
The exports are from an enterprise system and the reason they are important because they are used by various things in Windows and also SharePoint when the documents are added to the tool tips, previews, search results and such and obviously in the "Info" part of Excel's back stage or whatever that is called these days (the File Menu replacement). These are the things we set by default in the old OpenXML exporter and I have seen commonly used.

        document.PackageProperties.Creator = _isSystemExport ? "System Name" : $"System Name;{_userName}";
        document.PackageProperties.Title = _title;
        document.PackageProperties.Modified = DateTime.Now;
        document.PackageProperties.LastModifiedBy = document.PackageProperties.Creator;
        document.PackageProperties.Created = document.PackageProperties.Modified;
        document.PackageProperties.Subject = "System Name Data Extract - " + _title;

If you have thoughts about work around, they would be most welcome.

[sveinungf]

Interesting. Thanks for explaining a use case. It doesn't seem like this should be particularly difficult to add.

In the meantime, a possible workaround could be to add the docProps files yourself to an already created XLSX file. An XLSX file is basically a ZIP file in disguise, so you could add additional files by using the ZipFile class from System.IO.Compression. You will most likely also need to add entries for the files in the [Content_Types].xml file in the root of the archive. I haven't tried this myself though, so I can't guarantee that this will work.

[sharpjoe]

You are correct, there are entries in the content type XML file required and I think that would be possible. I started down that path and then decided to try an experiment and the easier work around is to Generate the file with SpreadCheetah without the props, open it with OpenXML and then add the doc props and save it.

Some details about the net result (this may not be the right place but...)

One use case that was crashing our server with the ported OpenXml implementation from Framework took 115s to run but leaked 14.4GB of RAM, and the GC was going nuts during the process (running every 2 or 3 seconds during the process). It spits out a xlsx file that is about 61MB.

The reimplemented version that generates the sheet with SpreadCheetah and then adds the properties as above takes 17s (2s to add the props), the GC doesn't trigger during the process at all, and there is no perceptible memory growth at all, and the resulting spreadsheet (with the compression option on) is roughly half the size but the content is identical according to both automated and manual comparison. So OpenXML can update the doc without hitting the issue in System.IO.Packaging.

Oh and the exporter that takes our report spec and data enumerator and spits out the file is 600 lines of code instead of 1700 and WAY more readable and maintainable.

All in all an excellent improvement, easily implemented, and much more concurrency friendly in a busy server environment.
Thank you!

[sveinungf]

Doing it with the OpenXML SDK is probably an easier workaround, good point.

Great to hear you're seeing such improvements 🙂