EPPlusSoftware
Standardize or remove line endings between XML/VML markup for all package parts
Is your feature request related to a problem? Please describe.
We are using EPPlus in an application to generate Excel reports programatically. We would also like to write automated tests for each of our reports that confirm the output Excel workbook matches EXACTLY an expected state. We are trying this by calculating a hash of each ZIP entry in the XLSX file.
Most all XML parts appear to be written with no line breaks between markup elements, however some VML and XML parts are being written with environment-specific line endings:
- xl/drawings/vmlDrawing*.vml
- xl/tables/table*.xml
This results in differences of the package contents generated between Windows (developer workstations) and Linux (build machines), which prevents these tests from being viable.
Describe the solution you'd like
I propose that all VML/XML parts in the package be either:
- written without line endings between markup elements (making it consistent with the existing behavior on other parts), OR
- force all parts to be written with a specific valid line ending (
\nor\r\n) across all OS platforms
Additional context
n/a
We can look at removing the formatting of the table*.xml files, as it's not necessary. When it comes to vml, I'm not sure as Excel seems to save the *.vml files formatted, but we can look into that. When it comes to line endings, I assume this is different behaviour in .NET for different operating systems when using the XML DOM and the XML streams. There is no difference in the code base for different environments in this case.
When it comes to line endings, I assume this is different behaviour in .NET for different operating systems when using the XML DOM and the XML streams. There is no difference in the code base for different environments in this case.
Looking at the EPPlus source code, it may be a result of where XmlDocument.Save is used to write part XML into the package. With the code cloned to my machine, I tried swapping this out in the VML drawing save code to use XmlWriter instead, of which you can more readily control the line endings. I suspect whatever the .NET runtime XmlDocument.Save does under the hood is selecting the line ending based on environment.
That might be a good place to start. If you are taking PRs, I could try working this out if you like.
We accept smaller simple PRs. For more details see our contributing guidelines : https://github.com/EPPlusSoftware/EPPlus/blob/develop7/CONTRIBUTING.md
No problem, this might be larger than that 'smaller simple' threshold, so I'll look forward to see if you are able to address a fix :)