This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 33553 - System.IO.Compression.ZipArchive produces bad archive files
Summary: System.IO.Compression.ZipArchive produces bad archive files
Status: RESOLVED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries (show other bugs)
Version: 5.1
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: João Matos
URL:
: 38295 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-09-01 15:19 UTC by David Schulte
Modified: 2016-02-23 13:26 UTC (History)
6 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test project demonstrating the issues noted in the Description section (49.12 KB, application/zip)
2015-09-01 15:19 UTC, David Schulte
Details
Xamarin version info (1.30 KB, text/plain)
2015-09-01 15:19 UTC, David Schulte
Details
Xamarin Alpha build details installed on 20150901 (1.47 KB, text/plain)
2015-09-01 21:43 UTC, David Schulte
Details
Updated test project demonstrating the problem reported by this posting. (45.94 KB, application/zip)
2015-09-04 09:28 UTC, David Schulte
Details
Visual Studio 2015 project for testing results of Native Windows ZipArchive support (21.41 KB, application/zip)
2015-09-04 15:15 UTC, David Schulte
Details
Xamarin Android generated zip file (212 bytes, application/zip)
2015-09-04 15:22 UTC, David Schulte
Details
Windows generated zip file (212 bytes, application/zip)
2015-09-04 15:23 UTC, David Schulte
Details
ZipStorer generated zip file. (208 bytes, application/zip)
2015-09-04 15:26 UTC, David Schulte
Details
A sample spreadsheet app built using Microsoft's Open XML SDK and Xamarin's one-off System.IO.Compression.dll (3.46 MB, application/zip)
2015-09-04 18:43 UTC, David Schulte
Details
Sample spreadsheet app built using a modified version of Microsoft's Open XML SDK which uses TSZipArchive and ZipStorer to construct the .xlsx file (3.47 MB, application/zip)
2015-09-04 18:49 UTC, David Schulte
Details

Description David Schulte 2015-09-01 15:19:04 UTC
Created attachment 12706 [details]
Test project demonstrating the issues noted in the Description section

While trying to use Microsoft's Open XML SDK 2.6 from github (https://github.com/OfficeDev/Open-XML-SDK), I've found that Xamarin's ZipArchive implementation is producing bad archive files (or files with a really old zip format). .xlsx files generated using Open XML SDK could not be opened by Excel 2010. I replaced the ZipArchive and ZipArchiveEntry class references in this open source copy of the SDK with my own implementations of these classes which implement the same API as ZipArchive and ZipArchiveEntry but use ZipStorer (https://zipstorer.codeplex.com/), and I can then successfully open the .xlsx files generated by the SDK.

The attached test application creates two zip files: /sdcard/z1.zip and /sdcard/z2.zip. z1.zip is created using Xamarin's ZipArchive implementation and z2.zip is create using my ZipArchive replacement. If you copy the two files to a UNIX host and invoke file on them, z1.zip shows up as a data file, not an archive file, which I believe is due to the fact that the magic info at the start of the file is wrong. Example:

$ file z1.zip z2.zip
z1.zip: data
z2.zip: Zip archive data, at least v2.0 to extract

Is there anyway we can get a more current version of ZipArchive added to Xamarin? Also attached are the details regarding my version of Xamarin Android.
Thanks in advance,
Dave
Comment 1 David Schulte 2015-09-01 15:19:37 UTC
Created attachment 12707 [details]
Xamarin version info
Comment 2 Jonathan Pryor 2015-09-01 16:17:19 UTC
This appears to be fixed for Cycle 6. Please try the Alpha.
Comment 3 David Schulte 2015-09-01 20:58:27 UTC
Sorry Jonathan. I tried using the alpha version with our app and ran into the following assertion error:

[Mono] [0x7fd35d70] worker starting
[Mono] [0x7fd2a010] hill climbing, change max number of threads 4
[] * Assertion at /Users/builder/data/lanes/1196/e5042d7c/source/mono/mono/mini/debugger-agent.c:2598, condition `res' not met
[libc] Fatal signal 6 (SIGABRT) at 0x00006b7f (code=-6), thread 27544 (CTSSmartWaitCur)

Could you have someone fix this and I'll try this again? Our app runs fine on the stable version.
Thanks,
Dave
Comment 4 David Schulte 2015-09-01 21:42:26 UTC
Johathan, the app I was referring to in my last posting was our normal application which exhibited the assertion error, not the test application that I posted to this ticket.

I recompiled the test application attached to this ticket, ran it, and I see the same results as I saw with the stable build, z1.zip, which is built using Xamarin's ZipArchive support shows up as a "data" file, not a zip file.

Please let me know if there is anything more that you want me to try.
Thanks,
Dave

p.s. I attached the details about the Alpha build that I installed tonight.
Comment 5 David Schulte 2015-09-01 21:43:08 UTC
Created attachment 12712 [details]
Xamarin Alpha build details installed on 20150901
Comment 6 David Schulte 2015-09-02 06:18:48 UTC
Jonathan, the crash that I noted earlier only occurs if I run the Debug version of the app via Xamarin Studio. If I invoke the Debug version directly on the device, the crash does not occur. Just some more info in case this helps.
Comment 7 David Schulte 2015-09-02 06:33:08 UTC
Here is another crash while running the Debug version of a different test app from Xamarin Studio.
Dave

[mono] Unable to find seq points for method '(wrapper managed-to-native) System.Diagnostics.Debugger:Mono_UnhandledException_internal (System.Exception)'.
[] * Assertion at /Users/builder/data/lanes/1196/e5042d7c/source/mono/mono/mini/debugger-agent.c:5413, condition `sp' not met
[libc] Fatal signal 6 (SIGABRT) at 0x00004d3a (code=-6), thread 19788 (spreadsheettest)
Step request failed: Exception of type 'Mono.Debugger.Soft.VMDisconnectedException' was thrown.
Comment 8 David Schulte 2015-09-04 06:53:53 UTC
Jonathan, is there any update on this issue?
Thanks,
Dave
Comment 9 David Schulte 2015-09-04 09:28:12 UTC
Created attachment 12752 [details]
Updated test project demonstrating the problem reported by this posting.

This version includes a new version of my TSZipArchive class, which is a replacement for Xamarin's ZipArchive implementation and is built on top of the ZipStorer class.
Comment 10 João Matos 2015-09-04 11:04:38 UTC
Just tried reproducing this bug with Mono master.

https://gist.github.com/tritao/3d66bf98e3e856d1a7d1

Unix file is reporting the created file as a Zip archive:

ubuntu-trusty-64:/vagrant$ file z1.zip
z1.zip: Zip archive data

Could you try reproducing on desktop Mono or giving me another way to reproduce it?
Comment 11 David Schulte 2015-09-04 11:44:51 UTC
I have no idea what "Mono master" is. Can you please build my test app using the version of Xamarin Android posted in my original "Xamarin Version Info" attachement?

The app built using this version will cause the problem to occur. I was running file(1) on a MacBook Pro.
Comment 12 João Matos 2015-09-04 11:52:29 UTC
Mono master is the latest development revision of the VM available on Github.

Xamarin.Android releases just bundle a certain revision of the VM, in your case we can see in the info that you posted that it's using Mono 4.2.0 (explicit/a224653).

I don't currently have any Android device nearby to test this, which is why I asked if you could reproduce the problem on the Mac, by running your reduced test case that I posted in my previous message.
Comment 13 David Schulte 2015-09-04 12:19:27 UTC
You should be able to use an Android SDK emulator to test this.

I guess I'm not sure what you are trying to determine. Are you trying to determine if the problem exist at all, even in the version of Xamarin Android that I'm using? Are you trying to determine if the problem exists in the latest build of Xamarin, regardless of if it exists in the version I'm using?

If you are trying to determine the latter, I need access to a copy of the most current build of Xamarin. As per my earlier notes, I tried installing the alpha build and see the same results, along with other bugs.
Comment 14 João Matos 2015-09-04 12:32:00 UTC
Most bugs in the class libraries can be more easily debugged on the desktop. There's usually nothing specific to Android in bugs like these Zip failures (unless it's caused by some ARM-specific code generation bug in the virtual machine, but that's unlikely). 

Which is why I asked if you could reproduce the failure on the desktop by using the standalone Mono VM (invoked by the 'mono' command). Or you can also use Xamarin Studio to do it.
Comment 15 David Schulte 2015-09-04 14:02:45 UTC
I tried building a console app but can't because System.IO.Compression.ZipArchive is not found.

I only have the ability to build iOS and Android apps using my copy of Xamarin.

Can you just try to do exactly what I did? If not and you include more specifics about what you want me to do, or provide a link to the master version of mono, I can try this again.
Dave
Comment 16 Jonathan Pryor 2015-09-04 14:19:41 UTC
> z1.zip, which is built using
> Xamarin's ZipArchive support shows up as a "data" file, not a zip file.

How are you determining file type?

Android File Transfer isn't working with my Android M Preview 3 device, so I can't easily test its behavior.

Android M Preview 3 does have Settings > Storage & USB > Explore, which shows z.zip, z1.zip, and z2.zip, but it does NOT show file types.

My hypothesis is that when using Attachment #12706 [details], z1.zip IS generated, and IS a zip file:

  $ adb pull /sdcard/z1.zip
  $ unzip -l z1.zip
  Archive:  z1.zip
    Length     Date   Time    Name
   --------    ----   ----    ----
          7  09-02-15 16:09   filea
   --------                   -------
          7                   1 file

i.e. it's a perfectly valid .zip file.

Not knowing how you're determining file type, I don't know why it isn't showing up as a ZIP file, but (with Cycle 6 Alpha 1) it *is* created, and *is* a ZIP file.

The assert mentioned in Comment #3 is another matter entirely.
Comment 17 David Schulte 2015-09-04 14:27:34 UTC
I am using file(1) on a MacBook pro, but any Unix/Linux host should produce the same results.

I didn't say that it wasn't producing a zip file. It is, but the file is a really old format and the header details aren't current. If you do invoke something like "od -x z1.zip" and compare the results with "od -x z2.zip" you will see that the headers don't match.

I'm trying to create .xlsx (Microsoft Open XML) files using Microsoft's Open XML SDK, and files produced using Xamarin's native System.IO.Compression.ZipArchive support won't open using Android Excel or using Microsoft's Open XML Productivity tool because the zip file, probably the magic info at the  top of the file, isn't correct or current.

The files produced by ZipStorer can be opened by Android Excel and Microsoft's Open XML Productivity tool.

Compare the headers of the z1.zip and z2.zip files produced by my test app to see the differences.
Comment 18 David Schulte 2015-09-04 14:29:21 UTC
The "od" command that I'm referring to is Unix's "octal dump" utility (od(1)), and the -x option will produce hex output.
Comment 19 David Schulte 2015-09-04 14:48:45 UTC
Here's some sample od -x output. z1.zip is the file created using Xamarin's native System.IO.Compression.ZipArchive support and z2.zip is the file created using the ZipStore class and my TSZipArchive interface class. Note that the magic details on the first line are different and also that, while the content is similar, the file sizes differ.

$ od -x z1.zip > z1.txt
$ od -x z2.zip > z2.txt
$ diff z1.txt z2.txt
1,15c1,14
< 0000000      4b50    0403    003f    0800    0008    707b    4724    f7a8
< 0000020      9ffe    0009    0000    0007    0000    0005    0000    6966
< 0000040      656c    4b61    4a4c    a856    aca8    0002    4b50    0403
< 0000060      003f    0800    0008    707b    4724    f7a8    9ffe    0009
< 0000100      0000    0007    0000    0005    0000    6966    656c    4b62
< 0000120      4a4c    a856    aca8    0002    4b50    0201    003f    000a
< 0000140      0800    0008    707b    4724    f7a8    9ffe    0009    0000
< 0000160      0007    0000    0005    0000    0000    0000    0000    0000
< 0000200      8100    0000    0000    6966    656c    5061    014b    3f02
< 0000220      0a00    0000    0808    7b00    2470    a847    fef7    099f
< 0000240      0000    0700    0000    0500    0000    0000    0000    0000
< 0000260      0000    0000    2c81    0000    6600    6c69    6265    4b50
< 0000300      0605    0000    0000    0002    0002    0066    0000    0058
< 0000320      0000    0000                                                
< 0000324
---
> 0000000      4b50    0403    0014    0000    0000    707b    4724    f7a8
> 0000020      9ffe    0007    0000    0007    0000    0005    0000    6966
> 0000040      656c    6161    6362    7820    7a79    4b50    0403    0014
> 0000060      0000    0000    707b    4724    f7a8    9ffe    0007    0000
> 0000100      0007    0000    0005    0000    6966    656c    6162    6362
> 0000120      7820    7a79    4b50    0201    0b17    0014    0000    0000
> 0000140      707b    4724    f7a8    9ffe    0007    0000    0007    0000
> 0000160      0005    0000    0000    0000    0000    0000    8100    0000
> 0000200      0000    6966    656c    5061    014b    1702    140b    0000
> 0000220      0000    7b00    2470    a847    fef7    079f    0000    0700
> 0000240      0000    0500    0000    0000    0000    0000    0000    0000
> 0000260      2a81    0000    6600    6c69    6265    4b50    0605    0000
> 0000300      0000    0002    0002    0066    0000    0054    0000    0000
> 0000320
Comment 20 João Matos 2015-09-04 15:09:11 UTC
Can you attach both zip files to the bug? I'll do some research to see why we're seeing these differences.
Comment 21 David Schulte 2015-09-04 15:15:38 UTC
Created attachment 12759 [details]
Visual Studio 2015 project for testing results of Native Windows ZipArchive support
Comment 22 David Schulte 2015-09-04 15:21:19 UTC
Sure ... give me a minute...

As another example, I just attached a Visual Studio 2015 project that includes the same source as the Xamarin project that I attached and it is producing valid zip files. z1.zip and z2.zip both appear as follows when using the file(1) command:

$ file z1.zip z2.zip
z1.zip: Zip archive data, at least v2.0 to extract
z2.zip: Zip archive data, at least v2.0 to extract

The content of the two zip files does differ though.

If I compare the z1.zip results generated by Xamarin vs. that generated by the windows console app that I just created, I see the following, which may be more useful. I'll attach copies of the Xamarin generated zip file v.s. the Windows version for your comparison. This may be more meaningful. I'll also attach the ZipStore version for reference.
Dave

Here's comparing the Xamarin generated zip file against the Windows version:
$ diff Xamarin_z1.txt Windows_z1.txt
1c1
< 0000000      4b50    0403    0014    0800    0008    7909    4724    f7a8
---
> 0000000      4b50    0403    0014    0800    0008    7949    4724    f7a8
4c4
< 0000060      0014    0800    0008    7909    4724    f7a8    9ffe    0009
---
> 0000060      0014    0800    0008    7949    4724    f7a8    9ffe    0009
7c7
< 0000140      0800    0008    7909    4724    f7a8    9ffe    0009    0000
---
> 0000140      0800    0008    7949    4724    f7a8    9ffe    0009    0000
10c10
< 0000220      1400    0000    0808    0900    2479    a847    fef7    099f
---
> 0000220      1400    0000    0808    4900    2479    a847    fef7    099f
$
Comment 23 Jonathan Pryor 2015-09-04 15:22:13 UTC
@joao:

> Most bugs in the class libraries can be more easily debugged on the desktop.

Indeed, and that's true here as well. Consider this app:

  using System;
  using System.IO.Compression;
  using System.IO;
  
  class App {
    public static void Main ()
    {
      using (FileStream zipStream = new FileStream("z1.zip", FileMode.Create))
      using (ZipArchive zipArchive = new ZipArchive(zipStream,
          ZipArchiveMode.Create, true, System.Text.Encoding.UTF8))
      {
        ZipArchiveEntry zipEntry = zipArchive.CreateEntry("filea");
        Stream zipEntryStream = zipEntry.Open();
        byte[] chars = System.Text.Encoding.UTF8.GetBytes("abc xyz");
        zipEntryStream.Write(chars, 0, chars.Length);
        zipEntryStream.Close();
      }      
    }
  }

Run, the use `file(1)` on the output:

  $ mono --version
Mono JIT compiler version 4.0.4 ((detached/5ab4c0d Tue Aug 25 08:35:07 EDT 2015)
  $ mcs z.cs
  $ mono z.exe
  $ file z1.zip
  z1.zip: data

The same is true with Mono 4.2.0: the generated .zip file is declared "data" by file(1).

Furthermore, `hexdump -C` is where it's at. ;-)

If we compare .NET-generated z1.zip (z1-net.zip) to mono 4.2.0-generated z1.zip (z1-m42.zip)

  $ hexump -C z1-net.zip > z1-net.zip.C
  $ hexump -C z1-m42.zip > z1-m42.zip.C
  $ diff -u z1-net.zip.C z1-m42.zip.C
> --- z1-net.zip.C	2015-09-04 14:45:33.000000000 -0400
> +++ z1-m42.zip.C	2015-09-04 14:49:40.000000000 -0400
> @@ -1,9 +1,9 @@
> -00000000  50 4b 03 04 14 00 00 08  08 00 89 75 24 47 a8 f7  |PK.........u$G..|
> +00000000  50 4b 03 04 3f 00 00 08  08 00 2c 76 24 47 a8 f7  |PK..?.....,v$G..|
>  00000010  fe 9f 09 00 00 00 07 00  00 00 05 00 00 00 66 69  |..............fi|
>  00000020  6c 65 61 4b 4c 4a 56 a8  a8 ac 02 00 50 4b 01 02  |leaKLJV.....PK..|
> -00000030  14 00 14 00 00 08 08 00  89 75 24 47 a8 f7 fe 9f  |.........u$G....|
> +00000030  3f 00 0a 00 00 08 08 00  2c 76 24 47 a8 f7 fe 9f  |?.......,v$G....|
>  00000040  09 00 00 00 07 00 00 00  05 00 00 00 00 00 00 00  |................|
> -00000050  00 00 00 00 00 00 00 00  00 00 66 69 6c 65 61 50  |..........fileaP|
> +00000050  00 00 00 00 00 81 00 00  00 00 66 69 6c 65 61 50  |..........fileaP|
>  00000060  4b 05 06 00 00 00 00 01  00 01 00 33 00 00 00 2c  |K..........3...,|
>  00000070  00 00 00 00 00                                    |.....|
>  00000075

We see that the ZIP "Version needed to extract (minimum)" field in the header differs, with .NET requiring 0x14 0x00 (20, presumably PKZip 2.0) while mono 4.2 requires 0x3f 0x00 (63, presumably PKZip 6.3).

The version appears to be the problem. If I use Hex Fiend to change the mono-generated file to have a version of 0x14 0x00 instead of 0x3f 0x00, file(1) correctly detects the file type.

I thus must conclude that Mono is inserting the wrong version number.
Comment 24 David Schulte 2015-09-04 15:22:25 UTC
Created attachment 12760 [details]
Xamarin Android generated zip file
Comment 25 David Schulte 2015-09-04 15:23:02 UTC
Created attachment 12761 [details]
Windows generated zip file
Comment 26 David Schulte 2015-09-04 15:26:16 UTC
Created attachment 12762 [details]
ZipStorer generated zip file.

This file is probably not as useful as the Windows and Xamarin generated files.
Comment 27 David Schulte 2015-09-04 15:28:49 UTC
Jonathan, if you can get someone to correct the version info being written, I can test my Microsoft Open XML SDK integration again and see if things are any better.
Thanks again,
Dave
Comment 28 David Schulte 2015-09-04 15:34:25 UTC
Jonathan, as per my comparison of the Windows vs. Xamarin results, there may be other subtle differences, but let's start with getting the correct version information being written and I'll try this out.
Comment 29 João Matos 2015-09-04 15:36:21 UTC
@jonp That narrows it down.

So the Zip version is being written here:

            OutputStream.Write(new byte[] {63, 0}, 0, 2); //version

https://github.com/mono/mono/blob/5129dd43cface699573ac21ab60d91ed5688e858/mcs/class/System.IO.Compression/SharpCompress/Writer/Zip/ZipWriter.cs#L145

It's hardcoded by SharpCompress. We can change it to the older version. I guess they use the newer format for features like encryption. I don't think .NET supports that though so it should be safe.
Comment 30 João Matos 2015-09-04 15:53:33 UTC
@David

I linked a fixed System.IO.Compression.dll, could you check if the fix works for you?

https://dl.dropboxusercontent.com/u/194502/dev/System.IO.Compression.zip
Comment 31 David Schulte 2015-09-04 17:35:26 UTC
I sure can. I'll try this later tonight.
Dave
Comment 32 David Schulte 2015-09-04 18:39:49 UTC
There is still something subtly wrong/different about the zip file format being created by ZipArchive. Microsoft Excel for Android cannot open Open XML spreadsheets (.xlsx files) creating using this version of ZipArchive, and Windows Excel reports that the file contains unreadable content, although file(1) now reports the same value as that produced by ZipStore and the native Windows support.

Also, the problem documented under https://bugzilla.xamarin.com/show_bug.cgi?id=32725 still exists.

The SDK attempts to open the zip file for update and we end up with the crash noted below. I made a small change to the SDK to get this to work for our needs, but it would be nice if the Xamarin support could be fixed. I believe all that is needed is to test the size of the file or stream being opened with ZipArchive and only attempt to read the archive's director if the size of the file or stream is not 0.

[MonoDroid] UNHANDLED EXCEPTION:
[MonoDroid] SharpCompress.Common.ArchiveException: Failed to locate the Zip Header
[MonoDroid]   at SharpCompress.Common.Zip.SeekableZipHeaderFactory+<ReadSeekableHeader>c__Iterator0.MoveNext () [0x0005d] in /Users/builder/data/lanes/1978/f98871a9/source/mono/mcs/class/System.IO.Compression/SharpCompress/Common/Zip/SeekableZipHeaderFactory.cs:29 
[MonoDroid]   at SharpCompress.Archive.Zip.ZipArchive+<LoadEntries>c__Iterator0.MoveNext () [0x0013c] in /Users/builder/data/lanes/1978/f98871a9/source/mono/mcs/class/System.IO.Compression/SharpCompress/Archive/Zip/ZipArchive.cs:203 
[MonoDroid]   at SharpCompress.LazyReadOnlyCollection`1+LazyLoader[SharpCompress.Archive.Zip.ZipArchiveEntry].MoveNext () [0x0002d] in /Users/builder/data/lanes/1978/f98871a9/source/mono/mcs/class/System.IO.Compression/SharpCompress/LazyReadOnlyCollection.cs:63 
[MonoDroid]   at System.IO.Compression.ZipArchive.CreateZip (System.IO.Stream stream, ZipArchiveMode mode) [0x000f6] in /Users/builder/data/lanes/1978/f98871a9/source/mono/mcs/class/System.IO.Compression/ZipArchive.cs:117 
[MonoDroid]   at System.IO.Compression.ZipArchive..ctor (System.IO.Stream stream, ZipArchiveMode mode, Boolean leaveOpen, System.Text.Encoding entryNameEncoding) [0x00034] in /Users/builder/data/lanes/1978/f98871a9/source/mono/mcs/class/System.IO.Compression/ZipArchive.cs:85 
[MonoDroid]   at System.IO.Packaging.ZipPackage..ctor (System.IO.Stream s, FileMode packageFileMode, FileAccess packageFileAccess) [0x0004a] in /Users/dschulte/Downloads/OpenXML/Open-XML-SDK-vNext/Open-XML-SDK-vNext/System.IO.Packaging/ZipPackage.cs:362 
[AndroidRuntime] Shutting down VM

I've attached a sample spreadsheet app that demonstrates the issue that still remains with the zip file format. It creates a file called /sdcard/z.xlsx. The attached project uses my modified version of the Microsoft Open XML SDK that has the fix for the open/create issue noted above as a work-around, but otherwise, uses the ZipArchive support from the dll that you gave me, NOT the version of the SDK that includes the use of my TSZipArchive class.

If I use a copy of the SDK that is built using my TSZipArchive class, which uses ZipStorer as its means for generating the .xlsx file, I can successfully open the results in Excel. Therefore, there must still be something incompatible about the zip format being generated by Xamarin's libraries other than just the version information in the header.

Open XLSX files are expected to be zipped using the Deflate algorithm, if this helps.
Please let me know if there is anything else that you would like me to try.
As a reminder, this an extended weekend for us here in the US and I may not get back to you until Tuesday of next week.
Thanks again for working with me on this problem!!
Dave
Comment 33 David Schulte 2015-09-04 18:43:56 UTC
Created attachment 12788 [details]
A sample spreadsheet app built using Microsoft's Open XML SDK and Xamarin's one-off System.IO.Compression.dll
Comment 34 David Schulte 2015-09-04 18:49:54 UTC
Created attachment 12789 [details]
Sample spreadsheet app built using a modified version of Microsoft's Open XML SDK which uses TSZipArchive and ZipStorer to construct the .xlsx file
Comment 35 David Schulte 2015-09-04 18:54:58 UTC
I just uploaded 2 sample spreadsheet project, one built using your support to generate the .xlsx file and one using my version of the Microsoft Open XML SDK which uses my TSZipArchive class and the ZipStorer class to build the .xlsx file. You can use these to compare the resulting .xlsx files if you wish.

If you want the source for the Microsoft Open XML SDK, you can get the original source from: https://github.com/OfficeDev/Open-XML-SDK.

If you want my 2 modified versions of the SDK source (one with a work-around for the second bug mentioned in Comment #32, and another which uses the TSZipArchive and ZipStorer classes) I can attach them to this ticket. Just let me know.
Thanks,
Dave
Comment 36 João Matos 2015-09-04 19:19:55 UTC
Glad to know that the difference reported by file has been fixed, even if it's enough.

About the other bug, I've fixed it locally and sent a pull request to Mono's Github. It wasn't fixed on the build I sent you because I have it on another branch.

Thanks for the sample projects you attached, those should help me to figure out the rest of the fix.
Comment 37 David Schulte 2015-09-16 10:24:28 UTC
Joao, have you been able to identify the cause of these issues yet?
Thanks,
Dave
Comment 38 João Matos 2015-09-16 11:26:52 UTC
Hey David,

It's on the backlog. I'm working on some higher priority tasks at the moment, once I get some time I'll take a look this.
Comment 39 David Schulte 2015-10-30 13:37:53 UTC
Has there been any update on this issue? I would really like to be able to remove our custom code from the OpenXML package.
Thanks,
Dave
Comment 40 Kerry 2016-01-28 23:09:59 UTC
This also has an impact on FAKE: https://github.com/fsprojects/Paket/issues/1056
Comment 42 David Schulte 2016-02-22 15:05:53 UTC
Joao, do you now what version of Xamarin Studio this is now resolved in so we can do some testing?
Thanks,
Dave
Comment 43 João Matos 2016-02-22 16:30:51 UTC
Since this was just pushed to master, it hasn't landed in any release yet. I've also backported it to the branch for our next release that's in alpha, so you can expect it in the next version that we push.
Comment 44 João Matos 2016-02-22 16:31:42 UTC
And just to clarify, it does not matter which version of XS you have, what will matter if the version of Xamarin.Android and/or Mono.
Comment 45 João Matos 2016-02-22 16:32:51 UTC
*** Bug 38295 has been marked as a duplicate of this bug. ***
Comment 46 RichardW 2016-02-23 13:26:42 UTC
Speaking of System.IO.Compression and the MS Open XML SDK, does anyone have any thoughts about

https://github.com/OfficeDev/Open-XML-SDK/issues/64

?

Seems that the MS version of ZipArchiveEntry.Open (in some cases at least) returns a stream whose length can be queried, whereas the Mono version always throws. Running the XML SDK tests gets a lot of failures due to it relying on being able to query the length (though as the linked issue says, the SDK contains its own workaround to make it work in some cases).

Note You need to log in before you can comment on or make changes to this bug.