VSTO add-ins for Outlook are great. It's much easier than implementing the IDTExtensibility2 interface. Basically, the way it works is this (actually, Andrew Whitechapel does a much better job explaining than I will, so here you go): the AddinLoader.dll keeps a "dormant" list of add-ins that tried to load when the Outlook.exe process is started.
If there's UI (if there are any Explorers or Inspectors visible), then it fires the _Startup event. If there is no UI (like when using the Outlook View Control or ActiveSync), then it doesn't fire _Startup until the first Inspector or Explorer is made visible.
A typical operation one would usually perform (and a reason for creating an add-in in the first place) is to add some sort of UI to an Inspector or Explorer, such as a button on a command bar or a menu item. In a traditional COM add-in, the way you would do this would be to hook in to the Inspectors.NewInspector event and in the handler for that event, you'd add your UI. And that works great. It works great in VSTO also, except the first time.
Because VSTO itself is waiting until the NewInspector event fires (in scenarios where Outlook.exe is started with no UI) to fire the _Startup event on your VSTO add-in, it is too late to bind to the event yourself (it's already been fired). So what happens is that the first time an Inspector opens, your button is not added to the CommandBar, but the second time it is!
The way to get around this problem is simple. Remember that the _Startup event is fired during the NewInspector event. So in your _Startup code, just check the Inspectors.Count property and if it's greater than 0, go ahead and add your button (or whatever)! In subsequent calls to the NewInspector, your code will fire.
Here's an example:
private Microsoft.Office.Interop.Outlook.Inspectors objInspectors;private void ThisApplication_Startup(object sender, System.EventArgs e){ objInspectors = this.Inspectors; objInspectors.NewInspector += new Microsoft.Office.Interop.Outlook.InspectorsEvents_NewInspectorEventHandler(objInspectors_NewInspector); if(objInspectors.Count >= 1) AddCustomUI();}private void ThisApplication_Shutdown(object sender, System.EventArgs e) {}private void objInspectors_NewInspector(Microsoft.Office.Interop.Outlook.Inspector Inspector){ AddCustomUI();}private void AddCustomUI(){ //...do your add button thing or whatever here}
Hi Patrick, I've built a VSTO addin for Outlook 2003 (SP1) with VS2005. The add-in works fine when Outlook is opened normally but when Outlook is opened without its UI the addin is disabled (loadbehaviour=2). Thing is, it's disabled before it gets to the startup event.
Changing the LoadBehavior to 2 is not disabling your add-in, it's "disconnecting" it. There's a slight, but significant difference. Your add-in was, what we call, "Soft disabled," which means there was a problem loading your add-in which crashed your add-in. It was not a significant enough problem to crash Outlook.exe so it wasn't "hard disabled" in which case your LoadBehavior would be set to 0 and it would appear in the Disabled Items dialog box.
My guess is that you have some member level code or something that is assuming the presense of an explorer window being present. Remember that your add-in's startup event is not fired until the first explorer or inspector window is created. When outlook is loaded without UI, you have neither. If you read Andrew Whitechapel's blog I linked to above, this is explained clearly.
Try commenting out all your code so you just have an empty stubbed out frame of a VSTO add-in and add back in until you get it to break. My guess is you're assuming UI elements where there are none.
Thanks Patrick, I created a new Outlook add-in with no code in the startup event and this also gets "disconnected". Specifically the Outlook Addin gets disconnected if Outlook is automated via the "File -> Send To -> Mail Recipient" function of other Office applications (i.e. Word).
My originally addin checked the Explorer count and is also error handled. Also, with the new add-in I've experimented with MessageBoxes in different parts of the addin and these never get called, so I don't think the start up event is reached.
Ok, so using the Send To Mail Recipient link is a little different than how I understood your original question. That link actually uses a Simple MAPI call to create a new mail message (which your default happens to be Outlook). Since your MAPI form provider happens to be Outlook, an Outlook MAPI form is created. But since it wasn't Outlook that created the inspector, Outlook doesn't keep track of that inspector, so the inspector count is still 0. Outlook.exe does start and the add-in keys are enumerated and manifests are loaded, but Startup is not called until Outlook registers a UI element being created.
I created a simple VSTO addin to try to repro your issue, and mine was only soft disabled when I tried to do something outside the startup event (like in the Initiate method).
Again, my guess is that if you created a brand new VSTO add-in with no code in it, it would not get soft disabled. You can then slowly add back your code until you discover what's causing the soft disable.
Hi Patrick, I only added the messageboxes to my newly created add-in after it still got soft disabled. But before this it had no code in it.
( only the vs generated stuff, i.e. ThisAddIn_Startup, ThisAddin_Shutdown, InternalStartup and ThisAddIn.Designer.cs )
Just to confirm, on the basis of the simple add-in you created a "blank" outlook addin shouldn't be disabled in this situation and the startup event should be reached?
Could it be something else other than the code - I'm using VSTOR (SE), Outlook2003, Office 2003 SP1, Office 2003 Interop Assemblies, built with VS2005
Also:
-The default mail editor of Outlook is WordMail
-The add-in only gets disabled if Outlook isn't already opened when the Send To Mail Recipient link is hit
-I've rolled this add-in out to 30+ users and they all have the same issue (so it's not isolated to my computer)
-All other Outlook add-ins on my computer have been disabled
So, yes, I created a new VSTO 2005 (not SE but that shouldn't matter) add-in which had no code in it except messageboxes in the Startup and Shutdown events. My add-in was not soft disabled when using the Send To Mail Recipient menu item from Word.
I assume you built the add-in with VSTO 2005 SE since you have the VSTO 2005 SE Runtime.
It could absolutely be something other than the code, but that's hard to tell in this medium. If you open a support case (http://www.microsoft.com/services/microsoftservices/srv_support.mspx) with us, we could look at it.
You may want to consider taking a ProcMon trace (http://www.microsoft.com/technet/sysinternals/FileAndDisk/processmonitor.mspx) and seeing if you can see what's happening around the time it flips your LoadBehavior key.
Thanks Patrick,
I'll submit a support case for this.
I ran the ProcMon trace - it told me that the addin gets soft disabled right after it hits the dll manifest file.
Also, am I able to download your VSTO version - it'd be a good test to see whether using your version would resolve this?
Where should I log the support case?
The company I work is a member of Microsoft Premier Support
My group is called "EBA Messaging Dev". If you just go through your normal channels of opening a case. Tell the tech router that you have an add-in for Outlook that is breaking and that you spoke to an engineer from "EBA Messaging Dev" and that he said his team would support you, they can route you to the right group.
So it seems that using VSTO 2005 SE <i>does</i> matter. It may be an untested scenario to automate Outlook 2003 with VSTO 2005 SE add-ins. I do not reproduce the same behavior with VSTO 2005 (not SE) runtime.
Thanks. I was having the same problem and this is at least a good explanation.
Is this issue solved? If so what is the solution?
A request to solve this is currently posted in the VSTO forums:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1413814&SiteID=1
Thanks,
-= Maarten =-
MVP - Visual Developer - VSTO
(Re-posting here my reply to http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1413814&SiteID=1
<quote>
We (the product team) have confirmed that Outlook 2003 will be soft-disabled in headless mode and this is a bug in VSTO 2005 SE. We do have a fix which is currently is beta-tested but is not yet widely released to the public.
There are currently no workarounds for this issue. Moving to Outlook 2007 will solve the problem - but for majority of our users this is hardly feasible.
The only thing I can say at this point is that I will make an announcement on my blog (http://blogs.msdn.com/mshneer) when the update is released. Sorry for being the bearer of bad news.
</quote>
Thanks Misha. Again, to reiterate, this is ONLY a problem with VSTO 2005 SE on Outlook 2003. Using VSTO 2005 on Outlook 2003 does not have this problem. Also, using Outlook 2007 will help you avoid this issue as well.
If you are a Premier or Professional level customer experiencing this behavior, open a support case with Microsoft and ask to be directed to the "EBA Messaging Dev" team. We have several cases on this waiting for the fix, which may still be several months from release. Watch Misha's blog for more information regarding the release of that patch: http://blogs.msdn.com/mshneer
Just as an update to those of you watching this thread, the hotfix for VSTO should be released sometime in the next couple months. It will include several fixes including a new one just added where StickyNotes do not close in Outlook 2003 on the first click of the X.