Permission Denied Error During Update of a Local MSOffice Add-In from Network

Question

I am attempting to write a procedure in PowerPoint 2003 that will allow automatic updating of an installed add-in. The general process is as follows:

1. Uninstall the add-in

   For Each objAddIn In Application.AddIns If UCase(objAddIn.Name) = UCase(AddInName) Then With objAddIn .Registered = msoFalse .AutoLoad = msoFalse .Loaded = msoFalse End With End If Next

2. Delete the file from the local Add-Ins directory

   Set objFSO = CreateObject("Scripting.FileSystemObject")
    If objFSO.FileExists(FileName) Then Set objFSO = Nothing Kill FileName End If

3. Copy over the file from the network location

4. Install the updated add-In

Upon reaching step 2, any attempt at deleting the file post-uninstall using either the FileSystemObject or a straight Kill inevitably generates Run-time error '70': Permission denied . If I hit Debug and then play, it runs through as if there was never a problem.

Side note: I realize I can use FSO to overwrite the local file, but that gives me the same run-time error.

I'm guessing the problem has to do with some aspect of the file being in use, but I can't figure out how to "release" the old add-in so that the underlying file can be deleted.

Does anyone have insight that can help?

Answer 1

You need to remove it from the Addins Collection before it can get physically deleted. Put this, right after your End With :

Application.AddIns.Remove objAddIn.Name

Answer 2

The KB Article that refers to a VBA function you can use to CHECK for a locked file is here. http://support.microsoft.com/kb/209189

It contains a simple function you can add to your VBA to check that a file is not locked and uses the same code sample that Otaku refers to in his answer.

What I would do is...

Replace the Kill Filename line in your code

If FileLocked(Filename) = True Then  
SetAttr Filename, vbNormal  
Kill Filename  
End If

*Where FileLocked is a custom function referred to in KB209189
**If this doesn't work, reply back, we could also look at replacing the Kill statement above with a lower level Win32 function that does the same thing (but perhaps more throughly). :D