Archived Forum Post

Index of archived forum posts


ZipEntry missing in zip file after using ReplaceData

Nov 26 '13 at 14:36

The method ZipEntry.ReplaceString(data) returns true but if the method Zip.WriteToMemory is called, the ZipEntry is missing (Version 9.4.1). In the Version 9.4.0 this method still worked.

The LastErrorText does not show any error.

Here shortened what we do.

// Get the document byte[] data = Document.GetDocumentManager().GetDocument(_DCH.DocumentInfo);


ZipEntry zc = Zip.GetEntryByName("content.xml");
ZipEntry zs = Zip.GetEntryByName("styles.xml");

string content = FileEncoder.GetEncoder().GetString(zc.Inflate());
string style = FileEncoder.GetEncoder().GetString(zs.Inflate());

// do some string processing with content and replace the result with the original content.


// return the zip

return Zip.WriteToMemory();

After retrieving the Zip and opening the Zip-Content the content.xml and style.xml are missing.


I believe this has already been fixed. Please let me know the .NET Framework version you are using and I'll provide a URL w/ the pre-release download.


We are using the .NET Version


Here are new builds:




Thanks for your fast fix, but strange enough we have now an other problem with the Zip component.

What we are doing:


byte[] data = Retrieve a 'Open-Office.odt' file.

Zip zip = new Zip();


return zip.WriteToMemory();


Using the Chilkat Version 9.4.0 the document can be opened by the 'Open-Office 3.2' application. Using the Chilkat Version (preRelease) the document cannot be opened and the Open Office application tells me that the document is invalid (broken) and has to be fixed. And of course the LastErrorText does not show any error.

Loading the data directly (without the Zip component) into 'Open-Office' works as expected.

The problem we have is, that we are using Chilkat with IMap, too. Here we need a fix done in the 9.4.1 version.

Any hints?


We are manipulating Open-Office documents templates (e. g. creating personalized news letter, contracts).
In order to retrieve the effects following steps can be made:

  1. Load the document into a byte array:

            FileStream fs = new FileStream(File, FileMode.Open, FileAccess.Read, FileShare.Read);
            int length = (int)fs.Length;
            byte[] buffer = new byte[length];
            fs.Read(buffer, 0, length);
  2. Create a new Zip object and call the 'OpenFromMemory' method.

            Zip zip = new Zip();
  3. Write directly into another byte array:

            byte[] result = zip.WriteToMemory();
  4. Now we retrieve this content by download using an application/octet stream.

  5. Save the document and open it with the 'Open-Office' application.

  6. With the version 9.4.0 everything is ok. With the version 9.4.1 prerelease 'Open-Office' throws an error indicating the document is broken and needs to be fixed.

Comparing the hex values of the both documents we can see slight differences between the documents (it seems in the internal file structure. The files itself seem to be ok. The method 'OpenFromMemory' returns true. The LastErrorText of the WriteToMemory is:
DllDate: Oct 22 2013
UnlockPrefix: *** Username: SV-DEV-03:DefaultAppPool
Architecture: Little Endian; 32-bit
Language: .NET 2.0
VerboseLogging: 0
oemCodePage: 850
encryption: 0
passwordProtected: 0
totalSize64: 26131
numCentralDirRecords: 17


The problem was due to the use of data descriptors in the zip format. When Chilkat re-writes, it automatically removes the data descriptors and write a friendlier zip. It didn't do this quite correctly. I found and fixed the problem, and I'll post a new build URL when it's ready.


Please try these new build:




This makes me worried that the behavior also affects .docx documents. I wrote a while ago about a similar ReplaceString issue. Though it was solved any appeared to be working, I am wondering if that is only because Microsoft Word ignores minor structural errors ?!?

Can you confirm this and if it relates only to the WriteToMemory() method or also WriteZipAndClose() ?


I see a similar problem in : a call to ReplaceData causes the FileName property of the Entry to go blank.

Before I test the new pre-release version from the download link above, could you explain why the dll file name is changed from ChilkatDotNet4.dll to ChilkatDotNet2.dll ?



Please ignore. Re-assigning the FileName property immediately after the ReplaceData() call seems to fix the issue.