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
Related
I followed all of the steps here to try and load in a basic excel custom function add in. Everything in the setup stages seems to work, however, when I run 'npm run start:desktop' and Excel opens, there is an error on the side that says:
ADD-IN ERROR This add-in is no longer available: add-ins inserted during development are only available during debugging from Visual Studio. Please open your project in Visual Studio and re-run your application, or deploy your application into a valid catalog and re-insert
I get this error whether I run the project from the command line, VS Code, or Visual Studio. I am on Windows 10 using Excel 2016.
Here is a photo of the Excel page with the error:
Even though question is old one and I think OP must have resolved this problem. However I am currently facing the exact same problem so often. Below are my work arounds which are working for me, it might help others.
Clear Excel Cache in Trust center settings and run application again.
Many times options 1 does not work, then I make change in Add-in menifest to make it invalid and then undo these changes and run application.
If both options fails, then restart Visual Studio.
If all other options fails, restart my system, and then this issue is resolved.
If still problem persists, Uninstall Office workload from Visual studio, install it again and check. If problem persists then repair office.
These 5 workarounds have so far worked for me.
Clearing the Office cache sometimes fixes this: Clear the cache
UPDATE 1/23/2021:
There is now a troubleshooting section for this error: Getting error "This add-in is no longer available".
The Add-in was working fine under Internet Explorer 11 and I was able to reliably observe and debug its behavior in Visual Studio 2017. Recently after some automatic Windows/Office updates, I noticed that iexplore.exe was not being used as the host browser. This resulted
in not being able to know what process to attach to for debugging.
At this point, out of desperation I executed the following steps to to set JS_DEBUG:
In a windows power shell window executed command
Get-AppxPackage Microsoft.Win32WebViewHost
The command listed the package information including full package name for Win32WebViewHost , which was
Microsoft.Win32WebViewHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
I then executed the following
setx JS_DEBUG Microsoft.Win32WebViewHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
After some poking I noticed that WWAHost.exe was being used as the browser. Now the add-in is deploying fine but is encountering strange errors.
Is it possible that the above steps resulted in WWAHost.exe as the browser being used to host the add-in. So wondering how to undo the above setting so Internet Explorer 11 is the browser used by Excel to host the add-in.
You cannot control which browser is used to host the add-in. Office decides that. For details how this is determined, see the article: Browsers used by Office Add-ins.
In the process of switching my folks over to TFS 2012, I was evaluating the team project reports I moved over. When I double-clicked on a report to open it, instead of seeing it in a tab within my VS 2012 IDE, it opens in a separate web browser window.
This behavior exhibits in migrated team projects (from 2010 to 2012), as well as newly created team projects. I'm inclined to think it's a configuration issue missed on my part, but I can't seem to nail it down.
[Migration details: upgrade performed by detaching 2010 collection, reattaching to running instance of TFS2012 on new hardware. ReportServer database was moved separately. Hardware is all WinSrv2008R2, SQL2012 Standard.]
UPDATE: altered title as this is happening to any/all settings and controls, as well, for any given team project (Security, Group Membership, Work Item Areas, etc). Anything that is URL-based. So, at least it's misbehaving consistently.
If I'm understanding you correctly, this is the expected behavior for TFS 2012. All of the controls you mentioned are part of Web Access and should be viewed/altered in a browser and not VS.
I will try to make an Excel dll add-in. But I have started with the example called 'generic' in the SDK (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23242), compiled it and tried to load it in Excel. But nothing happens. If I start Excel with VS2010 debugger it doesn't even shows that Excel loads the dll. None of the addin functionality is available, and if I set breakpoints in the dll and then start Excel as debug target, no breakpoint is ever hit. Actually, they remain with the "empty-circle", meaning that to the knowledge of the debugger the dll has not been loaded.
I have carefully checked the security settings, and there is nothing that could inhibit the addin functionality there.
Any ideas?
I'm working with Excel 2010.
Definitely sounds like security settings to me. Maybe you should see if http://xll.codeplex.com works for you.
I am supporting a legacy application that was written in Access 2003 using VBA. We are updating our systems to Office 2010, with the exception of Access, which will remain the 2003 version. (This is due to several factors pertaining to other groups in my organization.)
We use Access as a front end for running reports out of MS SQL and Sybase databases. Some of these reports open in Excel. During testing, running reports that write to an Excel workbook causes the Access application to crash and exit without a warning message - the application simply disappears from the screen.
I'm not sure what the cause of this is or where I should start looking for answers. Has anybody dealt with a similar situation?
I saved and recompiled the application on the development machine that had Office 2010 installed, and thereafter the application worked correctly with Office 2010 (of course, it no longer works on machines only having Office 2003.) This was, of course, after checking the references were correct. Without any intervention, the reference to Office was for 2010.
After testing with early versus late binding, it would appear the best answer to this issue is to use late binding.
Make sure you are writing to Excel in Excel compatibility mode (.xls).