Wiz/dumb : VSTO

Trouble with Live Search Maps Add-in for Outlook

Patrick Creehan — Wed, 22 Oct 2008 16:08:27 GMT

Several million of you have downloaded the Live Search Maps Add-in for Outlook which allows integration in Outlook with maps and has some cool functionality around extending your appointment blocks to account for automatically calculated travel time among other things.

We have received a large number of support cases that are caused either directly or indirectly because of this add-in. These include hangs, crashes, and leaks. There could be any number of different reasons for those, but to name one culprit, the add-in interops with CDO 1.21, which if you are a messaging developer following the blogs of anyone on our team, you will know that this is not supported.

http://support.microsoft.com/kb/266353

Worse than that, it is distributing CDO.dll, which is also not supported. http://support.microsoft.com/kb/171440

A customer of mine reported an issue that lead us to another discovery. The add-in installs a custom form to your Personal forms registry and changes the default form for the calendar to IPM.Appointment.Location. The form it publishes is based on the LEO.oft form that it installs in your Program Files. The OFT was clearly customized from an existing item in the designer’s mailbox. The form contains a value for PR_START_DATE and PR_END_DATE set to 4/6/2006. The problem with this is that Outlook doesn’t use PR_START_DATE and PR_END_DATE, but CDO 1.21 does and OWA will set them as well. Outlook uses custom named props to keep track of dates. Exchange normally keeps these custom props and PR_START/END_DATE in sync, but only if it needs to because of a modification you did from OWA or something like that. Otherwise, the original values will stick.

If you have a CDO 1.21 application which filters based on a date, all the appointments you created with this form in your calendar will appear to be on 4/6/2006.

The long-term plan for what to do about all the problems in this add-in has not been determined at the time of writing of this blog, but it may result in the download being removed from microsoft.com. This won’t help you fix up any items that already exist in your calendar though – nor will it prevent users from using the add-in if they already have it downloaded and installed.

If you insist on continuing to use the add-in, then please at least use this updated form.

You will need to publish this form to your Personal Forms library over the original. If you uncomfortable with that, you can

Uninstall the add-in using Add/Remove Programs.
Remove the existing form from your Personal forms library,
Close Outlook and ensure no instances of Outlook.exe are running in Task Manager.
Reinstall the add-in,
Replace the LEO.oft in the Program Files folder (C:\Program Files\Live Search Maps for Outlook) with the one contained in the ZIP file linked above.
Open Outlook. (the add-in will publish your new form).

This should allow your CDO 1.21 code to execute normally on any newly created items. For existing items, you can use Outlook Object Model or CDO 1.21 (or Extended MAPI) code to loop through the appointments in your calendar and delete the PR_START_DATE and PR_END_DATE properties if they are on 4/6/2006 with a message class of IPM.Appointment.Location. Outlook should still be able to work with the appointment just fine without those properties.

Misha Shneerson : COM Interop: Handling events has side effects

Patrick Creehan — Wed, 22 Oct 2008 16:04:09 GMT

Misha, a Senior Dev on the VSTO team just posted this blog describing why handling events in managed code can be problematic. This is not news to our team, but he provides a good explanation of why it’s problematic.

Misha Shneerson : COM Interop: Handling events has side effects

If any of what he says sounds familiar, it’s because our own Matt Stehle has been talking about this for a while.

Form Region Leak in Visual Studio Tools for Office 2008 (v3) Template

Patrick Creehan — Fri, 08 Aug 2008 00:03:24 GMT

I had a case on this a few months ago, but thought more folks might run into this as they start moving to form regions. By default, if you use the VSTO template for creating a form region in Outlook, the item is leaked. This can show up in a number of different symptoms, but the one we saw was that when the item was created (then saved and closed), then modified in WebDav, then they tried to modify the item again in Outlook, the user would get the error:

"The item cannot be saved because it was changed by another user or in a another window."

Fortunately, the resolution is easy, you just need to add a call to Marshal.ReleaseComObject to the FormRegionInitializing event in the designer code.

private void FormRegion1Factory_FormRegionInitializing(object sender, Microsoft.Office.Tools.Outlook.FormRegionInitializingEventArgs e)    
{     
    Marshal.ReleaseComObject(e.OutlookItem);     
}

Stehle's finally doing his OOM series

Patrick Creehan — Fri, 07 Dec 2007 15:54:00 GMT

I've been encouraging him to blog his "Matt Stehle's Tenents of OOM Programming" for a while now, and he's finally begun with a series on some common pitfalls we see with developers using OOM in .NET. This first article is concerned with a common reason we see for events to stop firing in your VSTO add-ins.

Rock on Stehle-E-O!

HOWTO: Exposing your VSTO 2005 SE Add-In to External Code

Patrick Creehan — Fri, 10 Nov 2006 20:48:00 GMT

So with regular COM AddIns in Outlook, to expose your COM Add-In to external applications involved setting the Application.ComAddins.Item("ProgID").Object property equal to an instance of the object. Typically, in your OnConnection event handler, you'd do something like this:

Application.ComAddins.Item("PROGID").Object = Me

That allowed external code to get a reference to your COM addin class through its Object property and call public functions on your addin. With VSTO 2005 SE with Outlook 2007, we have a new (better) way of handling this scenario.

There is a new virtual method which you can override and specify ANY object to be set in that value when the add-in is created.

You do this by overriding the RequestComAddinAutomationService method in your VSTO add in. See the following MSDN article: http://msdn2.microsoft.com/en-us/library/microsoft.office.tools.addin.requestcomaddinautomationservice(VS.80).aspx

The article on MSDN actually has a good example of what you need to do. Just realize that you do have to include the attributes on your interface class to make them IDispatch and ComVisible.

VSTO add-ins and the NewInspector Event

Patrick Creehan — Fri, 07 Jul 2006 05:29:00 GMT

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. Once the last UI element is closed, then VSTO fires the _Shutdown event.

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
}