I have this serious problem with excel addins. Hope someone helps me in solving.

I have an .msi app, I created a .mst as per the company standards. I need to insert an excel addin(.xla) in the application. Whenever I launch excel, my addin must launch automatically. I have the idea of adding custom action in the .mst for execution of my excel addin. I used the following script for the addin execution.

On Error Resume Next
Dim oXL
Dim oAddin
Set oXL = CreateObject("Excel.Application")
oXL.Workbooks.Add
Set oAddin = oXL.AddIns.Add("C:\Program Files\ABC\XYZ.xla", True)
oAddin.Installed = True
oXL.Quit
Set oAddin = Nothing
Set oXL = Nothing

If the above script is run locally the addin gets installed. But when I insert this in the .mst the addin doesn't work.

Pls help me in this issue. I have been trying all the possible ways. Pls tell me the best sequence steps we can use for the application to work.

--
Charlie.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
You could create a vbs file, copy the file locally when you install the mst, then run an active setup script to run the vbs file when each user logs in again.
Answered 11/03/2009 by: Crazy8
Senior Yellow Belt

Please log in to comment
0
Location: After InstallFinalize
Condition: NOT REMOVE or NOT Installed
Properties: Immediate Execution; Synchronous; Always Execute

Remember, you'll need a companion CA for uninstallation.

Location: After InstallInitialize
Condition: REMOVE~="ALL"
Properties: Immediate Execution; Synchronous; Always Execute

Your script should be altered so that it has a single function. That function will take a parameter, indicating whether you're adding or removing the add-in, meaning you have only one code instance to maintain.
Answered 11/04/2009 by: VBScab
Red Belt

Please log in to comment
0
I've not looked into what these automation scripts add to the system (Does it dynamically enumerate those OPEN reg keys? - dunno. I'll go digging when I get a second....) but I'd have thought it should be deferred? But as I said, I don't know what it does to be honest so I'll shut up. Anyway, based on the parameter VBScab mentions, so long as you're executing in an immediate context you can use the feature state to determine what should happen like this:

'get state of feature. In this example, 'Complete' is the name of your main feature
Dim featureState : featureState = Session.FeatureRequestState("Complete")

'call your configureAddin subroutine - pass in the feature state
configureAddin(featureState)

Sub configureAddin(featureState)

Select Case(featureState)
Case 2
'logic to uninstall addin

Case 3
'logic to install addin
Case 5
'logic to repair addin
Case Else
'do nothing
End Select

End Sub
Answered 11/04/2009 by: captain_planet
Second Degree Brown Belt

Please log in to comment
0
Cap'n, It will, I suspect, enum the relevant keys at some point but it's done "internally", thus removing the onus from the packager.

Run in Immediate, automation automatically uses HKCU instead of HKLM so is quite safe there. I prefer it there, as not all users want the same add-ins. Obviously, one could use Active Setup instead.
Answered 11/04/2009 by: VBScab
Red Belt

Please log in to comment
0
Run in Immediate, automation automatically uses HKCU instead of HKLM so is quite safe there. I prefer it there, as not all users want the same add-ins. Obviously, one could use Active Setup instead. - Thanks for that.
Answered 11/04/2009 by: captain_planet
Second Degree Brown Belt

Please log in to comment
0
I have been successful in adding the addin to excel thru active setup. According to the standards, how to uninstall the added plugin. I have a .vbs to uninstall.If I put that as a CA, its not working. How to uninstall the added addin by active setup?
Answered 11/05/2009 by: charlie.deployer
Senior Yellow Belt

Please log in to comment
0
Typically you would find the excel addin registries at HKEY_CURRENT_USER\Software\Microsoft\Office\<Office_version>\Excel. I would create a VB Script which would remove the registries and run this script through active setup.
Answered 11/05/2009 by: jinxngoblins
Senior Yellow Belt

Please log in to comment
0
Nah, wrong approach. ALWAYS use XL Automation for add-ins, be that adding or removing.

The script quoted looks almost identical to the one available here on AppDeploy. The post containing it also has one for removal (which is again almost identical to the adding script, except that it sets the add-in's 'Installed' property to False).
Answered 11/06/2009 by: VBScab
Red Belt

Please log in to comment
0
Thanks Ian for your suggestion.. Unfortunately I have never worked on XL automation before... can you pls let me know how do I use this? and, where can i find it?
Answered 11/06/2009 by: jinxngoblins
Senior Yellow Belt

Please log in to comment
0
ORIGINAL: jinxngoblins

Thanks Ian for your suggestion.. Unfortunately I have never worked on XL automation before... can you pls let me know how do I use this? and, where can i find it?


it's all here if you did a search

http://itninja.com/question/excel-addin-removal-from-all-the-users-profiles&mpage=1&key=bheers䱯
Answered 11/06/2009 by: cygan
Fifth Degree Brown Belt

Please log in to comment
0
ORIGINAL: Crazy8

You could create a vbs file, copy the file locally when you install the mst, then run an active setup script to run the vbs file when each user logs in again.


Hi Folks,
the above method works like charm during installation. Works in the way I want to be during install. I have problem with uninstall. Once after uninstall, if I open excel, it shows that the path to the particular excel is not found and the addin is loaded in Tools---->Addin. There the addin is check marked. Please help me in this issue. If my software is uninstalled the addin must be uninstalled too. I used Active Setup during installation.

Thanks in advance.
Answered 11/10/2009 by: charlie.deployer
Senior Yellow Belt

Please log in to comment
0
I bet people roll their eyes when I say that scripting is easy but that good scripting isn't. Well, here we have a prime example.

For each installing Custom Action, you should create a companion uninstalling Custom Action, conditioned to run only on uninstall (REMOVE~="ALL"). Of course, for stuff which gets into HKCU, it gets tricky, since most people choose the Active Setup (AS) route without really thinking about uninstalling.

The AS scripts I use for HKCU-targeted objects check the ProductState using the WindowsInstaller.Installer object and, if the product isn't present, checks for the HKCU stuff. If the HKCU stuff is still present, it gets removed. If the product is present, but the HKCU stuff isn't, then the HKCU bits get installed. And, as usual, before anyone asks, no, I won't be publishing/sending/posting an example. Sorry: been burned in the past.
Answered 11/11/2009 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

The AS scripts I use for HKCU-targeted objects check the ProductState using the WindowsInstaller.Installer object and, if the product isn't present, checks for the HKCU stuff. If the HKCU stuff is still present, it gets removed. If the product is present, but the HKCU stuff isn't, then the HKCU bits get installed. And, as usual, before anyone asks, no, I won't be publishing/sending/posting an example. Sorry: been burned in the past.



That's excellent because I've encountered in the past that these AS scripts, if not authored to run silently, may cause additional issues if the HKLM registry doesn't get removed on uninstall. But that again comes back to good UAT testing. I'd be interested to try figure out how to do this script with clues like "ProductState",WindowsInstaller.Installer object" even though it's general. Anyway impressive solution you have!!
Answered 11/11/2009 by: PackageExpert
Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity