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.
Related
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
I am using Word (from 2007 to 2013) to convert documents to PDFA format,
and i'm having trouble with users who have certain add-ins. When they use the system they get an assortment of COM Exceptions like RPC_E_SERVERCALL_RETRYLATER and (0x800706BA) RPC server unavailable.
If they disable the add-ins it works fine. Problem is that the add-ins are required so that simple solution is out the window. (Also I know that using word for this kind of thing is frowned upon, and we are looking into getting something better, but until the business side want's to pay, we are stuck with this)
The new plan is to start word with the /a parameter to make it start without add-ins.
I have seen another question How can I start MS Office Word from .NET without Add-ins?
Where there is a working solution for one instance of Word,
//startup without plugins
System.Diagnostics.Process.Start(
#"Winword.exe",
#"/a");
//give a time for startup
Thread.Sleep(2000);
//attach to office
Application officeApplication = (Application)Marshal.GetActiveObject("Word.Application");
My question is two fold: Is it possible to set startup parameters when you start word like this
var _word = new Word.Application();
So I don't have to use Process.start();
And if not, how do I do a late bind to a specific word instance (GetActiveObject(), always gets the oldest word instance), perhaps there is some other method?
To your first question, there's no way to pass parameters or otherwise influence how Word starts when using the new keyword. The instructions for starting the application are in the Registry, so it would involve changing how the new keyword is implemented in the Registry. And since this Registry entry also determines how Windows Explorer starts the Word.Application, changing the Registry entry would also change the way Word works for the user.
It is possible to unload add-ins after an instance of Word has started via the Application.COMAddins property. This is the equivalent of unchecking the boxes next to the Add-in entries in the COM Add-ins dialog box in the Word UI. I would test whether doing this in the UI allows your software to work properly.
If it does, you can incorporate this in your code - no need to worry about starting Word without the add-ins.
Which brings us to the second question: GetActiveObject is only able to access the single instance of Word (any Office application) registered in the ROT. By design, Office applications register only a single instance in the ROT and usually, this will be the first instance. There are a couple of KB articles on MSDN that describe this. The only work-around is to start two instances of Word in the user profile, "hiding" the first (the registered) one and presenting the second to the user.
But this can be tricky, so if it works, I'd go with the suggestion about the COMAddins collection to unload the problem Add-ins.
(I'm currently on a mobile device. Next time I'm on my main machine I'll try to remember to paste in the links to the KB articles on the ROT.)
I faced really strange limitation of the MS Dynamics CRM, that is not covered anywhere in documentation.
It's is possible to create entities of sdkmessageprocessingstep type from within plugin, thus subscribing plugin to the events on demand, however it's not possible to perform reverse operation — delete these steps, or at least disable them.
CRM fires exception in case if Delete message is called for sdkmessageprocessingstep, however the same code works just fine, when executed from command line application for example.
Have anybody faced with the this issue before? What's the reason of it? Do you know any approach how to work around it?
It is indeed possible to delete plugin steps from within plugin code. However, the user must still be authorized to do this.
For sandboxed plugins it is enough to have the appropriate entity privileges.
For plugins registered for full trust mode the user must be a member of the deployment administrator group. Also, the plugin code must be executed on a thread impersonating the Windows account of the administrator. This implies that this only works in an OnPremise environment and within the company network.
Before you delete a plugin step, you may need to delete associated pluginstepimages first.
I'm writing a small service in C# and I've installed it and uninstalled it a couple of times and all of a sudden it won't install again. I tried to uninstall it and it says there is nothing to uninstall, but when I install it again I get the following message:
Error 1001: The specified service already exists
Now, I've tried the following solutions:
Close the service manager (as an open service manager may hold a
handle to it)
Tried to find it with SC QUERY and delete is using SC DELETE
(according to
Service already exists (when it clearly doesn't))
Tried to remove it in regedit (doesn't exist there)
I've correctly added the project output to Custom Actions (install,
commit, rollback, uninstall)
Restarted the computer (!)
I'm running out of ideas. There is absolutely no proof that the service is installed on my computer and even though thousands of developers seems to have had this problem (and I've even had it myself previously) I've never heard of a situation where none of the standard solutions actually works.
What could I have missed?
EDIT
I've been into regedit and I tried again to find my service, but this time I exported the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ section and searched it. I can find my service in the dump under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MyService
But then I go there in the regedit view, it's not there. Any suggestions? How did I screw that up :?
RE-EDIT
Disregard edit, the service only shows in regedit while the install i showing the error message, but that's event weirder, the service is installed, then breaks and rollbacks...
As a temporary solution, you can change the name of the service slightly ( e.g. add or remove one or two chars from the service_name) but keep the display_name the same.
I would suggest looking and Sysinternals Process Monitor activity and going backwards trying to find what happened before the error was reported. You might be able to see that for example a certain reg key was accessed.
I had a similar issue to this (the service was in stopped state and then deleted by an overzealous disk space tidier) and to solve it I copied my new service to the same location as marked in the "Path to Executable" box, and then started the service.
No issues so far.
I am creating an automation solution for Word (2007). Sometimes I have to kill the Word process. Next time word is launched a tab/window appears suggesting to recover an unsaved document. I would like to either disable this or have my application close this window.
I have no idea where the entry point to this tab/window is.
EDIT: I've found out that word calls this "Feature" Repair, not Recover. Still no idea how to avoid/bypass/disable it.
Suggestions?
This can be solved by deleting the Resiliency key in the Registry before starting Word again. This is described here:
Every other time that you open a document in Word, the document opens in recovery mode or you receive an error message
You can safely delete the entire Resilience key for local machine and the current user. Note that there are various places where the key is stored:
HKEY_CURRENT_USER\Software\Microsoft\Office\\Word\Resiliency
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\\Word\Resiliency
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Office\\Word\Resiliency
I assume you have access to the word:
http://www.ehow.com/how_6012331_disable-document-recovery-word.html
[edit]
Seems this doesn't work, you could try
Options.SaveInterval = 0
(source: http://www.tech-archive.net/Archive/Word/microsoft.public.word.customization.menustoolbars/2004-07/0195.html)
but I assume this gives the same effect as what I said first.
[/edit]
Its not possible atm. Maybe on next SP...