We Keep Coding

Warn when Outlook add-in is not enabled

Since upgrading to Office 2013, we have some issues with an Outlook add-in disabling itself. I know that the time it takes to start can be an issue, but while we've done everything possible to speed it up, the fact it is a .net add-in means that, on our systems, we cannot get it to start faster than 1 second - the threshold beyond which Outlook disables it automatically.
We previously modified the add-in to catch all exceptions in all interfaces by default. The add-in should never pass an exception back to Outlook, but I have seen the odd occasion where Outlook's internal interface has crashed, disabling the add-in.
The add-in itself is critical to the way part of our application works - outgoing emails are intercepted and scanned, and if they meet certain criteria, uploaded to a document management system automatically. The users love it, except when it doesn't work.
I know when the add-in gets disabled, Outlook is meant to warn the user via a notification bar, but this doesn't always happen, especially in Citrix, where users don't have the requisite permissions to enable or disable add-ins.
Ideally what we would like is some way to warn a user when the add-in is not enabled. Obviously the add-in can't do this, because if it's not enabled it can't warn the user that it's not enabled. Does anyone know of another way of doing this?

Outlook 2007 Addin Startup Crash due when Outlook startup trigger via Send Mail option on Word or Excel

Having started development on a Outlook 2007 Addin at my new job, a user encountered the following error:
Object reference not set to an instance of an object during Outlook startup. After trying to track the issue via additional try catches as the initial VSTO exception message from the unsuppressed alerting was not particularly useful. I tracked the issue to the method that starts with this code:
if (newToolBar == null)
{
Office.CommandBars cmdBars = this.Application.ActiveExplorer().CommandBars;
newToolBar = cmdBars.Add("Data Team Toolbar", Office.MsoBarPosition.msoBarTop, false, true);
}
Being relatively new to VSTO, my first assumption was that ActiveExplorer().CommandBars was returning null.
After further correspondence, with my end user I was able to confirm that they had started Outlook using Excel's Send mail option from the mail menu. (not a scenario I had foreseen at all.) This seemed to collaborate my theory of the main Outlook window not being open at time, and I was able to successfully reproduce the crash consistently.
As such I added the following code
if (this.Application.ActiveExplorer() == null )
{
// If Outlook is opened via some other method ie. send on Excel or Word
// Kill Addin nicely.
this.OnShutdown();
}
However, I soon realized when I published this version under UAT (as I cannot seem to find a way to reproduce the issue within Visual Studio (Command Switches (https://support.office.com/en-sg/article/Command-line-switches-for-Microsoft-Office-Outlook-2007-92de9e0b-4f97-42a2-8e02-89c4a8294916)
Specifically "/c ipm.note" set as a debug argument seems to have no impact on debug startup process.
That this appears to close Outlook as per this link (VSTO Outlook integration - Outlook shutdown event for synchronization) and not just the Addin as I had thought.
The only solution I have thought of from a design prospective (whilst not ideal) would be a way of disabling the Addin from taking further action under this scenario but allow it to run again under normal startup conditions without user intervention. I'm thinking the logic could be included in a guard clause like so,
if (this.Application.ActiveExplorer().Caption != "Microsoft Outlook")
{
//Disabling code//
}
But I'm not sure how or if I want to implement this,
As my Addin has a lot of dependencies on the toolbar (This solution would mean a lot of very specific guard clauses to check the toolbar existed would need to be added, something I rather avoid if at all possible. Ideally I would like the Addin to be able to detect if it's run under a different approach if opened this way, and only load the Toolbar if and when the main window for Outlook is visible, I already have a background main loop as part of other requirements. So possibly something along the lines of?
if(DataTeamAddin.LoadStyle != "Normal")
{
if(OutlookMainWindowVisible == true && ToolbarIsNotLoaded == true)
{
BeginToolbarSetup();
}
else
{
//Resume Main Loop
}
}
However I'm unsure how to go about it? let alone how to test this using automated testing in MSTest, as I cannot even reproduce the issue within my VS2013 IDE?

First, Command bars were deprecated. Consider using the Fluent UI instead. You can read more about the new UI in the following series of articles in MSDN:
Customizing the 2007 Office Fluent Ribbon for Developers (Part 1 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 2 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 3 of 3)
Second, it is a known case when Outlook is run from other Office applications. Only the inspector window is available. You can subscribe to the NewInspector or InspectorActivate events to be aware that the add-in is run when the Send To command is used.

Can you run your code when everything is ready?
https://msdn.microsoft.com/en-us/library/bb147656(v=office.12).aspx

Word AddIn inactive state

I've a problem with my Word-AddIn.
When I start Word out of my application, it seems to crash with a document preview, which is also part of the application. The Word-AddIn is inactive.
I've checked the loadbeahavior in the registry...value is still 3. But when I look up the AddIn-State in Word (FILE -> OPTION -> Add-Ins), my AddIn is listed as inactive.
There is also no "DisabledItem" nor "StartUpItems" in the resiliency registry-element. Just one element in "DocumentRecovery"
How can I programly (C#) check the AddIn state?
Anyone familiar with this problem?

You can check out the COMAddIns property of the Word Application class which returns a reference to the COMAddIns collection that represents all the add-ins currently loaded in Microsoft Word.
The Connect property of the COMAddin class returns the state of the connection for the specified COMAddIn object. The Connect property returns True if the add-in is active; it returns False if the add-in is inactive. An active add-in is registered and connected; an inactive add-in is registered but not currently connected.
Be aware, 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.

Outlook just hangs while debugging VSTO Addin

I am using Visual Studio 2013 and trying to develop a C# Outlook Add-In project for Outlook 2013 client installations at my enterprise employer.
What could cause Outlook to not load completely, i.e. upon pressing F5 to Start Debugging my application via the VS IDE, the Outlook Splash Screen loads for a second, but Outlook never actually loads. Via the Task Manager, I am able to see a process for Outlook running in the background, but it never materializes into an App process.
I have done the following: in the project's Properties page, I have set Outlook.EXE local path as the Start an external program and also set the working directory.
When I run my code "Start Without Debugging", Outlook indeed does load and I can run my Outlook Add-In, but I am not able to step through my code which, of course, is invaluable.
Any ideas on what I should maybe look for?
UPDATE:
As per #Sarvesh's answer, I created a new Outlook Add-In project without setting any Properties and just one line of code as shown and still the same behavior:
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
Console.Writeline("ThisAddIn_Startup was called...");
}

In the project's Properties page, I have set Outlook's local path as
the Start an external program and also set the working directory.
Why you have set these?
If you are developing VSTO addin using templates provided by VS, you don't need to set these properties manually.
Set it back to default and then Debug.

Be aware, only one instance of Outlook can be run at the same time. So, first of all check out the list of running processes for Outlook.exe before starting your project. Only then you can start your add-in under the debugger.
Also I'd suggest disabling all other add-ins in Outlook. Outlook may disable add-ins that take a lot of time for loading. Try to reproduce the issue with a newly created empty add-in project. Set a breakppoint to the Startup event handler and run it under the debugger. Does it work?
Outlook 2013 monitors add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.
For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold.
Make sure that the add-in is always enabled.
See Performance criteria for keeping add-ins enabled for more information.

I had this same issue just recently - I resolved it by building and installing the addin in Outlook, which when launched threw an error and popped up with the exception.
In the end, the solution to my issue was to create a registry key in the 64-bit hive named EnableVSTOLocalUNC set to value 00000001 (as a dword) in the key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Vsto
Runtime Setup\v4].
Here are some other potential issues you may come across once you've installed the addin.

Add-in makes Excel crash when starting minimized

I start Excel from within my C# WinForms application using Process.Start(...) (this has a reason). I want to start it in background, without distracting the user, so I try to start it minimized or hidden. In both cases, I experience a very weird behavior:
After some seconds, Excel restores the window (even makes it visible if it's hidden) and then crashes saying: "Microsoft Office Excel has encountered a problem and needs to close. (Win XP crash message.)"
The same thing happens if I start Excel manually by double-clicking its Shortcut Icon on the Desktop and then just switch to another application window immediately, such that the Excel window loses focus during startup.
The problem appears only if any of the XLA add-in contains a UserForm. If I remove the UserForm, the problem disappears. If I remove the add-in, the problem disappears.
Any help is appreciated, as long as it is
An explanation of why this happens
Something I can change in the add-in
A way how to work around this bug (without using COM)
Not a suggestion to use COM. (See here to understand why I don't.)
Not an advice to update Excel (I can't)
Steps to reproduce:
Start Excel 2007 with an empty workbook.
Save As...
File Type: Excel 2003 Add-in (*.xla)
Location: %APPDATA%\Microsoft\Excel\XLSTART\foobar.xla
Alt + F11 (open VBA editor)
Add a UserForm to the project.
Save and Quit Excel
Start Excel and then immediately click on the Firefox or whatever tab in the taskbar to activate any window other than Excel.
Wait and watch Excel start, until it crashes.
After restarting Excel it says:
Excel experienced a serious problem with the 'foobar' add-in. If you have seen this message multiple times, you should disable this add-in and check to see if an update is available. Do you want to disable this add-in?
Details/Findings:
Excel version: 12.0.6535.5002, SP2 MSO 12.0.6425.1000
0xA3 reported in his comment he could reproduce it on 32 bit machine with Excel 12.0.6535.5002, SP2 MSO 12.0.6535.5002
I've tried with a 2007 add-in (XLAM). The same problem, except that it even crashes if it doesn't contain any UserForms.
0xA3 reported that on his 64 bit machine it worked, however Excel still pops up unexpectedly (but doesn't crash). The same holds for 2 machines of my testers so far.
This is the code I wanted to use in C# (note that the problem can be reproduced completely independent of any C# app, see above).
Process.Start(new ProcessStartInfo("excel.exe")
{ WindowStyle = ProcessWindowStyle.Minimized });