VB6, VBscript, File exists, Shell, copyhere, .NET Framework 2.0

http://groups.google.com/group/microsoft.public.scripting.wsh/msg/8b484bf43a96d7e9?hl=en&lr=&ie=UTF-8
this will explain it, but the fix i think you want is

SA.NameSpace(CopyTo).CopyHere (SA.NameSpace(ZipFile).items), &H100 

Select allOpen in new window

Thanks for trying but this is very similar to the first code I had.    I tested my interpretation of your suggested code. It produces the same erroneous error -- File exists -- when it does not.
The zip file has 8 folders in it and each folder has two small files.  It should interpret the zip file as a compressed folder. The code that I posted previously WORKED before I installed .NET Framework 2.0.

The test code is attached:

Public Sub main()
Dim copyTo As Object
Dim ZipFile As Object
Dim sa As Object
Set sa = CreateObject("Shell.Application")
Set copyTo = sa.namespace("c:\xtProject_51\references\test5")
Set ZipFile = sa.namespace("c:\xtProject_51\references\module_references.zip")
sa.namespace(copyTo).CopyHere (sa.namespace(ZipFile).items), &H100
 
End Sub

Select allOpen in new window

hmm,.
https://www.experts-exchange.com/questions/22097165/VB-Net-Shell32-Zip-file.html

Sub main()
        Try
            Dim sc As Shell32.ShellClass = New Shell32.ShellClass
            Dim SrcFlder As Shell32.Folder = sc.NameSpace("c:\xtProject_51\references\test5")
            Dim DestFlder As Shell32.Folder = sc.NameSpace("c:\xtProject_51\references\module_references.zip")
            DestFlder.CopyHere(SrcFlder.item, 20)
            System.Threading.Thread.Sleep(500)
    End Sub

Select allOpen in new window

VB6 will not allow dim as shell32.shellclass, nor the system. threading statement.  I don't think this is so much a coding problem as it is some changed component of Windows, the result of the .net 2.0 install.  
What did .NET do to my system?  The original code I pasted works fine in XP sp2 without the .net 2.0 framework.  How can I undo it?  Apparently you cannot uninstall it and the Restore to an earlier time did not solve the problem.  But if it cannot be undone, I was hoping there might be an alternate coding strategy.

not sure why but changing the way it was written seemed to work for me.

Set sa = CreateObject("Shell.Application")
Set copyTo = sa.namespace("c:\xtProject_51\references\test5\")
Set ZipFile = sa.NameSpace(sa.namespace("c:\xtProject_51\references\module_references.zip")).items
sa.NameSpace(copyto).CopyHere zipfile

Select allOpen in new window

What you have here is essentially the same code that worked for me prior to installing the .NET 2.0 Framework.  Have you installed that on your system?  If you have not, then this code will work for you whereas is does not work after .NET 2.0.  I have been seraching for someone in the developer community to confirm that .NET 2.0 causes this problem. I have also searched msdn  but have found nothing. I suspect Microsoft knows what is going on but is reluctant to address it since vb6 is old hat.

it works with dotnet 2 installed
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

and i agree it is essentially the same code, but it didn't work initially when i got it from you and then it did this way.
i agree it is essentially the exact same thing. not sure why.
does it still not work for you?

possibly it could be related to something else?
try to run it as a vbs instead of within vb6,.. does it work that way?

have you tried unzipping to an empty folder?

Yes, each try I am unzipping to an empty folder.  I do not know how to test in VBScript. The only time i have used vbscript is in html and that won't allow this type of code (permission denied). Maybe it needs to be signed code(?). One more bit of info: when I did the restore, it apprently removed the record of having installed .net 2.0 aince in my Add/Remove programs I only have .net 1.1 now. I am however, certain that the install of .NET 2.0 caused this problem to begin with.

copy the code i pasted and save it in a text file as unzip.vbs then double click on it

(I didn't know it was that easy.)  I did as you said and got exactly the same results -- File Exists.  I am becoming more convinced that the solution will involve either reinstalling, uninstalling or repairing something.

and you tried it with different zip files as well?

what is the exact message you get?

msgbox is too short to show entire dialog title  "Error Copying File or F ..."
Red ball with white X
Text says "The file exists."  OK button
It creates the first folder in the zip file but not the two files that go inside.

Every test I empty the destination folder.
Yes, I tried a different zip file but I kept it so that there are no files at the root of the zip, only inside a folder in the zip -- this is the way I need to have them extracted.  I also cut it down to just two files.

Same error.

i don't suppose the following helps? doesn't here
http://msdn2.microsoft.com/en-us/library/ms723207.aspx


System.Shell.Folder.copyHere(oItem [, intOptions])
16 Click "Yes to All" in any dialog box displayed.  

?

sa.NameSpace(copyto).CopyHere zipfile, 16

or from here
http://www.microsoft.com/technet/scriptcenter/guide/sas_fil_vrwr.mspx?mfr=true
 
&H10&
 Automatically responds "Yes to All" to any dialog box that appears. For example, if you attempt to copy over existing files, a dialog box appears, asking whether you are sure you want to copy over each file. Selecting this option is identical to clicking Yes to All within that dialog box.
 
?

sa.NameSpace(copyto).CopyHere zipfile,  %H10%

curious
what happens when you extract it using winzip?

Using winzip I get the conatined folders, each with two files in them.  In the short version of the zip file I discovered something that may be a clue:  there is only one file in each of two folders, whereas before there were two files in each of 8 folders.  In the first case it failed after creating the first folder; in the second case it created both folders and then failed.  In the first case, could it be acting as if it needs to create a folder for each file and since there are two files in the first folder it stops after creating the first folder and is reporting that it cannot creat another folder of the same name?

Also, remember that it works perfectly on other machines that have XP sp2 installed.  So what I am trying to determine is whether this is a problem with .net 2.0 (and so others will encounter this problem in my code) or if my installation of .net 2.0 on this one machine is corrupted in some way.

probably not exactly what you want, but it bypasses the file exists message

const strfolder = "c:\scripts\" 		'to unzip to
const myzip 	= "c:\scripts\word.zip" 'file to unzip
 
Set sa = CreateObject("Shell.Application")
Set copyTo = sa.NameSpace(sa.namespace(strfolder))
Set ZipFile = sa.namespace(myzip)
Set objFSO = CreateObject("Scripting.FileSystemObject")
for each f in zipfile.items
	do until objfso.folderexists(f.name) = False
		iffldrexists f, x
		x = x+1
	loop
	copyto.CopyHere(f)
next
 
 
function iffldrexists(thefolder, strcount)
'if the folderexists, then add a number at 
'the end of the folder name of the one that exists
if not objfso.folderexists(f & strcount) then	objFSO.MoveFolder f, f & strcount
end function

Select allOpen in new window

Thank you for your persistence, but that did not work either.  Since the folder does not exist to begin with, it does not do the inside of the loop but goes to copyTo.copyhere.  After it creates the folder, (or as it is creating the folder) it returns "File exists."  The very first time it hits the copyto.copyhere statement I get the error.  So the trapping part is never executed.  I suspect the underlying copyhere method is broken in some way -- may be some mismatched shell.namespace component but I do not know enough about the individual pieces to diagnose that.

have you merely tried rinstalling  the dotnet framework or even the windows scripting host?

http://www.microsoft.com/downloads/details.aspx?FamilyID=47809025-D896-482E-A0D6-524E7E844D81&displaylang=en

we can try to get more help.,.
post a 0 point question in the main group asking for additional help. leave a link to this question

https://www.experts-exchange.com/questions/23022290/VB6-VBscript-File-exists-Shell-copyhere-NET-Framework-2-0.html

Thanks for the advice. I created a new question and selected XP operating system as one of the groups -- I have no idea how to choose "main group."  Anyway, I assigned it 200 point because it would not allow 0 points.  At this time I would be willing to give all points to whomever solves this problem.  Yes, I uninstalled and reinstalled .NET 2.0 and then I found a MSDN site: How to repair .NET 2.0 and I went through that exercise as well.   After doing this I tested your suggested solutions.  Same outcome.

Is the "problem machine" running Internet Explorer 7, while the "working machine" is still running IE6?

No. They are both running IE6 6.0.2900.2180.  Just for clarification:  the problem is with VB6 where IE is not even running.

I understand. But CreateObject("Shell.Application") is identical to creating a new instance of the ShDocVw.ShellWindows class. ShDocVw.dll is the DLL that contains this class, a system DLL which is overwritten by a newer version when you install Internet Explorer 7.

Although you don't have installed IE7, can you still check the version of ShDocVw.dll on both machines? The DLL can be found in C:\WINDOWS\SYSTEM32

The working system has 6.00.2900.3231 (xpsp_sp2_gdr.071010-1320).
The one with the error has 6.00.2900.3231 (xpsp_sp2_qfe.071010-1316).  Both have 10-11-2007 as date.

well if that is what is needed try copying the dll from a working machine to the non working one and see if it resolves the issue,..

you may have to register it

start - run - regsvr32 ShDocVw.dll

Had to do safemode and all, but checked to make sure that the file was in fact the one from the machine where it is working.  I am getting the same error!  Here is I hope, another clue:  If I click through the errors messages, I end up with all 11 of the folders created in the destination folder.  ( The zip file contains 11 folders each with two files in them)  After it creates the folders the code exits.  The code that creates the folders is the last one posted by weelio:

const strfolder = "c:\scripts\"       
const myzip       = "c:\scripts\word.zip" 'file to unzip
etc.............

so you get the error message, but it creates the folders anyway?

add
on error resume next
to the top of the script,. what happens, then?  :)

Nice try ;-)
What it does NOT do is create any (not one) of the files that are inside the folders.  

This is weird, but it might be another clue: I just discovered that html links that point  to Word documents no longer open up.  For example, I have links that look like this: file:///c:/myHappy.doc    that, when clicked, do nothing.  This has to be some system component crap out.

Here's something else I stumbled upon: if I right click on an html link that points to a Word document (as described above) I can Save Target As and give it a .doc name and then in the Download dialog box that IE pops up when you do this,  I can click Open and it opens right up.

RubenvdLinden: are you suggesting that IE 7 could solve this problem?

i think he is suggesting that IE7 could cause additional problems,. :)

what version of shell32.dll are you using,.. i think this may have something to do with it..
maybe reregistering it

There are known situations where IE7 causes problems with scripts because of the improved security and changes in the SHVWDOC.dll file. However, the Namespace method should also work with IE7.

If a system component is indeed corrupted, upgrading to IE7 might even work for you.
You can also try the system file checker: click Start > Run > sfc /scannow

I ran sfc and it completed without any messages or errors (I guess that''s normal).  I found that I had to reinstall IE 6.0 to get my html links to work again.  I don't know what is going on, but I have Mcafee protection and I ran hijackthis to see if there were any suspicious activities going on on startup. The versions of shell32.dll are
6.00.2900.3241 (xpsp_sp2_gdr.071025-1248) on the working machine and
6.00.2900.3241 (xpsp_sp2_qfe.071025-1245) on the machine with the .copyhere problem

try re-registering the shell32.dll.. if that doesn't work, try copying the otherone over and see...

shell.application is from shell32,..

I copied shell32.dll from the machine where it is working over to my machine with the error and reregistered it.  I am still getting the same error.  The behavior is the same: after it creates one of the destination subfodlers and should be copying the first file inside it, it thinks it needs to create the folder again -- and this is where the error occurs.  As I wrote before: if I step through all of the errors I end up with all of the subfolders craeted but with no files in side of them.

can you take a screen capture of the error and upload it

Here is a flash screen recording of the whole problem:
http://princetoncenter.org/copyhere/copyhere.html

I now see the exact error messages: "Error copying file or folder" and "The file exists"
I also see you're running McAfee on the system. Temporarily disable McAfee COMPLETELY, then try your code again.

Exactly same results. I killed all of mcafee processes.

do me a favor and try it with shorter filenames

c:\test\123.zip or something

http://kbalertz.com/835926/Programs-scripts-CopyHere-method-might-items-specified-using-wildcard-character.aspx

although this doesn't specifically identify the particular issue it does show the files associated with the 'copyhere' method

Microsoft Windows XP 32-bit versions   Date         Time   Version            Size    File name
   --------------------------------------------------------------
   02-Apr-2004  03:15  6.0.2800.1361     921,600  Comctl32.dll    
   02-Apr-2004  03:15  6.0.2800.1502   8,348,672  Shell32.dll      
   02-Apr-2004  03:15  5.1.2600.1363     676,864  Sxs.dll          
   10-Mar-2004  17:59  5.1.2600.1363     593,408  Xpsp2res.dll  


maybe replacing and reregistering all these files will resolve the issue at hand..

pull them from the working ones and put them on the nonworking ones.

When tring to unregister and then re-register the files copied from the working machine I got this.DllRegisterServer entry poiny could not be found.  This file cannot be registered.
DllUnRegister entry point could not be found.  This file cannot be registered.

I got the two errors above for all filoes except shell32.dll.

I also think I am running into WFP problems -- replacing the files as soon as I rename or try to replace them.

That's correct. You cannot register these dlls, except for shell32.dll. No need to worry about this.

weellio suggested that I post a link to this question in another area so I added one in the OS group because I suspect that that is where the problem lies.  
https://www.experts-exchange.com/questions/23025756/need-additional-responses-main-group.html

I have 500 points on each question and if I can get a solution, all points will go to the wizard who can unravel this one.

I found it.  Weellio, thanks for hanging in there with me on this one.  Also thanks to rubenvdLinden.  Weellio's last comment got me looking in the temp directory and I found a long list of temporary folders associated with the unzipping process that were serialized up to 99 and they ended on 12/10/07, the date of my original error.  Apparently the code creating these temp folders/files was not written to deal with temp folders greater than 99!!!  I deleted these temp folders and it worked as it should.  One of the problems may have been that the temp folder it created may have had a read only file in it and the normal housecleaning for the temp file would not remove the temp folder because of this.

I was focusing on newly installed components. Thanks for getting me to look outside the box.

glad you got it figured out.  :)

I am running daily reports that are unzipped every morning and ran into the same problem when the count reached 99. Thanks to everyone who spent time solving this!