I've written a Excel-Dna based Addin in C#.
Used the following technique to register it at users computer (from WixInstaller and ManageOpenKey):
Locate the active Excel version key in registry (16.0 for this example):
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Options
Write the path of the XLL in the first available string value named
"OPEN". As seen in this screenshot, my Addin is written at "OPEN1" key.
Everything works as expected in the installation, but the problem starts if one of the addins is uninstalled using WixInstaller.
For example, if value "OPEN" is removed, addins at "OPEN1" and "OPEN2" will stop functioning. Excel explicitly looks for "OPEN", "OPEN1", "OPENXXX" sequence and if one of the values is missing - it stops enumerating.
I checked the source code of ManageOpenKey - it "blindly" removes the addin key even if this operation breaks the sequence.
Only solution I am thinking, is to write a function that re-orders all the keys. This does not look so difficult, but my question is:
Have anyone found a solution for this?
Yes you would have to rewrite the OPEN keys so that they are in contiguous ascending sequence.
Also worth removing the key from the ADDINS hive in case a user has used the XL Addin manager to move it from the active to the inactive list of addins.
Charles Williams answer is correct. When uninstalling an Excel add-in, you should rewrite & reorder the values in the registry that comes after the add-in being uninstalled (if any).
I've added an issue to the Excel-DNA WiXInstaller Template repo, for us to fix it.
Uninstalling add-in can break other add-ins
Related
I am currently maintaining a company-internal add in that only takes a mail, wraps it as attachment and sends it to our internal mail adress for spam reports.
The add in always had the issue that for seemingly no reason ( - besides: "the addin has caused outlook to crash - therefore it has been permanently disabled", when checking the addin state)
Outlook doesn't like it and disables it permanently without options to re-enable.
This was already an issue with Outlook 2016, and could back then be solved by setting a few registry keys. I was tasked to build a version for Outlook365. Outlook365 seems to be a lot more sensible there.
I have added a function that sets the following keys:
[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\SpamReporter]
"LoadBehavior"=dword:00000003
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Resiliency\DoNotDisableAddinList]
"SpamReporter"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Addins\SpamReporter]
"LoadBehavior"=dword:00000003
The following key is also rolled out via company policy:
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\outlook\resiliency\addinlist]
"SpamReporter"="1"
Furthermore. The assembly is signed with a Comodo Certificate in Visual Studio, and I have also tried to sign the installer itself again.
But all of these efforts seem to not make a difference. I thought I had a working version we could roll out, only to get the response from our rollout guy that the plugin doesn't show up for him when he tested it quickly.
This behaviour is really frustrating and the docs on Office 365 VSTO COM add-in troubleshooting seem really scarce.
I have spent an obscene amount of hours trying to fix this issue.
Most likely your addin takes too long to load (assuming it does not crash on startup).
Note that you get punished for using .Net - the whole .Net run-time of a particular version needs to be loaded before a single line of code in your addin runs. There used to be a Warmup registry key that allowed to tell Outlook whcih version of .Net run-time you are using so it will preload it, but it is no longer supported.
What does Outlook itself say when you go to File | Options | Addins | COM Addins?
We are developing a COM Add-In for Microsoft Word (only local, not for cloud usage). One of our customers had the problem, that each time he started Word, he had to manually activate the Add-In (Word Options > Add-Ins > Go... > tick the checkbox for the corresponding Add-In). I could reproduce this behavior by forcing an error in the Add-In coding which caused Word to crash. When starting Word the next time, I got the following message:
Of course I saw this message several times before. But: back then the consequence of clicking on "Yes" was that the Add-In was disabled. In that case it was sufficient to re-enable it one time (as described above). The next time the Add-In was started, you didn't have to enable it any more.
But now, additionally to disabling the Add-In, there is a registry key created. That key has the name of the Add-In and is located at the following path: HKEY_CURRENT_USER/SOFTWARE/Microsoft/Office/15.0/Word/AddInLoadTimes.
And it seems that this key causes the behavior described at the beginning. Because if I delete the key, start Word, enable the Add-In, close word, set the "LoadBehavior" key in the registry to "3" and then restart word, everything is fine again.
Now my question: is there a user-friendly alternative to enable the Add-In? Since the fewest of our users have administrative privileges, we cannot ask them to change some registry keys in order to fix the problem.
I hope that someone can help me with this.
Best regards
Timo
The path we took to avoid this issue, was to check in the code any static initialize methods / properties (which are invoked when word tries to activates the addin), which potentially could throw exceptions (IO work, REST api requests ... etc) and added to them try / catch blogs with some notification to the user that the activation of the addin failed + logging of the exception.
Side Note: At the time we have struggled the same issue we could not find anything but the registry key which you have mention to resolve this behaviour, but we faced the same security restriction, so this was not an option.
Not knowing much about your add-in, I can think of 2 possibilities:
Since the registry key is in HKCU (which is normally fairly accessible) why not create a 2nd 'helper add-in' that checks for problems with this key and resets it when required?
Otherwise you could use Inno Setup to create a dummy installer that does this for you?
I think this is possible because your target location is HKEY_CURRENT_USER/SOFTWARE/Microsoft/Office/15.0/Word/AddInLoadTimes (i.e. HKCU) which usually can be modified without admin rights: Changing registry without admin rights
Solution seems to go to Options > AddIns, then click GO aside Word Add-ins:
Then select desired one and click ENABLE/DISABLE.
I have written two addins , 1 for excel and 1 for word. However these addins have a lot of duplicates: Database handling, file handling,array handling which I would like to update 1 place instead of two.
We do have access to sharepoint, and could get access to visual studio. The thing is that people like to use file explorer and find the correct word or excel file, then open it then press a button inside the application which then should do things with the active document.
This is why we haven't written it as a .Net application yet, because that requires that people browse for the file inside the .NET application uless I am mistaken.
Is it possible to make an Addin which works both excel and word, or a dll? AnAnother important thing is that it should be easy to roll out a new version to the user, like stored on a network drive or similar.
Yes it is possible
The Hard Way
You can create a .Net DLL and call it from VBA. In visual studio a lot of people use Unmannaged Exports by Robert Giesecke to create DLLs that don't need to be registered (that way the DLL can be shipped with your document, and as long as it can be found you can use it).
Alternatively you might be able to do it manually as shown here by Hans Passant.
The Easy Way
Once the DLL is created you can declare it in a VBA module the same way you declare any other DLL for Late Binding and then call it from your code.
OR if you're happy to create the DLL and add it as a reference (possibly less portable) you can make it COM visible and register it for COM Interop in Visual Studio; this is probably the easiest way to go because you can then use Early Binding.
This is a walk through that might help: http://www.geeksengine.com/article/create-dll.html
But if you want to store the DLL on a network drive, well it might be that you really want to look at doing it the 'hard way', in which case look here: https://stackoverflow.com/a/5934745/3451115 and here: https://msdn.microsoft.com/en-us/library/bb687915.aspx
The strange problem I am having now is the Excel 2010 Add-in won't let me use the newer version. For some reason, it is still pointing to the old version and displaying the old UI.So my first impression about this is perhaps Excel caches stuff in the background or something.
This problem seems to be disappeared if I set the Add-in LoadBehavior value to 16 or 3 instead of 9 (the default value is set to 9). But I am not sure if it's a fix or probably I just somehow get lucky. Anyway, I hope someone can help explain a bit further about this problem. Thanks.
Have you appended "|vsto" to manifest path (check registry software/microsoft/office/exce/addins/[your addin name]/manifest. if this is not done vsto will always pick dll from clickone cache
I'm working on a VSTO add-in for Outlook that, if another custom VSTO is loaded, will perform a specific action. How would I determine if that VSTO is loaded? I've not delved too far into COM as of yet other than writing a number of add-ins.
You can check the key:
"HKLM\Software\Microsoft\Office\Outlook\Addins[YourAddInName]"
in the registry.
Existence of the key means that the AddIn is installed.
You can also read the value LoadBehaviour under the above key, the value 3 means that the addin is loaded/to be loaded normally. The value 2 means that the addin has problems.