2015-07-14 14 views
5

Tutto funziona correttamente in modalità di debug ma quando viene eseguito in rilascio la chiamata ExtractToDirectory non riesce.Xamarin Android: System.IO.Compression.ZipFile.ExtractToDirectory Errore in modalità di rilascio

Ecco la funzione di riferimento. Solo per essere sicuro che non stiamo facendo nulla di strano.

private bool UnzipFiles() 
    { 
     bool toReturn = true; 
     try 
     { 
      UpdateStatus("Almost done..."); 
      string file = Path.Combine (DownloadFolder, "ZipFile.zip"); 
      if(System.IO.Directory.Exists(UnzippingDestinationFolder)) 
      { 
       System.IO.Directory.Delete(UnzippingDestinationFolder, recursive:true); 
      } 

      System.IO.Compression.ZipFile.ExtractToDirectory(file, UnzippingDestinationFolder); 
      UpdateStatus("Finished!"); 
      var files = System.IO.Directory.GetFiles(UnzippingDestinationFolder); 

      int m = 3; 

     } 
     catch (Exception e) 
     { 
      toReturn = false; 
     } 

Infine, ecco l'eccezione che otteniamo.

System.NullReferenceException: Object reference not set to an instance of an object 
    at SharpCompress.Common.Zip.Headers.ZipFileEntry.DecodeString (System.Byte[] str) [0x00000] in <filename unknown>:0 
    at SharpCompress.Common.Zip.Headers.DirectoryEntryHeader.Read (System.IO.BinaryReader reader) [0x00000] in <filename unknown>:0 
    at SharpCompress.Common.Zip.ZipHeaderFactory.ReadHeader (UInt32 headerBytes, System.IO.BinaryReader reader) [0x00000] in <filename unknown>:0 
    at SharpCompress.Common.Zip.SeekableZipHeaderFactory+<ReadSeekableHeader>c__Iterator0.MoveNext() [0x00000] in <filename unknown>:0 
    at SharpCompress.Archive.Zip.ZipArchive+<LoadEntries>c__Iterator0.MoveNext() [0x00000] in <filename unknown>:0 
    at SharpCompress.LazyReadOnlyCollection`1+LazyLoader[SharpCompress.Archive.Zip.ZipArchiveEntry].MoveNext() [0x00000] in <filename unknown>:0 
    at System.IO.Compression.ZipArchive.CreateZip (System.IO.Stream stream, ZipArchiveMode mode) [0x00000] in <filename unknown>:0 
    at System.IO.Compression.ZipArchive..ctor (System.IO.Stream stream, ZipArchiveMode mode, Boolean leaveOpen, System.Text.Encoding entryNameEncoding) [0x00000] in <filename unknown>:0 
    at System.IO.Compression.ZipFile.Open (System.String archiveFileName, ZipArchiveMode mode, System.Text.Encoding entryNameEncoding) [0x00000] in <filename unknown>:0 
    at System.IO.Compression.ZipFile.ExtractToDirectory (System.String sourceArchiveFileName, System.String destinationDirectoryName, System.Text.Encoding entryNameEncoding) [0x00000] in <filename unknown>:0 
    at System.IO.Compression.ZipFile.ExtractToDirectory (System.String sourceArchiveFileName, System.String destinationDirectoryName) [0x00000] in <filename unknown>:0 
    at NewBaron.Screens.DownloadContentScreen.UnzipFiles() [0x00000] in <filename unknown>:0 
+1

Un paio di cose da provare: - Quella biblioteca è open source, mettere il codice sorgente nel progetto e il debug di esso. Il riferimento null sarà abbastanza ovvio quando si verifica. - Include tutti i set di caratteri nell'apk. [Opzioni progetto] -> Build Android -> Linker -> Internazionalizzazione. – matthewrdev

+2

Inoltre, disabilitare il linker in modalità Release. – matthewrdev

risposta

1

Il suggerimento di @ mattewrobbinsdev era esattamente quello. Per i lettori futuri, ecco la finestra di dialogo in Xamarin Studio:

Dialog

+0

Sarebbe utile determinare * perché * questo lo risolve ... La mia ipotesi migliore è che il linker stia eliminando un'API che SharpCompress utilizza tramite la reflection. Se si desidera risolvere questo problema senza disabilitare il linker, identificare la classe che viene rimossa e fare un uso di stub di esso. Lo standard è di creare un file 'LinkerPleaseInclude.cs': https://github.com/MvvmCross/MvvmCross/blob/v3/nuspec/DroidContent/LinkerPleaseInclude.cs.pp – matthewrdev

+0

Il comportamento del collegamento dell'opzione: non collegare, worket per me. Il System.IO.Compression si bloccava durante la decompressione di un file in modalità RELEASE. Il problema è che il file .APK duplica la sua dimensione. Nel mio caso il .APK era 25mb e dopo il collegamento non era di 50bm. – jzeferino

+0

Qualcuno ha mai registrato un bug nel bugzilla di Xamarin? – dotMorten

4

A lievi modifiche alla soluzione di Victor. Il mancato collegamento degli SDK ha generato un apk di 53 MB. Troppo grande per il limite di dimensioni degli apk del play store.

ho impostato il comportamento che collega a collegare solo assemblee SDK e ha proposto il formato apk verso il basso per 29MBs

Ecco la finestra aggiornata.

enter image description here

+1

Risposta molto migliore. Anche questa soluzione ha contribuito a risolvere lo stesso problema su un'app Xamarin.Mac. –

+0

Questo ha risolto il mio problema, mantenendo il file .apk piccolo a causa solo degli assembly SDK. – jzeferino

Problemi correlati