One use is for unzip a resource embed into an assembly (.dll). The resource is approximately 224MB in size. The program sometimes throws an out-of-memory exception. The exception is thrown by Chilkat.Zip.OpenFromMemory and OpenFromByteData methods.
How can this problem be solved?
First, this is truly an out-of-memory condition. The two possible solutions are (1) to allow your application to use more memory (not sure if this is possible, but you might look here for information on the topic: https://www.codeproject.com/Articles/483475/Memory-Limits-in-a-NET-Process ) or (2) to use less memory.
The OpenBd method can be used to significantly reduce memory usage. The problem with OpenFromMemory (and OpenFromByteData) is that the contents of the zip are passed in a .NET managed byte array. The data must be marshaled from managed memory to unmanaged, and this causes the full 224MB to exists twice in memory (in managed memory within your .NET application, and in unmanaged memory within the underlying native Chilkat C++ implementation).
A better solution is to use a Chilkat.BinData object to load the contents of the file, and then call zip.OpenBd. This way you’re just passing a handle to the BinData object instead of 224MB. The zip data exists only once in memory.
*** In general, Chilkat is incrementally adding “Bd” and “Sb” methods for those methods in Chilkat classes that can potentially pass large amounts of binary or text data. The “Sb” methods pass a Chilkat.StringBuilder object. The same concept applies: Instead of marshaling a huge string in the method call, the application can pass a StringBuilder object which contains the text.
Using “Bd” and “Sb” methods is better for other programming languages too, especially anything using the ActiveX because strings in ActiveX/COM are passed as BSTR’s (utf-16) and binary byte data is passed in Variants. The overhead of conversion/marshaling can be eliminated by using the Bd and Sb methods.