Redemption attachement filename escaping differs from Outlook

0
votes

We are trying to save attachments selected by the user using Redemption but stumbled on filename escaping inconsistency between VSTO and Redemption. What we do:

  1. By attachment context menu save attachmentSelection[1] index and filename to the db and also message entryId and storeId.
  2. After a while (maybe even after Outlook restart) we need to save this attachment to file. To do this, we get that e-mail with Redemption by id, get attachment by index (rdoMail.Attachments[index]) and also ensure that filename match, since according to this: https://docs.microsoft.com/en-us/dotnet/api/microsoft.office.interop.outlook.attachment.index?view=outlook-pia#Microsoft_Office_Interop_Outlook_Attachment_Index index property is valid only during the current session. Although it is not clear what they mean. Can it change if the e-mail is saved and sent already? Or received?
  3. For reply e-mail VSTO Attachment.Filename is "RE Test.msg" and RDOAttachment.Filename is "RE_ Test.msg" (this is msg attachment of another e-mail).

So, the questions are:

  1. why it is different and is it documented somewhere? Can we, for example, replace _ with string.Empty for Redemption filenames or there can be other cases?
  2. Or maybe there is a way to get RDOAttachment from Outlook Attachment object somehow?
  3. Can we rely on that Redemption attachment index is the same as Outlook one?
1
outlookvstooutlook-redemption

1 Answers

1
votes

  1. Sounds like you are dealing with an embedded message attachment - unlike regular by-value attachments that expose the PR_ATTACH_LONG_FILENAME MAPI property, there is no intrinsic file name property for the embedded attachments. Both OOM and Redemption generate that property from the the embedded message subject, whcih you cam access through RDOAttachment.EmbeddedMsg.Subject. OOM does not expose embedded message attachments at all.

  2. Yes, use RDOSession.GetRDOObjectFromOUtlookObject method

  3. The index usually does not change, but it might. MAPI itself uses PR_ATTACH_NUM to open the attachment using IMessage::OpenAttach, but it can be different based on how the message was opened - a fake IMessage returned from MailItem.MAPIOBJECT can have a different value of PR_ATTACH_NUM from the native message returned by the store provider.