Bug in Excel handling VBA/VBScript installation of Add-Ins
 

When you install and activate an Excel Add-In (.XLA) programmatically the
first time, everything works as expected. However, if the installation is
performed from a local (non-removable) drive, Excel will not copy it in the
'C:\Documents and Settings\<user\Application Data\Microsoft\AddIns' folder
but leave it in the source folder and link to it.

When you try to update the same Add-In [programmatically] and you install it
from a local drive AND from a different folder (such 'C:\AddInv2' instead of
'C:\AddInv1') then Excel continues to link the first one. This also happens
when you install it from a removable drive; here, however, the Add-In is
copied to the '...\M$\AddIns' folder but then the Add-In might be exposed
*twice* in the "Excel|Tools|Add-Ins"

Workaround:
- First programmatically unload the Add-in (Excel as Automation Server
process must be killed otherwise the Registry is not updated,
"ExcelApp.Close" is not enough)
- Remove the Add-In link from the Registry (using WMI since "Wscript.Shell"
cannot do this due to a problem handling "\" characters in registry
keys/values)
- If from a local drive, programmatically copy the Add-In to the
'...\M$\AddIns' folder, otherwise use the "CopyFile := True" option when
adding the Add-In via VBA
- Load the new Add-In programmatically

VBS source provided on request