Последовательное получение адресов электронной почты «От» во всех версиях Outlook

Question

Я работаю в автономном настольном приложении c #, которое отправляет документы, а затем импортирует их из Outlook, когда они отправляются обратно. Приложение забирает электронные письма из указанной папки, обрабатывает их, а затем сохраняет имя отправителя и другие данные в базе данных.

Это хорошо работает для Outlook 2003 и 2007, которые имеют свойство SenderEmailAddress. Однако Outlook 2000 и XP не имеют этого свойства и не будут последовательно возвращать name@domain.com. Я предоставляю поддержку для этих версий.

Я обнаружил, что библиотека под названием Outlook Redemption решит эту проблему, но я занимаюсь разработкой в ​​.net и очень хочу избежать записи в реестры клиентов. Я также нашел MAPI33 оберткой .Net вокруг MAPI, но на форумах неясно, поддерживается ли она по-прежнему.

Буду признателен за любые указания относительно альтернативы .Net для Redemption dll или подхода к возможности постоянного получения адреса электронной почты в версиях Outlook.

Большое спасибо

AbsFabs

Эпилог: Я закончил тем, что использовал решение из этой статьи http://support.microsoft.com/kb/324530. Это включало в себя создание ответа и затем извлечение ответа на адрес созданного почтового элемента. Он хорошо работал для электронных писем, отправленных через Интернет, и в настоящее время проходит тестирование Exchange Server.

Также нашел это в моих путешествиях http://anoriginalidea.wordpress.com/2008/01/11/getting-the-smtp-email-address-of-an-exchange-sender-of-a-mailitem-from-outlook-in-vbnet-vsto/ похоже, что это касание. Это может включать мой план B, если моя существующая реализация не выдерживает испытания.

Спасибо за ваш отзыв

AbsFabs

Я в конечном итоге завелась с помощью Искупления. Отличный инструмент для работы. Моя проблема была с необходимостью зарегистрировать DLL, когда мое приложение было установлено. Так как мое приложение написано в dotnet, ему не нужно ничего регистрировать. Я был в состоянии обойти проблему регистрации DLL с помощью COM без регистрации.

Большое спасибо за ваше вдохновение.

Answer 1

Имея подобную проблему на работе, мы решили пойти по пути netMAPI, что вызвало некоторые проблемы.

Основная проблема заключается в том, что MAPI управляет собственной памятью, как и .NET, что означает, что иногда (у нас около 300 человек используют наше собственное программное обеспечение), это может привести к сбою нашего приложения, генерирующему Windows «сообщение об ошибке» диалог, а не наш собственный диалог отслеживания ошибок. Это было вызвано перезаписью кучи памяти друг друга.

Поскольку мы должны использовать сервер обмена, мы провели некоторое исследование и обнаружили, что если вы напишите код MAPI в приложении VB6, у него будет свое собственное пространство памяти, и, следовательно, не будет перезаписываться куча .NET.

Это довольно долгий путь, но до сих пор у нас не было проблем, и каждый день сотни (если не тысячи) писем отправляются нашими сотрудниками.

Answer 2

Я использую решение Outlook Redemption в производственном коде C #. Работает красиво. С его помощью вы можете получить SenderID почтового сообщения (IRDOMail), а оттуда - метод GetAddressEntryFromID () объекта IRDOSession.

Answer 3

Выкуп можно использовать без установки в реестре - вы можете использовать RedemptionLoader в C #, VB.Net, Delphi и C ++.

//tell the app where the 32 and 64 bit dlls are located
//by default, they are assumed to be in the same folder as the current assembly and be named 
//Redemption.dll and Redemption64.dll.  
//In that case, you do not need to set the two properties below
RedemptionLoader.DllLocation64Bit = @"c:\SourceCode\Redemption\redemption64.dll";
RedemptionLoader.DllLocation32Bit = @"c:\SourceCode\Redemption\redemption.dll";
//Create a Redemption object and use it
RDOSession session =  RedemptionLoader.new_RDOSession();
session.Logon(Missing.Value, Missing.Value,  Missing.Value, Missing.Value, Missing.Value,  Missing.Value);

Answer 4

Хорошая новость заключается в том, что вы на правильном пути, отслеживая нужные интерфейсы. Плохая новость заключается в том, что 2000 и XP очень плохо поддерживаются в .NET, потому что они были раньше .NET, и только с 2003 года они стали настоящей попыткой заставить COM работать в .NET.

Ваше решение для этих версий 2000 и XP будет состоять в том, чтобы вы отслеживали правильные COM-интерфейсы и оборачивали их самостоятельно. Мне приходилось делать это много раз для этих версий Outlook, и это никогда не было красиво. Так что удачи.

Answer 5

Я на самом деле никогда не использовал их, но вы можете попробовать Outlook Collaboration Data Objects (CDO). Раньше они были надстройкой, которую вы могли установить с помощью outlook, но теперь они предоставляются отдельно.