Home Forums .NET libraries Xceed Zip & Real-Time Zip for .NET Zipping is not synchronous?

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • User (Old forums)
    Post count: 23064
    #20242 |


    I do a loop and I zip a file at each iteration.

    When the loop ends, the zipping is not finished (I see the zips are still coming in the working directory).

    Is the zipping asynchronous? is it possible to make it synchronous?

    I use the following code to zip : diskFolder.CopyFilesTo(archief,

    true, true);

    Thanks for your help

    Imported from legacy forums. Posted by Jean Christophe (had 1842 views)

    Xceed Support
    Post count: 5658

    Hi Jean Christophe,

    Xceed Zip for .Net does not support Asynchronous Processing.

    Xceed Zip Compression Library do support Asynchronous Processing; this feature can be enabled/disabled by setting the Zip Object’s property “BackgroundProcessing” to “True/False” :

     objZip.BackgroundProcessing = True;



    Technical Support


    Imported from legacy forums. Posted by Alain [Xceed] (had 799 views)

    User (Old forums)
    Post count: 23064


    Hi. I was googling for what may be a similar problem, and this exchange from a year and half ago came up. I have “inherited” a bit of code that we are converting to Exceed, and I get an exception on the call to CopyToFiles:

    A first chance exception of type ‘Xceed.FileSystem.FileSystemIOException’ occurred in Xceed.FileSystem.dll 

    Additional information: The file item could not be opened for reading.


    The file exists, has good permissions, etc. The only unusual thing is that (for some reason) the caller of my routine has a workflow that calls for the compression twice. The first CopyToFiles is successful, the second call results in the exception described above. I am wondering if i might be victim of the asynchronous  bug described previously.


    My code looks like this:


    CCompressHelper::CompressFileEx(BSTR inputFile, BSTR zipFile,

     // following call generates exception the second time through:
      diskFolder->CopyFilesTo(%oZipArchive, false
    ,false,oDiskFile.Name );
      return S_OK;
    } // CCompressHelper::CompressFileEx()

    Now, there is no BackgroundProcessing property available on oZipArchive. So perhaps there is some other factor at work. Btw, I have also tried with the replaceExistingFiles argument set to true, with no change in behavior.

    I would very much appreciate any insight or suggestion on this problem.


    Chuck Puckett
    Software Scientist, Intergraph Corporation, Huntsville, AL

    Imported from legacy forums. Posted by Chuck (had 159 views)

    User (Old forums)
    Post count: 23064

    For some reason, the forum s/w truncated my code snippet. I repeat it here:


    BSTR inputFile,

    BSTR zipFile,

    long compressRate)


    Xceed::Compression::CompressionLevel compressionLevel = ConvertCompressRateToXCeedCompressionLevel(compressRate);

    System::String ^sZipFile = msclr::interop::marshal_as<System::String^>(zipFile);

    System::String ^sInputFile = msclr::interop::marshal_as<System::String^>(inputFile);

    //Remove Quotes.

    sInputFile = sInputFile->Replace(


    Xceed::FileSystem::DiskFile oDiskFile(sInputFile);

    Xceed::FileSystem::AbstractFolder ^diskFolder = oDiskFile.ParentFolder;

    Xceed::FileSystem::DiskFile oZipFile(sZipFile);

    Xceed::Zip::ZipArchive oZipArchive(%oZipFile);

    oZipArchive.DefaultCompressionLevel = compressionLevel;

    oZipArchive.DefaultCompressionMethod = Xceed::Compression::CompressionMethod::Deflated64;


    false,false,oDiskFile.Name );


    return S_OK;


    // CCompressHelper::CompressFileEx()

    Imported from legacy forums. Posted by Chuck (had 1238 views)

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.