Closed aboryczko closed 2 years ago
I guess it's not totaly Excel related because I've exchanged the SharpCompress library for the .NET internal compression implementation and my generated files work correctly.
so there is an error in the compression library that adds some strange bytes in the middle of the content every N bytes. I will go continue this thread there.
@salvois if it would be ok with you I could create a PR that would replace SharpCompress with the built-in .NET Core implementation and bumped it to v2.0. It worked fine for me.
Hi @aboryczko , last time I checked, the built-in compressor in .NET failed to produce a ZIP64 with content larger that 4 GiB considered valid by Excel. It refused to open it altogether. If this is still the case, unfortunately I cannot switch the underlying compression library. Have you tried this too? Thanks, Salvl
Would be nice if you can try out the 0.32.1 release of sharpcompress, that was linked to this issue
Hi @Erior , many thanks for pointing that out and for your help, I will try it next week! Salvo
Hi @aboryczko , @Erior , the issue seems to be solved using SharpCompress 0.32.1. I have just released LargeXlsx 1.5.1 with the updated dependency. Please have a try and let me know. Thanks for your contribution! Salvo
Thanks everyone, I can also confirm that the issue has been resolved :)
Hi,
I've tried to use this library to stream Excel files on the fly via ASP.NET Core. My use case prohibits me with caching it in memory and I end up using the raw HTTP response stream. The file generated seems ok at first, but when I load it with Excel it tries to repair it and without any data loss the file is opened. The only difference between a correct file and the broken one is that the underlying ZIP file has the general purpose bit flag set to (bit 3). I know that this is more of an Excel issue but did anyone have any luck working around that?