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?
Related
We currently have a team that uses an Outlook Add-In (call it Add-In A) that we developed internally that attaches to the Send event and, if some rules around the From address and Subject are met, a form is displayed, data is written to a SQL database and the email is sent. This works fine.
We've also just had a company-wide rollout of a third party Outlook Add-In (call it Add-In B) that checks any emails you send to see if they're going to an external address and if so asks if you're sure you want to send. Again, this works fine.
The problem is when these two are combined. While there's no technical problem where they conflict or anything like that, there is a potential logical error where you could try and send an email, Add-In A kicks in, the user completes the form and data gets written to the database. Then Add-In B kicks in, warns the user they're sending an external email, they decide against sending and the whole process is cancelled. However, the database has been updated to say it was sent, which is incorrect.
I'm struggling to think of any way to prevent this - if we could force Add-In B to fire before Add-In A then that would solve the issues, but I'm pretty sure that you can't specify the order that each Add-In should fire or be enabled, and we have no control over the code for Add-In B as it's a third party product.
Any suggestions to prevent this from being a possible outcome?
First of all, you may handle the ItemAdd event of the Sent Items folder in Outlook to be sure that a mail item (Outlook Item) was sent for sure. Be aware, the Sent Items folder can be specified an runtime using the SaveSentMessageFolder property of the MailItem class.
Also you may choose the ProgID name for the add-in to make sure that your add-in is loaded after others. The events are fired in the reverse order. But all of these facts are not documented and can be changed at any time. Nobody can guarantee that it work stable all the time.
I developed an application using C# Outlook ribbon Addins. Its working fine, but its keep disabling when outlook start.
Is your add-in listed in the Disabled Items list?
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.
Also 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. See Performance criteria for keeping add-ins enabled.
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
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.
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.