I have a VSTO Excel 2010 workbook project, and it works on all PCs except one. The additional custom user control isn't present on the workbook. I've noticed that exceptions in C# are suppressed, and I haven't found where they can be viewed. Is there such thing as Excel error log? How do I turn on all error messages?
There are (2) error log sources that office uses when errors occur. "Microsoft Office Diagnostics" and "Microsoft Office Sessions". You can try to use these to troubleshoot.
Office 2010
You can enable interface error dialogs by going to File->Options->Advanced->Developers and checking "Show Add-in user interface errors".
Office 2007
You can enable interface error dialogs by going to Tools->Options->Other->General->Advanced Options and checking "Show Add-in user interface errors".
There is also an option to enable logging (unsure of its behavior)
Related
I have a signed VSTO vb.net add-in that is loaded into Excel 2013. There are roughly 200 users, and 90% are having no issues. For the 10%, every time they boot Excel, the add-in is soft disabled.
I have stood next to them as they boot XL, go into COM Add-ins, check the add-in, and click ok. It loads (and works fine) without error. They then quit XL, boot XL again, and the add-in is again disabled. No "An add-in was causing issues dialog", no errors, just disabled -- if you click on the add-in name in COM Add-ins, there is no indication of any error in the Load Behavior (just "Load at Startup"). They re-enable and it works fine for that session.
The fact that it's a subset of people makes me believe it's a setting on their machine (perhaps in the Trust Center?) but I have yet to find a guilty setting. All users have the same version of Windows, and should be on the same update.
My Google searches have found lots of entries for add-ins that are misbehaving or where the Trust settings are very restrictive -- from what I can see, neither of those categories fit. I found one article that talked about the boot order with Analysis Toolpak, but none of the users assisted had Toolpak enabled.
Being that no error (either from the add-in or Excel) are displayed, I've been at a loss as to why it turns off (and why it's working perfectly on 90% of the machines).
I would appreciate thoughts on either what to look at in my code (even though there are no errors visible) or what settings to attempt.
For the 10%, every time they boot Excel, the add-in is soft disabled.
There can be a lot of reasons why your add-in is disabled automatically.
First of all, I'd suggest checking the list of prerequisites - whether they all were installed correctly (including the .net runtime)
Then I'd recommend enabling any logging mechanisms to look for any unexpected exceptions fired at startup.
There may be a conflict with other add-ins that are being loaded in the Office application. Disable all other Add-Ins except the one in question and retry.
The Antivirus on the system may be blocking the Add-In load. Run latest updates for the Antivirus and retry. If this doesn’t help, disable the Antivirus program completely and retry. Sometimes the Antivirus software also installs additional Office add-in, you may need to disable these additionally by running through the Antivirus control panel (Settings).
Visual Studio Tools for Office can write all errors that occur during startup to a log file or display each error in a message box. By default, these options are turned off for application-level projects. You can turn the options on by adding and setting environment variables. To display each error in a message box, set the VSTO_SUPPRESSDISPLAYALERTS variable to 0 (zero). You can suppress the messages by setting the variable to 1 (one). To write the errors to a log file, set the VSTO_LOGALERTS variable to 1 (one). Visual Studio Tools for Office creates the log file in the folder that contains the application manifest. The default name is .manifest.log. To stop logging errors, set the variable to 0 (zero).
Read more about possible pitfalls in the following articles:
Troubleshooting COM Add-In load failures
Troubleshooting Outlook Add-ins
A colleague attempts to edit an Excel spreadsheet hosted in SharePoint and gets the following error message. Why? and how to solve it?
Sorry, but to open this workbook, your computer must be running a
supported version of Microsoft Excel and a browser that supports
opening files directly from Office Web Apps.
My colleagues has the same version of Office and IE as me (Office 2010 and IE9), but when I attempt to open the same document, it works without with error message. So what is the real cause of this error message, and how to resolve it? The version of SharePoint is SharePoint 2013.
Excel addin which uses Excel API 1.2. Add-in loads fine in Excel 2016 for Windows and Excel online. Save the file from Excel online and open in Excel 2013, addin fails to load in Excel 2013 with following errors:
When loading the Addin published in Store:
APP ERROR We can't load this app because we could not connect to catalog
When sideloading the addin from trusted catalog:
This app could not be started. Close this dialog to ignore the problem or click restart to try again
I know that Excel 2013 does not support Excel API 1.2. Could you please confirm the recommended way to make sure the add-in loads in Excel 2013?
• Should we use runtime checks using isSetSupported method?
• In such cases, how to debug which line of code is failing in Excel 2013 client?
• Is there any logging that can be enabled to troubleshoot such issues in Excel client?
I tried debugging a default add-in created by VS 2015 which uses Excel 1.2 API in Excel 2013. I added the following requirements set to the Manifest:
<Requirements>
<Sets DefaultMinVersion="1.2">
<Set Name="ExcelApi" />
</Sets>
</Requirements>
The addin also fails to load in Excel (15.0.4849.1003) when debugging using VS 2015. It works fine in Excel 2016 client.
I think there are two separate issues here (though there's a good chance that they're related, and the platform is simply giving the wrong error string. If so, let's confirm, and then I can file a bug to have us fix this).
Excel 2013 does not support the "ExcelApi" requirement set, which is a 2016 addition of the host-specific APIs (same goes for "WordApi"). If you specify ExcelApi in the requirements section of the manifest, as you have above, this will always fail to load in Excel 2013 -- by design. Essentially, you're requesting an API set and marking it as "required" for something that Excel 2013 does not support -- so it has no choice but to refuse to run it.
This is where the runtime check (isSetSupported) comes in. Please see my answer at Neat ways to get environment (i.e. Office version) for more details.
I am not sure what you mean by "how to debug which line of code is failing" or troubleshooting techinques. Essentially, any call to an Office 2016 API (anything in the ExcelApi set) from 2013 will result in a runtime failure...
Hope this helps!
I have plug in CRM2011 to Outlook 2013, and when I try open CRM in Outlook I see this error
Error: Could not complete the operation due to error 800a139e
Code: 0
URL; https://xx.xxx.xxx:123/_static/_gid/GridControl.js? ver=1594428341
You have an idea of what could be the reason for the error?
We had this issue on CRM 2013 and Outlook 2010. We tracked it back to the IM presence option. If you go to the Microsoft Dynamics CRM menu, then Settings > Administration > System Setttings, you'll see an option titled "Set the IM presence option" under the general tab. Disable it and the error will disappear.
I wrote a Word 2003 add-in that uses the 2003 PIAs for early-binding. I want the same executable to support the Ribbon interface in Office 2007 and 2010, while still running in Office 2003.
Is it possible to late-bind the IRibbonExtensibility interface? If not, is there another way to dynamically differentiate between Office versions?
There's a good book on working with the ribbon UI in Office:
RibbonX: Customizing the Office 2007 Ribbon
Robert Martin, Ken Puls, Teresa Hennig
The authors and MS both suggest a trick along these lines for solving this problem:
When your add-in loads, it queries the app to find out what version it's running in.
If Office 2003, it creates a normal CommandBars 'n Buttons UI.
If Office 2007 or later, it looks for another add-in and demand-loads it. This second add-in contains just the RibbonX code to create your ribbon UI plus handlers for the button click events. The handler simply calls back to the main add-in.
With a little clever use of tags in your RibbonXML and handler, you can have a single handler work out which routine in the main add-in to call.