mstehle: The CDOs and CDONTS of Messaging Development : Outlook General

FYI: In Outlook 2010 Exchange Client Extensions Are Gone…

mstehle — Tue, 26 May 2009 16:32:00 GMT

On the Outlook team blog it was announced recently that Exchange Client Extensions (ECEs) will not work with Outlook 2010. This shouldn’t come as a big surprise, they haven’t been a primary extensibility model for Outlook since Outlook 97-98 days. However, many Outlook developers have continued to maintain their ECEs and Microsoft supports them to work on Outlook versions up to Outlook 2007. Here are the suggestions from the blog post about how to move forward…

“To redesign your solution, you should consider the following options:

Rewrite your ECE as a COM Add-in using native or managed code. Unlike ECEs, an add-in represents a strategic extensibility technology that is fully supported in Outlook 2010. Using an Outlook add-in, you can build Outlook form regions and extend the Office Fluent User Interface. For additional information, please visit the Outlook Developer Portal on MSDN.

Rewrite your ECE as a Windows service application using native code and MAPI. If you are writing a Windows service application, you must use MAPI to access Outlook items rather than the Outlook object model.”

Now THAT is a shutdown!

mstehle — Mon, 27 Oct 2008 23:36:01 GMT

Steve asked me to link to a post from Ryan Gregg detailing some changes in Outlook 2007 SP 2 Beta. Here is what Steve wrote…

Ryan posted an article about some changes we're making in Outlook 2007 SP2. The gist is we're changing Outlook's shutdown behavior to always shutdown regardless of whether there are other running applications using the Outlook Object Model. He's looking for feedback on the logic change, so be sure to send him your comments.

FYI: MSDN Protocol Docs...

mstehle — Tue, 01 Jul 2008 17:50:56 GMT

Steve posted a link to the MSDN protocol documentation. He talks about them here and here as well.

OOM.NET: Part 5 - Event Planning

mstehle — Thu, 12 Jun 2008 21:43:20 GMT

Plan For What You Can Control

One of the common scenarios in OOM programming in managed code that required calling GC.Collect() was handling events. As has been discussed earlier in this series, item references need to be released before they go out of scope. This includes items passed into event handlers. Take the ItemSend event for example...

// This leaks 'Item'
void app_ItemSend(object Item, ref bool Cancel)
{
    
}

// This does not leak...
void app_ItemSend(object Item, ref bool Cancel)
{
    try
    {

    }
    finally
    {
        System.Runtime.InteropServices.Marshal.ReleaseComObject(Item);
    }
}

...In most cases you would expect that the caller invoking the delegate and passing 'Item' would be responsible for releasing it since that is where it was created. However, that is not the case here - 'Item' must be released within the delegate, the caller does not call ReleaseCOMObject().

Know The Symptoms

The most common symptoms of this kind of leak (especially with the ItemSend event) are scenarios involving sending meeting requests and meeting updates. If there is a leak in the ItemSend event and a meeting request or update is sent out the appointment in the calendar is ultimately leaked. The user experience goes something like this...

Organizer sends a meeting update.
Organizer makes a change to the appointment item in his/her calendar.
Outlook prompts the organizer to send a meeting update and save the changes.
Organizer attempts to send the meeting update or save and close and Outlook throws a warning/error dialog stating that the appointment has been modified elsewhere and cannot be saved.

Another common scenario is there is a leak in the NewInspector event. Typically the symptom here is that a user will open a message and close it, then try to open the message again at which time Outlook displays a dialog stating that the "Operation failed."

Get Fixes For What You Can't Control

There were some scenarios in Outlook 2003 and Outlook 2007 where - even if the OptionPagesAdd event was the only event handled - users still saw the meeting request experience described above. To make a long story short the interop assembly is generated by tblimp.exe (more information here) in such a way that if one event on an interface such as ApplicationEvents_11_Events interface then "underneath the covers" they are all handled - in the case of OptionPagesAdd that means ItemSend and ItemLoad are handled too. Because these events are not handled in the AddIn code there is no way to release the reference the items passed to them. To address this issue, the Outlook team released a fix for Outlook 2003 and Outlook 2007. Any Outlook install that is using extensive or multiple .NET AddIns should have the following fixes installed to avoid this issue...

Description of the Outlook 2007 post-Service Pack 1 hotfix package: January 28, 2008

Description of the Outlook 2003 post-Service Pack 3 hotfix package: December 13, 2007

OOM.NET: Part 3 - Back to the Basics, MSDN Must Reads

mstehle — Tue, 19 Feb 2008 00:13:00 GMT

The Outlook Developer Reference on MSDN has great information on .NET and COM interop which I would consider a prerequisite to any managed code development with Outlook Object Model. It simply isn't enough to know how to accomplish tasks with OOM or to call GC.Collect here and there - it is important to understand the whole story...

Introduction to Interoperability Between COM and .NET - This is a short and sweet run through of COM Interop and sets up a foundation for understanding where some of the issues come from in my previous posts (OOM.NET Part 1 & Part 2). Be sure to pay attention to the following quote...

"...a COM client manages an internal reference count provided by IUnknown to free a coclass, a .NET client relies on the runtime garbage collector provided by the .NET platform to free an object..."

...That is why RelaseCOMObject is so important - in the Outlook world of item in reuse we cannot rely on the runtime garbage collector provided by the .NET platform to free an object.

There is also some 101 type information about what a PIA is found in Why Use the Outlook PIA - the take away from this is, "Any number of interop assemblies can exist to describe a given COM type. As publisher of the type library, Outlook provides a Primary Interop Assembly (PIA) that contains the official description of the COM-based Outlook object model." Installing and Referencing the Outlook 2007 PIA takes the next step to show how to add the reference in Visual Studio. The list of classes and interfaces in OOM as seen by VB6 or VBA differ greatly from what is seen in a .NET project - for an explanation of that phenomenon read, Relating the Outlook PIA with the Object Model.

The MSDN documentation hits on some of the points I made in Part 1 and Part 2 of OOM.NET:

Scoping Variables Appropriately in Event Handlers

Systematically Releasing Objects

Looking forward to Part 4 of OOM.NET...

A huge area of trouble is in the handling of events and how to structure code and understand the code in the PIA to prevent item leaks. I'll be posting more information on this topic soon - in the meantime read the following two articles for some background information...

Connecting to Custom Event Handlers

Events in the Outlook PIA

OOM.NET: Part 1 - Introduction and Why Events Stop Firing...

mstehle — Fri, 07 Dec 2007 01:12:00 GMT

OOM.NET is not a special API set that was created in managed code. It is the name I've given to a series of posts I'll do about the “gotchas” of Outlook Object Model development in .NET. I've compiled some notes over time of the most common issues, how to resolve them, and why they exist. I'd love to hear back from you on other issues you face with OOM programming in .NET as well so that I can add them to this series...

With the introduction of Visual Studio Tools for Office and the maturity of .NET languages in general more and more Outlook developers are using .NET languages like C# and VB.NET. The nice thing about .NET is that it encapsulates a lot of common functionality into a framework, manages memory, provides a framework for inter-operating with COM, and allows you to quickly write applications with very little concern for how all this happens.

The bad thing about .NET is that it allows you to quickly write applications with very little concern for how all that happens...

Developers can get caught up in the ease and speed of development in .NET. They can suffer from an "It Just Works Addiction" - meaning in the bliss of swiftly writing code that just happens to compile and run it is possible to lose sight of what is making everything work. This mentality simply will not work with Outlook development; especially in .NET because there is just too much that can happen to adversely affect your application. So on with the show...

Why Events Stop Firing

Typically, the events stop firing problems come from adding an event handler from a locally scoped object or calling ReleaseCOMObject on an object which you are listening to events on. The code below will eventually stop handling the NewInspector event because inspectors is locally scoped here and when GC runs it will get cleaned up thus stopping the event to fire…

private void ThisAddIn_Startup(object sender, EventArgs e)

{

Outlook.Inspectors inspectors;

inspectors = Application.Inspectors;

inspectors.NewInspector += Inspectors_NewInspector;

}

To fix it you would need to make inspectors a module level variable and call ReleaseCOMObject within a dispose method or in this case inside ThisAddIn_Shutdown. You wouldn’t want to call ReleaseCOMObject on inspectors within ThisAddIn_Startup because it would free the underlying COM object and also cause your event to stop firing.

private Outlook.Inspectors inspectors;

private void ThisAddIn_Startup(object sender, EventArgs e)

{

inspectors = Application.Inspectors;

inspectors.NewInspector += Inspectors_NewInspector;

}

However, in Inspectors_NewInspector you *would* want to call ReleaseCOMObject on inspector once you were done with it. For example…

private void Inspectors_NewInspector(Outlook.Inspector inspector)

{

try

{

MessageBox.Show(inspector.Caption);

}

finally

{

Marshal.ReleaseComObject(inspector);

}

You wouldn’t want to call ReleaseCOMObject until you were done with that particular reference though. In this case all the work is done within the try/finally block so we can safely release when we are done. Also, it is highly recommended that you use a try/finally block to release objects in this scenario because it ensure the reference will get released even if there is an exception.

FYI: The Outlook Team has a blog

mstehle — Mon, 05 Nov 2007 22:18:00 GMT

The Outlook team has a blog now and they just put up a post about Outlook development and linked to me. So I'll return the favor! It is great to have yet another product team start blogging at MS...good stuff!

KB: New Outlook 2007 Development KB Articles...

mstehle — Mon, 08 Jan 2007 22:59:00 GMT

With new versions of the product come new KB articles, make sure to take a look at this as you begin Outlook 2007 development...

929592 Known issues with developing Office Outlook 2007 form regions
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929592

929593 The known issues with the Microsoft Office Outlook 2007 object model
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929593

Update 1-15-2007...

Here is another KB article related to Outlook 2007 development...

929591 Known issues in Office Outlook 2007 when you use custom forms that were created by using earlier versions of Outlook
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929591

Update 1-17-2007...

Here is another...

929590 Known issues with the Office Outlook 2007 development platform
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929590

FYI: Better Together: A look at how Exchange 2007 and Outlook 2007 work together...

mstehle — Mon, 04 Dec 2006 19:17:00 GMT

There is a new technet article written by Michael Khalili, an Exchange PM, which talks about some of the ways that Exchange 2007 and Outlook 2007 play together better than their older relatives did. The most exciting piece mentioned in this article for me, as an Outlook/Exchange developer, is the Calendaring piece. Of all the APIs we support it seems to me that most of our questions and bugs center around calendaring, any improvements/simplifications in this area are very welcome. Here is an excerpt from the article about prior problems with Free/Busy data...

"In the past, most calendar logic resided in Outlook. Each meeting update was treated as a separate meeting invitation, which meant the notifications could be accepted out of order. If two meeting updates were sent in quick succession, and a recipient accepted the second meeting update before the first, he might have out-of-date information on his calendar. Furthermore, accessing Outlook information from Smartphones or PDAs could lead to differing free/busy information according to the method by which users viewed the data."

...been there, done that...

"The solution was to move all calendar logic from the Outlook client to Exchange Server 2007. When a meeting request is received by the server the meeting is automatically placed on the calendar as tentative until the user chooses to accept or decline the appointment. If a time or location change to the meeting is received, the meeting will be automatically updated and the old invitation marked out of date so users will not accidentally accept it. This logic is consistent among all clients—Office Outlook, Outlook Web Access, Outlook Mobile, or another third-party client—so only the correct, most up-to-date meetings are present."

...very nice. As Outlook/Exchange developers we are dependant on the information returned from APIs (which in turn comes from the application's proprietary business logic) to present accurate information to the user in our applications. The more Exchange understands or centralizes Outlook's business logic as it relates to calendaring, the more accurate that data, and therefore our applications become...

FYI: Want to build VSTO AddIns for Office 2007? VSTO 2005 SE Download Available Now!

mstehle — Tue, 07 Nov 2006 00:06:00 GMT

VSTO 2005 SE is a free download for Visual Studio 2005 Tools for Office AND Visual Studio 2005 Professional that will allow you to build VSTO AddIns for Office 2007 applications.

Note if you installed the CTP this summer...

"VSTO “v3” CTP users: If you previously installed any of the VSTO “v3” CTPs, you need to completely remove the CTP software from your computer before you install VSTO 2005 SE. Because the CTP’s ability to uninstall itself is very limited and unreliable, we strongly recommend that you restore your system in its entirety from a backup made before any VSTO “v3” CTP software was installed. This will require you to reinstall Visual Studio as well. If VSTO 2005 SE is installed on computers where VSTO “v3” CTP software is installed, or was installed but not removed properly, you may experience various error messages and failures. (If restoring a backup of your computer is not an option, you can try to uninstall Visual Studio 2005 and all related products from your computer, and then install them again. This is not guaranteed to completely remove the CTPs, but it has been reported to be sufficient to enable VSTO 2005 SE to work.) "

FYI: KC Lemson On Viewing Internet Headers of Mail Messages...

mstehle — Fri, 27 Oct 2006 21:16:00 GMT

This post by KC Lemson provides some good sample code to view the internet headers of mail messages in Outlook but also illustrates the huge advantage the Outlook 2007 object model provides with the PropertyAccessor object. Notice the differences between the Outlook 2007 code which is done completely through OOM compared to the Outlook 2003 code which requires the use of CDO 1.21 to access properties on the message.

UPDATED: FYI: Looking for Office 2007 Training Materials??

mstehle — Tue, 24 Oct 2006 22:08:00 GMT

Look no further! In preparation for the upcoming release of Office 2007 ~~release this Friday~~ we have provided a TON of material for anyone interested in learning the new features in Office 2007.

UPDATE: Here is the latest on Office 2007's release to manufacturing...

FYI: Exchange Team Blog: Email Archiving in Exchange

mstehle — Wed, 18 Oct 2006 23:52:00 GMT

We get a lot of calls relating to custom email archiving solutions with Exchange. A lot of folks seem to set out on their own to create a solution before realizing what solutions come out of the box (see Exchange Journalling). The Exchange team blog has a new post which discusses some of the custom solution options and what problems customers run into then how things will be different or improved in Exchange 2007.

FYI: Patrick Creehan joins me blogging from the messaging developer support team!

mstehle — Fri, 29 Sep 2006 00:42:00 GMT

Patrick Creehan is the latest member of the Messaging Developer Support team to start blogging. Check out his blog as well, he has some cool stuff already.

FYI: More From Ryan Gregg, Outlook 2007 Development Q&A

mstehle — Tue, 12 Sep 2006 20:14:00 GMT

Ryan actually published this post last week but I had yet to link to it. I have been asked many of these questions regarding Outlook 2007 in my support role at Microsoft. Here are some of the questions he addresses...

"Is there a future for the Outlook view control (OVC)?

Have the form controls been improved?

Is the IDE for form script any better?

How do you envision people debugging code on forms?

Do you see people continuing to use Public folders?

Was work put into improving custom forms management/deployment?

OWA/Mobile. Design once, run everywhere is a definite necessity, will this story be improved?

Is WYSIWYG forms printing supported in Outlook 2007?

Progress and Excitement. Do you think there is a REAL commitment within the Outlook team for extensibility?"