My TTS Turbo Macro Excel COM add-in was working before I uninstalled Logi Options Plus for the second time.
I tried cleaning up related registry items and reinstalling TTS Turbo Macro add-in and Logi Options Plus but it didn’t help. The load behavior value of 3 for TTS add-in was correct; load count also matches the number of times I launched MS Excel, though the add-in never loaded. To further troubleshoot, I added paths related to TTS add-in to trusted location, but to no avail. I had ran into the similar situations where TTS add-in does not load; reinstalling the OS would fix it but I’d rather not waste that much time on it again. The TTS add-in also has an Excel (non-COM) add-in. When I launch Excel, I could see it’s been loaded, but nothing appears on the ribbon like before. Is there anything else I can do to troubleshoot and fix the issue?
By default, if a VSTO Add-in attempts to manipulate the Microsoft Office user interface (UI) and fails, no error message is displayed. However, you can configure Microsoft Office applications to display messages for errors that relate to the UI. You can use these messages to help determine why a custom ribbon does not appear, or why a ribbon appears but no controls appear. See To show VSTO Add-in user interface errors for more information.
Also Microsoft Office applications can disable VSTO add-ins that behave unexpectedly. If an application does not load your VSTO add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO add-in is executing.
Soft disabling can occur when a VSTO add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing. Read more about that in the How to: Re-enable a VSTO Add-in that has been disabled article.
But I'd suggest contacting add-in developers instead.
Related
I have a c# COM Add-in developed for Outlook that was created years ago in Visual Studio 2010. It was installed on a computer using Office 2010 and works fine. We are now migrating to Office 365. I installed the Add-in and in Outlook's "File".."Options".."Add-ins" it is listed under the "Inactive Application Add-ins". When I click on the Go button under the "Manage" - "COM Add-ins", the add-in is listed but not checked. When I check it, it shows "Load Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in." The old Add-in was compiled as 32 bit and I tried to install it as that, then recompiled it as a 64 bit app and installed that but it gives me the same message. Should COM Add-ins work in Office/Outlook 365? Is there something that needs to be updated?
Should COM Add-ins work in Office/Outlook 365?
Yes, they should work correctly. There were no breaking changes.
Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again.
Is there something that needs to be updated?
You need to check add-in prerequisites, make sure that all of them were installed correctly. Then try to log all startup operations and see where an exception is thrown.
If you use VSTO, make sure that you did all the steps described in the Deploy an Office solution by using Windows Installer article.
I am developing an add-in for Word to add ribbon bar functions for our business.
I am developing the add-in in VB.Net using Windows Visual Studio 2017.
The machine is currently a stand-alone machine that is not connected to the main network.
My issue is that for some reason, the add-in seems to have set itself up in such a way that it appears to have already been installed on the system and loads, with the most updated code, if I just start Word normally.
Any development has been done in Debug mode and I have not been re-building the solution in release mode, and yet anything I change and then run/debug updates the code that the add-in appears to be run off when opening Word directly.
If I go through the options --> add-ins and disable the VTSO add-in it just gets enabled again. I don't seem to be able to separate a debug/development section and live code.
Edit from comments: I can accept that the VTSO needs to be installed and registered but having no separation of live code and development code is frustrating. This machine is used by others for other purposes and this includes using Word, and so any old code must be kept as comments that can set back as the working code should I need to leave part way through. I cannot leave anything partially written as any run the debug mode will set the code as live.
What you're experiencing is normal behavior. When you debug, VSTO registers the add-in in the Windows Registry. This is all that's required for the Office application to find and load the add-in when it starts.
If you disable the add-in in Word, it will remain disabled until you again debug the add-in in Visual Studio.
If you share the machine and want to have the add-in under development disabled for other users:
Work with separate user profiles. VSTO registers its add-ins under CurrentUser, not for all users - VSTO isn't designed to register add-ins for the entire machine. OR
Get into the habit of using Visual Studio's Build/Clean Solution functionality when you leave the machine. That unregisters the add-in (until it runs in debug mode again).
I deploy a VSTO 4 file like picture below
It work well in a lot of Computers but some computers my AddIn cannot show. I have checked on the check box in the second picture, but when I restart Word Program and open the dialog "Com Add-Ins" a gain the check box is not checked. My AddIn is not shown.
I have build my AddIn in Visual Studio 2010, output VSTO 4. I deploy into Win XP and Word 2007, .net 4 is installed at the computers.
Please tell me what is the problem, how to fix it.
I encountered this problem as you in one system with excel addin, when the user opened her excel file, the addin was not exist, in this case when I opened excel from start menu and clicking on office button and opening file from there the addin appeared
it is temporary solution, after while when she re-installed the office the problem solved.
Most probably you get an unhandled exception in the code of the add-in.
when I restart Word Program and open the dialog "Com Add-Ins" a gain the check box is not checked. My AddIn is not shown.
Microsoft Office applications can disable add-ins that behave unexpectedly. If an application does not load your add-in, the application might have hard disabled or soft disabled your add-in.
Hard disabling can occur when an add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your add-in is executing.
Soft disabling can occur when an add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable an add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again.
Read more about that in the How to: Re-enable an Add-in That Has Been Disabled article.
Also you can check out the Trust center setting in the host application.
Its a long story. I had a simple VSTO excel solution that i build in VS 2005 and Excel 2003. Few years ago we upgraded to Excel 2010 and VS2010. The VSTO solution was upgraded to .xlsm file and everything worked fine.
Recently we upgraded to Office 2013 and VS2013. (Office 2010 was uninstalled and then Office 2013 was installed). I opened the VSTO project and it forcibly upgraded the solution. I published the new version which created the setup.exe in the publish folder. I install the new customization on my dev PC and then open the .xlsm file that was installed on c:\user\abc\appdata\local... on my dev machine and everything works fine.
However, when i install setup.exe on a user machine and open the .xlsm file, even though i dont get any errors, the customizations (buttons etc) are all greyed out. Its as if it didn't even install. I banged my head with this all day today and cant figure it out. PLEASE HELP.
Thank you in advance.
Tarun,
Make sure that all the required prerequsites were installed properly. See Deploying an Office Solution by Using Windows Installer or Deploying an Office Solution by Using ClickOnce for more information.
Also I'd suggest checking the COM Addins list in the application. Is it enabled?
Microsoft Office applications can disable add-ins that behave unexpectedly. If an application does not load your add-in, the application might have hard disabled or soft disabled your add-in.
Hard disabling can occur when an add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your add-in is executing.
Soft disabling can occur when an add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable an add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again. See How to: Re-enable an Add-in That Has Been Disabled for more information.
I have an add-in for MS Word. One of my users, who is on Word 2007, reports that the add-in is not being loaded. When she checks the COM add-ins list, it says "Load Behavior" is "Unloaded; Load at Startup" (value of 2 in LoadBehavior registry entry).
Yet when she checks the add-in's registry entry, LoadBehavior is set to 3 (Loaded; Load at Startup). The add-in is also not loaded at all.
Is there some reason for the discrepancy between what Word is reporting for the add-in, and what's in the registry, and is there a way to resolve it?
I have a hunch that Word has set a LoadBehavior value somewhere else on her system after the add-in crashed, but she is remote from me, and doesn't want me to remote control her computer to check myself.
Edit: Some additional info: if the user runs a macro to check my add-in in Application.COMAddins, Connect is set to False. However, updating this to True doesn't seem to have any effect. The property will stay True as long as Word is running, but if Word is restarted then it will revert to False (and the add-in is never loaded).
More information: The add-in had been disabled due to a crash, and put in the disabled add-ins list. The user enabled the add-in from the COM add-ins drop-down list, but the load behavior was then stuck on 2, despite the registry value being 3. WinWord.exe doesn't have any compatibility settings.
Also, I provide three add-ins: one for Word, one for Excel, and one for PowerPoint. The Excel and PowerPoint add-ins work fine on the user's computer. I test the add-in myself on XP, Vista, and 7 (32 and 64 bit). The user is on Vista 32 bit.
The Word add-in was working on the user's computer for about two years, but after a crash it was disabled, and the LoadBehavior was stuck on 2. The user actually tried uninstalling and reinstalling Office, but that didn't change the behavior.
Solution
0xA3's solution wasn't complete, but on the right track. It turns out that the user had installed a new antivirus program, which was disabling the add-in (silently! ::insert rant about overzealous AV::).
I also learned a valuable lesson: to some users, "Have you installed any new software" doesn't include antivirus programs. I'll have to change that question to, "Have you installed any new software, or any antivirus programs?"
As said by Otaku, the problem seems to be that the add-in cannot be loaded and therefore is disconnected. It might due be an incomplete/corrupt installation of the add-in, a missing dependency or incorrect/missing registration of a COM component.
It's hard to give you more concrete tips, but here is a list of trouble-shooting tools that you might want to use during Word startup:
DebugView from Sysinternals, run as Administrator, with Capture Global and Capture Kernel enabled.
fuslogvw.exe to check for missing assemblies (assuming your add-in is written in .NET)
DependencyWalker to see for missing native dlls
Process Monitor to check for missing files/registry entries
Is there some reason for the discrepancy between what Word is reporting for the add-in, and what's in the registry, and is there a way to resolve it?
The reason for the discrepancy between the Registry and the actual Word setting is most likely that the current add-in state (loaded, but disconnected) is not stored in the Registry at all because the user has no sufficient permissions to change the HKLM Registry key. The LoadBehavior remains 3 in the Registry, and on next Word startup Word will try again to load and connect the add-in.
Addins can be registered in the USER hive or the LOCAL MACHINE hive, same folder in each.
HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\Your addin name
or
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Word\Addins\Your addin name
be sure to check both.
FYI : I was having similar issue with Excel AddIn. Excel "blacklisted" the add-in due to an error (which has not necessarily generated any error message). Go to: AddIns > "Disabled items" > Enable Addin resovled the issue for me.