I have an Excel Automation Add-in that is registered with COM by my installer. By registering with COM, my add-in appears in the (for Excel 2007) Excel Options > Add-Ins > Manage Excel Add-Ins Go... > Automation list. The users must still navigate to the dialog above and select my add-in to enable it.
Is it possible (via a registry key perhaps) to enable my automaton add-in programmatically in my installer class (or in VBA) after the types are registered with COM?
Thanks in advance - Frank
Ive not done ths specifically, but a reference that I use has this to say regarding your question:
Automation Add-Ins are loaded in the same way as normal .xla Add-Ins , but using the ProgID instead of the file name, as in the following code:
Sub installAutomationAddIn()
AddIns.Add Filename:="Excel2007ProgRef.Simple"
AddIns("Excel2007ProgRef.Simple").Installed = True
End Sub
If you are creating an installation routinefor your Add-In, you may want to write directly to the registry in order to set the Automation Add-In as installed. To do so, you need to create the following registry entry (Which will already exist if you've used the above code).
(In the Registry Key:)
HKEY_CURRENT_USER\SOftware\Microsoft\Office\12.0\Excel\Options
(Create the string value:)
Name = the first unused item in the series: Open, Open1, Open2, etc.
Value = /A "Excel2007ProgRef.Simple"
Related
When we try to run analysis for office functions such as:
lresult = xlApp.Application.Run("SAPLogon", "DS_1", bw_client, bw_user, bw_password)
lresult = xlApp.Application.Run("SAPExecuteCommand", "RefreshData")
Despite analysis add-in is active in our workbook and all macros are enabled (trust center...), we always get the same error: Cannot run the macro "SAPExecuteCommand". The macro may not be available in this workbook or all macros are disabled.
Has anyone any idea to solve this? I´ve tried to add all SAP libraries in Tools/References, however it doesn´t work.
Thank you so much
You should have a look at the following registry key:
Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Excel\Addins\SapExcelAddIn
If the value "LoadBehavior" is set to something different than 3, the described error will occur because the COM Add-In is not loaded. If you set it to 3 ("The Add-In is enabled. If required, users can disable it in the COM Add-In dialog box."), the error should disappear.
See the SAP documentation for details on "LoadBehavior":
https://help.sap.com/viewer/df90d3701aba42b9a4351caa387bd672/LATEST/en-US/f26e8ad16c9b1014bf2c9a7eb0e91070.html
I am having difficulty with the load behavior of an Excel Ribbon Add-In developed as a VSTO solution.
The Add-In serves as an Excel VSTO Ribbon control that has several tabs, each tab's visibility is set to false by default and made visible by the workbook's Add-In instantiation.
For reasons that are unclear to me allowing the ClickOnce install to set the LoadBehavior to 16 (then a subsequent 9) is problematic. The initial value of 16 will load the workbook ribbon tab properly but after closing and reopening the same workbook the ribbon tab is not displayed.
However if another workbook is opened with the same Add-In, both tabs appear in each of the workbooks.
The LoadBehavior of "0" works as intended in any case and is the reason for the posted question.
Here is the VBA code for the Add-In instantiation
'This loads the Ribbon Addin
Private Function LoadAddIn() As Boolean
On Error GoTo Err_LoadAddIn
Dim msg As String
Dim m_addIn As COMAddIn
Dim m_automationObject As Object
Dim m_sWorkbookKey As String
msg = "Unable to load the PITA AddIn, please contact PITA support"
'Load the Excel Addin
Set m_addIn = Application.COMAddIns("PITA Ribbon")
'Connect the COM Add-In to the current workbook
m_addIn.Connect = True
'Set a reference to the utility class that the COM Add-In references
m_automationObject = m_addIn.Object
'If it is nothing then the Add-In is in a bad state
If m_automationObject Is Nothing Then
msg = "Error loading the PITA AddIn, please contact PITA support"
GoTo Err_LoadAddIn
Else
'Set the service type of the Add-In (currently only SQLServer)
m_automationObject.SetDataConnection "SQLServer"
'Set the workbook key - this is the name of the analyzer
m_sWorkbookKey = Worksheets("SheetX").Range("A10")
'Set the ribbon tab's visibility relative to the current workbook
m_automationObject.SetTabVisibility m_sWorkbookKey, True
'If the connection to the datasource is successful
'Populate the Tab's List Controls with the values from SQL Server
If m_automationObject.Connected = True Then
m_automationObject.SetTabDefaults m_sWorkbookKey
End If
End If
LoadAddIn = True
Exit Function
Err_LoadAddIn:
MsgBox msg, vbCritical, "AddIn load error"
LoadAddIn = False
End Function
I have tried altering the VSTO manifest file in the customization section below to "0" but the ClickOnce installer errors out when attempting an installation with this modification.
<vstov4:customization>
<vstov4:appAddIn application="Excel" loadBehavior="0" keyName="PITA Ribbon">
<vstov4:friendlyName>PITA Ribbon</vstov4:friendlyName>
<vstov4:description>PITA Ribbon</vstov4:description>
<vstov4.1:ribbonTypes xmlns:vstov4.1="urn:schemas-microsoft-com:vsto.v4.1">
<vstov4.1:ribbonType name="PITAAddIn.PITARibbon, PITA Ribbon, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</vstov4.1:ribbonTypes>
</vstov4:appAddIn>
</vstov4:customization>
Is there a way to have a ClickOnce installation set the default load behavior to "0"?
Any guidance on how to do this is greatly appreciated!
You need to re-sign the deployment any time you change the manifest directly after you publish it.
MSDN documentation
One of my answers that has a powershell script that automates this
The question posed by Chris in the comments section in the initial post identifies the core issue (i.e. Did you re-sign the deployment after changing loadBehavior to 0?)
Once the manifest file is modified for the Add-In, one must re-sign the manifest and assembly.
Instructions for modifying the VSTO deployment properties are addressed here
Instructions for re-signing assemblies and deployment manifests are addressed here
Generating self-signed certificates can be accomplished with PowerShell, this is the link that I used to create a code signing certificate for a test environment.
My steps were as follows:
Generate a new code signing certificate using PowerShell. komsky provides a great command line example.
After publishing the VSTO Add-In make modifications to the Add-In assembly manifest by LoadBehavior to 0
Use MAGE.EXE to sign the manifest mage.exe -sign "PITA Ribbon.dll.manifest -CertFile "C:\Certificates\cert.pfx -Password ******** -a sha256RSA
Use MAGE.EXE to update the VSTO deployment manifest mage.exe -update "C:\PitaDeploy\Pita Ribbon.vsto" -appmanifiest "Pita Ribbon.dll.manifest" -CertFile "C:\Certificates\cert.pfx -Password ******* -a sha256RSA
After performing these steps the VSTO installed with no issues.
The scenario is a Windows Server 2012 R2, 64 bit; Excel 2010, 32 bit. Many users, just a couple of them have administrative privileges. I installed Power Query from the built-in administrator. Without asking anything, the add-in got installed for all users; I mean that its settings may be found in a registry key under HKLM, not HKCU.
The key is
HKEY_LOCAL_MACHINE -> SOFTWARE -> Wow6432Node -> Microsoft -> Office -> Excel -> AddIns -> Microsoft.Mashup.Client.Excel
and the relevant value is
LoadBehavior (REG_DWORD)
Now just a few users really need Power Query. I don't want it to load for everybody, everytime Excel is launched. I tried some different settings for the LoadBehavior value (see this link). I found the following:
If LoadBehavior = 2, the add-in is not loaded for any user, no way.
If LoadBehavior = 3, the add-in is loaded for all users. However, if I create a specific key for a specific user (in the registry), the user can disable the add-in from Excel. E.g., in HKEY_CURRENT_USER, the path for the key is:
Software -> Microsoft -> Office -> Excel -> Addins -> -Microsoft.Mashup.Client.Excel
More specifically, it is sufficient to put in the user's key the LoadBehavior value, and this allows the user to decide whether he wants the add-in loaded or not. A value of 3 means "Load", a value of 2 means "No load".
I need exactly the opposite: add-in normally not loaded, and some users allowed to load it. I found that it is possible to set the LoadBehavior in the HKLM to 9. This means "Load on demand". I.e., the add-in is only loaded when the user requires an action depending on the add-in itself. Quite fine for me.
At this point I may leave out the key for specific users (in HKCU, e.g.). However, I found out that if I create it, it takes precedence over the HKLM (when the latter has LoadBehavior = 9). So it is possible to decide, for specific users, to have the add-in on "Always Load" mode. Just set LoadBehavior = 3 in the key under HKCU.
All this seems fine. Now the problem is that I need to call some Power Query actions from a VBA procedure. If Power Query is already loaded, all is fine. But if it is not loaded, even with the "Load on demand" setting, the action fails. In order to get Power Query loaded, one has to press some button on the Excel GUI which calls a Power Query action.
I found that there is a property of the add-in object available in VBA which indicates whether the add-in is loaded, and may be set to load or unload it from VBA. It is:
Application.COMAddIns.Item("Microsoft.Mashup.Client.Excel").Connect
If it is True, the add-in is loaded, and if it is False, the add-in is unloaded.
Now it should be possible to load the add-in just by setting this property to True. However, this is not the case in my scenario: the result is an error (80004005). This seems a problem related to the user not having administrative privileges. See this page - this behavior is considered a bug.
My last idea, which I will try later, is to completely remove the LoadBehavior in the key under HKLM. I already checked out that this prevents users from seeing the add-in, unless the user-specific key is created, in which case the user can set the add-in load behavior autonomally. I will see what happens in this case when the load is requested from VBA.
Meanwhile, I'd appreciate any idea to solve the thing: having Power Query not loaded normally, possibly available on demand for all users, loaded automatically from VBA (at least for some users), and all this without having to manually add the user-specific key for all users. It is acceptable to add this key for a few users, those who actually need Power Query.
EDIT
Removing, or renaming, the LoadBehavior value in the key under HKLM works. Power Query is then only seen by users who have a specific key under HKCU. If, in this key, the value of LoadBehavior is set to 3 (or 2), then the add-in is loaded by default (respectively, not loaded). The VBA instruction to change the .Connect property works fine; it switches the LoadBehavior between 3 (True) and 2 (False). Luckily, I can also set LoadBehavior = 9 in the registry (under HKCU), and the .Connect property is still writable. In this situation, when this property is assigned a True value the add-in is loaded, but the LoadBehavior value stands still at 9, so that upon closing and re-opening Excel the add-in is unloaded, is set as "Load on demand", and may be loaded from VBA.
This is exactly the behavior I was looking for; the only caveat is that the key needs to be created for all users who need Power Query. Since in my situation they may be counted on one hand's fingers, this solution is acceptable.
I'm still curious to see whether anyone comes out with any better solution.
Have you considered using a powershell script to update the registry entries for each user accordingly? The following example is a bit complex, line 111 has the loop you need to set it for many users.
https://daniel.streefkerkonline.com/2014/04/09/re-enable-microsoft-office-add-ins-with-powershell/
My other recommendation is you should not use VBA in Excel 2010 to call anything PowerQuery related. Given how it is an add-in I don't think it's included in the service agreements for Excel 2010. VBA interaction with PowerQuery was not fully supported in Excel 2010 or debugged. I noticed in several patches broke the GUI in PowerQuery altogether. Upgrading to Excel 2013 or 2016 was the fix.
When using Excel 2016 VBA editor to interact with PowerQuery, the macro code is challenging to debug and get working, and its references are poorly documented. It's more stable to show you an error and not just crash but it's very challenging to troubleshoot the errors the compilers find.
I have a SAP Business Objects Web 7.5 Add-in in Excel 2007.
The add in itself is made up of a compiled .xll file (CtExcelLinksWeb.xll) and a number of dll's.
A bit of vba shows the xll is registered, and all of its registered functions.
However, when I try to use one of these functions in VBA using Application.Run(), I get
Runtime 1004 - Macro may not be available or may be disabled.
I have tried registering the xll within the same sub (Application.RegisterXLL ()) and upon registering a VBAProject called CtEmpty.csv is created
I want to be able to automate the use of this add-in using VBA as it does long winded repetitive tasks, and then I can work on figuring out how to use the functions
Any help will be appreciated
Are the DLLs on the PATH? It may be that Excel can't load the DLLs that the XLL is dependent upon. Dependency Walker (depends.exe) is a handy tool for troubleshooting this kind of issue.
Also, have you tried using File/Options/Addins to register the XLL, as well as VBA code?
We have an existing add-in that we publish to users via click once. We would now like to use this as a vehicle to publish some of our existing C# methods directly into Excel so that the users can call them as a UDF.
For example - I have an assembly called MyAssembly, that has a class called MyClass with a public method called MyMethod. I also have an excel addin which adds some item to the ribbon for some custom functionality. I would now like to publish MyAssembly with my existing addin so that a person who has the addin installed can enter =MyMethod into a cell and have my custom method run.
How would one go about doing this?
I solved this quite comprehensively by using ExcelDna, an open source XLL implementation which is very simple to use, and pretty much avoids the whole COM debacle all together. So far it has matched our requirements perfectly...
http://groups.google.com/group/exceldna
you have not been very verbose about what you want to do. What do you mean with "users can call them"?
If you mean that add-in methods should be exposed to VBA you can find two articles on that here:
http://blogs.msdn.com/andreww/archive/2008/08/13/comaddins-race-condition.aspx
http://blogs.msdn.com/andreww/archive/2008/08/11/why-your-comaddin-object-should-derive-from-standardolemarshalobject.aspx