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
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 220.127.116.11.
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();
Using the Chilkat Version 9.4.0 the document can be opened by the 'Open-Office 3.2' application. Using the Chilkat Version 18.104.22.168 (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.
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:
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);
Create a new Zip object and call the 'OpenFromMemory' method.
Zip zip = new Zip(); zip.OpenFromMemory(buffer);
Write directly into another byte array:
byte result = zip.WriteToMemory();
Now we retrieve this content by download using an application/octet stream.
Save the document and open it with the 'Open-Office' application.
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
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 22.214.171.124 : 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.