ZipToolkit在win10下不听使唤，猫猫花了一天时间却无功而返，无奈之下这样做了

昨天社群的卿先生问了一个问题，有webservice出错。

后面在我的解答中，最后他才说是ziptoolkit.dll的问题。

我记得去年他有问过同样的问题，我翻了翻记录，终于找到了。

开始了排查之旅，先看一下代码

代码语言：javascript代码运行次数：0运行复制

Define Class qiyuprj As Session OlePublic    Procedure helloworld        Local llReturn        Local lcfile,lczapfile        lcfile ="1test.txt"        lczapfile ="1test.zip"        Declare Integer ZipFiles In "ziptoolkit.dll" As zip String,String,Integer,String        If File(lcfile)            If zip(lcfile,lczapfile,1,"password")>0                lcreturn  = "压缩文件成功，压缩文件名："+lczapfile            Else                lcreturn  = "压缩文件失败"            Endif        Else            lcreturn ="没有找到文件："+lcfile        Endif        Clear Dlls "ZIP"        Return lcreturn    Endproc    Procedure getparams(key1,key2)        Return "您传的参数是:"+key1+key2    EndprocEnddefine

首先确认一下默认目录的问题默认目录 Webservice调用的vfp的com的默认目录为x64 C:\Windows\SysWOW64\inetsrvx32 C:\Windows\System32\inetsrv把这个ZipToolkit.dll放到这个目录，声明不再出现找不到32位DLL的情况。

但是这句出问题了zip(lcfile,lczapfile,1,"password")，错误信息如下

helloworld e:\web\testwebservice\qiyuprj.prg 第 11 行发生错误 不能加载 32 位 DLL c:\windows\system32\inetsrv\ziptoolkit.dll。1753

看来问题还未解决。

再次确认是不是临时目录没有权限写入的原因。于是下载了一些文件夹检测的工具来看这个COM生成的临时文件在哪里，但系统产生了一堆文件，我看花了眼还是没有找到。

于是我想是不是应该把IIS的用户权限提权一下。在应用程序池把用户设为超级管理员

问题没有解决。

我最后还是在想是不是真是权限问题，没有权限生成临时文件，所以导致加载错误，但今天时间不够了，还有其它工作要去。

当然利用MYFLL的ZIP压缩功能就完会没有问题了，因为ZIP是标准格式的，那服务端用MYFLL， 客户端用ziptoolkit不会有影响啊。

代码语言：javascript代码运行次数：0运行复制

Set Library To myfll additIf Zip(lcfile ,lczapfile ,"password")    lcreturn  = "压缩文件成功，压缩文件名："+lczapfileElse    lcreturn  = "压缩文件失败"Endif

那事情就先告一段落。