|
Thanks very much. and I have got the new version.
|
|
|
|
|
I like to use the Zip and Unzip classes in my .NET Managed Extension C++ library project. But when it was linked, it generated an error below.
error LNK2019: unresolved external symbol _main referenced in function _mainCRTStartup
The help for this error from MSDN is as following.
In Visual C++ .NET 2003, this error will be generated when /clr is used and the CRT is not linked into your executable. Any object code generated by the compiler that is not built with /clr:initialAppDomain contains a reference to the _check_commonlanguageruntime_version function, which is defined in the C Runtime Library (CRT). This function provides for an error message if your application is run on version 1 of the runtime. Code generated by the current compiler is not compatible with version 1 of the common language runtime. So, if you compile without the CRT in Visual C++ .NET 2003, you should include a definition of the _check_commonlanguageruntime_version function in your code. As an alternative to using the _check_commonlanguageruntime_version function, you can link with nochkclr.obj, which contains an empty version of the function and does not provide for an error message if you run your application on version 1 of the runtime. To build an application with the current compiler version to run on the previous version of the runtime, use /clr:InitialAppDomain.
I tried to link it with different CRTs and still get this error. Is the zlibstat.lib not compatible with VS.NET?
Can anyone help me on this? Thanks.
Long Deng
|
|
|
|
|
>> Is the zlibstat.lib not compatible with VS.NET
i think this is definitely something that needs answering.
your best bet might be to contact gilles volant directly.
sorry i can't suggest anything else but i have zero knowledge of .NET at present.
regards
dang!
AbstractSpoon
|
|
|
|
|
I may have found a bug in the code.. Correct me if I am wrong.
What I want to do is create an archive in a different directory than the source files of the archive.This works fine,but the class is storing full path info in the archive including the drive letter.
I am using winzip to test extraction, and it gets confused when trying to extract the file because it sees "c:" in the file name and can not extract it.
At the bottom of:
bool CZipper::AddFileToZip(LPCTSTR szFilePath, bool bIgnoreFilePath)
I see that zipOpenNewFileInZip 2nd parameter is filename, but in this instance the drive information has not been stripped off. Once I stripped off the drive info from the filename before calling this function the archive created played nice with winzip and it extracted the stored files without a problem. Is there something I am doing wrong
=======================================
: W. Scott Dillman
: Principle Software Engineer
: binaryRevelations Interactive, LLC.
: http://www.binaryrevelations.com
=======================================
|
|
|
|
|
hmm...
my ProjectZip article on CP does the same thing you're trying to do without any apparent problem (i use the feature all the time).
i think i need you to help me debug things.
consider the AddFileToZip function
the following line should detect if its a fullpath.
bool bFullPath = (strchr(szFilePath, ':') != NULL);
if it is then the the following code should remove the root path bit
else if (bFullPath)
{
if (0 != _strnicmp(szFilePath, m_szRootFolder, lstrlen(m_szRootFolder)))
return false;
lstrcpy(szFileName, szFilePath + lstrlen(m_szRootFolder));
}
can you try to follow this thru in the debugger and tell me what you get.
dang!
AbstractSpoon
|
|
|
|
|
I see what the problem was... m_szRootFolder has no length therefore szFileName contains the the entire path.
This happens because the zip file name I used in OpenZip() did not have the full path, becuase I am setting the current working directory elsewhere in my application.
I should be using GetCurrentDirectory() and append my zip file name to it, before passing it to OpenZip() ...
Thanks again,
Scott
=======================================
: W. Scott Dillman
: Principle Software Engineer
: binaryRevelations Interactive, LLC.
: http://www.binaryrevelations.com
=======================================
|
|
|
|
|
thanks for looking into this.
i will also add a fix to detect for a relative path in OpenZip() and correctly build the root path from the cwd.
regards
dang!
AbstractSpoon
|
|
|
|
|
scott,
i've added a fix for this problem and sent an update to CP.
in the meantime you can get the latest code from my website (see link below).
ps. in researching a fix i stumbled upon the crt function '_fullpath' which does exactly what you were suggesting.
regards
dang!
AbstractSpoon
|
|
|
|
|
I can't seem to get the class to append files to an already created zip file. It just seems to delete the entire contents of the archive and replace it..
If I do something like this:
<br />
CZipper zipper;<br />
zipper.open("test.zip",NULL,TRUE);<br />
zipper.AddFileToZip("test.txt");<br />
zipper.close()<br />
All the files in the archive are now gone and the only file would be test.txt.
I'm not sure where I am going wrong here. Incidently the zip file I am trying
to append to is created by CZipper also.
any ideas??
=======================================
: W. Scott Dillman
: Principle Software Engineer
: binaryRevelations Interactive, LLC.
: http://www.binaryrevelations.com
=======================================
|
|
|
|
|
this definitely sounds like a bug, scott.
i'll look at it tonight or over the weekend.
thanks for finding it
regards
dang!
AbstractSpoon
|
|
|
|
|
Thanks for looking into it...BTW excellent work..
-Scott
=======================================
: W. Scott Dillman
: Principle Software Engineer
: binaryRevelations Interactive, LLC.
: http://www.binaryrevelations.com
=======================================
|
|
|
|
|
unfortunately scott, this is proving more tricky to figure out than i thought it might.
however, i'm onto it so it should get fixed sooner or later (hopefully not too much later).
regards
dang!
AbstractSpoon
|
|
|
|
|
I played with thel ibrary and found some behavior different from WinZip
I zipped a folder where some subfolders contained no files, some had files.
When I unzipped the just created archive, the folders that had no files in them did not get unzipped or even show up in the test application's list control. When I did the same thing with WinZip, directory structure was unzipped the same as it was before zipping, regardless of whether folders were empty or not.
By playing with WinZip and test app, comparing results, I determined then empty folders did not make into the archive at all. Thus I suspect the problem is in Zip operation. I do not know if the problem is in the zlib or the wrappers yet; when I have time, I will trace it.
|
|
|
|
|
yes, i agree that this is very likely a problem in my zip classes.
i guess i did not anticipate such a requirement as zipping empty folders.
i'll look into it.
thanks
dang!
AbstractSpoon
|
|
|
|
|
i've figured out how to fix this and will post an update as soon as i can.
normally there is no need to explicitly add folders as they get added as a by-product of adding a file.
empty folders are of course not handled by this so I've got to add code to explicitly detect and add empty folders.
thanks for finding it.
dang!
AbstractSpoon
|
|
|
|
|
I played with thel ibrary and found some behavior different from WinZip
I zipped a folder where some subfolders contained no files, some had files.
When I unzipped the just created archive, the folders that had no files in them did not get unzipped or even show up in the test application's list control. When I did the same thing with WinZip, directory structure was unzipped the same as it was before zipping, regardless of whether folders were empty or not.
By playing with WinZip and test app, comparing results, I determined then empty folders did not make into the archive at all. Thus I suspect the problem is in Zip operation. I do not know if the problem is in the zlib or the wrappers yet; when I have time I will trace it.
|
|
|
|
|
|
i've finally fixed this and posted an update to CP.
in the meantime you can get the latest code from my website (see link below).
regards
dang!
AbstractSpoon
|
|
|
|
|
Dan! While your project compiles and links with no errors, when i follow your instructions to add your files and zlibstat.lib to my existing project, i get the below error messages and I cant figure out whats wrong.
Can you help? Thanks!
Compiling...
Zipper.cpp
Linking...
Unzipper.obj : error LNK2001: unresolved external symbol _unzOpen
Unzipper.obj : error LNK2001: unresolved external symbol _unzClose
Unzipper.obj : error LNK2001: unresolved external symbol _unzCloseCurrentFile
Unzipper.obj : error LNK2001: unresolved external symbol _unzGetGlobalInfo
Unzipper.obj : error LNK2001: unresolved external symbol _unzGoToFirstFile
Unzipper.obj : error LNK2001: unresolved external symbol _unzGoToNextFile
Unzipper.obj : error LNK2001: unresolved external symbol _unzGetCurrentFileInfo
Unzipper.obj : error LNK2001: unresolved external symbol _unzReadCurrentFile
Unzipper.obj : error LNK2001: unresolved external symbol _unzOpenCurrentFile
Unzipper.obj : error LNK2001: unresolved external symbol _unzLocateFile
Zipper.obj : error LNK2001: unresolved external symbol _zipCloseFileInZip
Zipper.obj : error LNK2001: unresolved external symbol _zipWriteInFileInZip
Zipper.obj : error LNK2001: unresolved external symbol _zipOpenNewFileInZip
Zipper.obj : error LNK2001: unresolved external symbol _zipOpen
Zipper.obj : error LNK2001: unresolved external symbol _zipClose
Debug\WATCHDOG.EXE : fatal error LNK1120: 15 unresolved externals
Error executing link.exe.
|
|
|
|
|
it looks like its not linking to zlibstat.lib correctly.
try adding the zlibstat.lib to the link tab of your project settings and see if that works better.
note: the easiest way to do this is to drop the lib into the project folder so that you don't need to worry about figuring out the correct relative path.
regards
DanG
AbstractSpoon
|
|
|
|
|
|
define ZLIB_WINAPI in project settings/c++/preprocessor definitions, i think.
it cost me a lot of time.
for example:
extern unzFile ZEXPORT unzOpen2 OF((const char *path,
zlib_filefunc_def* pzlib_filefunc_def));
ZEXPORT is defined in the zconf.h
if we use the zlib as dll, we should define ZLIB_DLL, i.e., ZEXPORT is __declspec(dllexport)
if we use the zlib as static link, it seems that we should define ZLIB_WINAPI, i.e.,
ZEXPORT is WINAPI, means stdcall. functions in zlibstat.lib all are stdcall
Zipper.obj : error LNK2001: unresolved external symbol _zipOpen
_zipOpen means _cdecl call
so it was not found in zlibstat.lib.hello to all
|
|
|
|
|
I tried using this and I get an error (-103 invalid zip file) from unzOpenCurrentFile inside the CUnzipper:Unzip method when trying to unzip a Winzip 8.0 compatible file. Winzip unzips it perfectly.
Please help!!! I have this already integrated into my app and don't want to take it out!!
Thanks
|
|
|
|
|
i'm afraid that you will need to direct this to Gilles Vollant (link in Credits section).
regards
DanG
AbstractSpoon
|
|
|
|
|
i mailed gilles and he expressed some surprise that you had a problem.
he asked if you could forward the zip file to him so he could check it out.
is this ok?
regards
DanG
AbstractSpoon
|
|
|
|