mkelly4ca

I have created a VSTO add-in that uses CDO. It's installed with Windows Installer (following the directions at http://msdn2.microsoft.com/en-us/library/bb332051.aspx). CreateObject("MAPI.Session") throws an exception "Cannot create ActiveX component". I've searched in vain for a solution, but all I can find are people suggesting that CDO isn't installed or registered, and that doesn't seem to be the case on my systems. When OutlookSpy is installed, my CDO code works perfectly. What is OutlookSpy doing to make my CDO calls work Surely I can do the same thing, and then not have to have OutlookSpy installed on my users' machines.

Thanks,

Mike.



Re: Visual Studio Tools for Office Outlook Add-in Distribution and CDO

Sue Mosher - Outlook MVP

Maybe Outlook Spy is fixing the component registration behind the scenes. In any case, given that CDO 1.21 is not supported in .NET languages, you are taking considerable risks by using it in an add-in.





Re: Visual Studio Tools for Office Outlook Add-in Distribution and CDO

mkelly4ca

Since this is an internal app that will only be used by a handful of people, I'm not too worried. What's the worst that could happen, realistically

What component registration needs to be fixed Is there a free tool that can monitor the installation of Outlook Spy and tell me what it's registering





Re: Visual Studio Tools for Office Outlook Add-in Distribution and CDO

Sue Mosher - Outlook MVP

The worst that can happen is that the add-in's CDO calls won't work.

I have no idea whether component registration is the issue at all. That was an educated guess. For information on Outlook Spy's internals, you can ask its developer and see what he'll tell you.





Re: Visual Studio Tools for Office Outlook Add-in Distribution and CDO

mkelly4ca

Maybe the better question would be, how can I extract first name, last name and SMTP address from a Microsoft.Office.Interop.Outlook.Recipient in the exchange GAB without using CDO

I'm currently doing this, basically:

FirstName = GetFieldValue(entry, MAPI.CdoPropTags.CdoPR_GIVEN_NAME)
LastName = GetFieldValue(entry, MAPI.CdoPropTags.CdoPR_SURNAME)

For Each address As String In GetFieldValue(entry, &H800F101E)
If Left(address, 5) = "SMTP:" Then
SMTPAddress = Mid(address, 6)
Exit For
End If
Next

Friend Function GetFieldValue(ByVal entry As MAPI.AddressEntry, ByVal field As Integer) As Object
Return DirectCast(entry.Fields(field), MAPI.Field).Value
End Function





Re: Visual Studio Tools for Office Outlook Add-in Distribution and CDO

Sue Mosher - Outlook MVP

Other approaches: Outlook 2007 PropertyAccessor, Redemption, MAPI33, possibly ADSI methods, or the Extended MAPI approach demonstrated by Helmut here: http://www.outlookcode.com/codedetail.aspx id=1112





Re: Visual Studio Tools for Office Outlook Add-in Distribution and CDO

mkelly4ca

I found the problem. I was running the CDO code on a separate thread using System.Threading.ThreadPool.QueueUserWorkItem. I found that I didn't get the exception when running the code on the main thread. So my solution was to rework the code to be single-threaded.

I have no idea why OutlookSpy affected my add-in.

This was in Outlook 2003 SP2 by the way. And FYI, I've also discovered that you apparently don't get the infamous CDO security dialogs if you're in a VSTO add-in. At least the code shown above doesn't generate any.