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

昨天社群的卿先生问了一个问题，有webservice出错。 后面在我的解答中，最后他才说是ziptoolkit.dll的问题。

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

有一个问题请教一下，我在WIN10使用webservice.调用的COM使用ZipToolkit.dll压缩文件.在本机调用COM可以正常压缩文件。使用webservice时调用就失败了。之前用在win2000和win2013电脑的IIS就没有问题。不知道你是否知道原因。

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

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
	Endproc

Enddefine

首先确认一下默认目录的问题 默认目录 Webservice调用的vfp的com的默认目录为 x64 C:\Windows\SysWOW64\inetsrv
x32 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不会有影响啊。

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

那事情就先告一段落。