Retain RTF format with MailMessage

Hi There,

We need to replace a attachment in a MSG file. The only way I could do this is using MailMessage, As MapiMessage doesn't allow to insert the attachment from filesystem.
When the original MSG file body is of RTF format, The MailMessage is automatically converting it into HTML. Is there any way to preserve the RTF format ?

Sample code


//
// Load a RTF message.
//
string inputMsg = @"C:\MSG_RTF_WithPDF+Image+InlineImage.msg";
MailMessage mailMessage = MailMessage.Load(inputMsg);
//
// Replace the attachments.
//
mailMessage.Attachments.RemoveAt(0);
mailMessage.Attachments.Insert(0, new Attachment(@"C:\A1.pdf"));
//
// This saves the file MSG in HTML format?
//
mailMessage.Save(@"C:\output.msg", SaveOptions.DefaultMsgUnicode);


Note: Sample input and output attached.

Hi,


Thank you for writing to Aspose Support team.

This is default behavior of the MailMessage class and can not be avoided. Whenever a message of type RTF is loaded, it is converted to HTML as per the API’s implementation. Thus, the original RTF format can’t be preserved. Please feel free to write to us if you have further query related to this issue.
Hi Muhammad Waqas,

Thanks for getting back,
I am able to replace the attachment using MapiMessage and also maintain RTF format.
To achive this
- I have set the mapi properties PR_ATTACH_EXTENSION_W, PR_ATTACH_FILENAME_W, PR_ATTACH_LONG_FILENAME_W, PR_DISPLAY_NAME_W to the new filename.
e.g.
attachment.SetProperty(new MapiProperty(MapiPropertyTag.PR_ATTACH_EXTENSION_W, Encoding.Unicode.GetBytes(newExtension)));

- Replaced the attachment binary data with the new content
e.g.
attachment.BinaryData = File.ReadAllBytes(filename);

But I have problems with embedded messages (message within a message), I am unable to replace the processed message file as an attachment to a parent message file. Do you have any suggestions ?

Note: I am able to use Aspose version 5.9.0.0 to remove the message attachment and add MapiMessage as an attachment, But this will loose the position in the RTF message.

Hi,

Could you please explain to us how the position is not maintained in the message file? The following code sample removes the attachment and adds another attachment at the same place in file. If possible, please share your sample MSG file with us for our reference.

Code:

MapiMessage mapi = MapiMessage.FromFile("RTFMsgWithMsg.msg");
Console.WriteLine(mapi.BodyType);
mapi.Attachments.RemoveAt(0);
mapi.Attachments.Add("MapiCalResaved.msg", File.ReadAllBytes("MapiCalResaved.msg"));
mapi.Save("RTFMsgWithMsg-Replaced.msg");
mapi = MapiMessage.FromFile("RTFMsgWithMsg-Replaced.msg");
Console.WriteLine(mapi.BodyType);
Thank you, yes your solution did work for a simple case "one message with one message attachment".

I have more questions
1)See the attached RTFMsgWithMsg.msg, It contains one embedded message "MessagewithoutAttachment.msg" and one embedded attachment "B.bmp".
- Just with the code you have provided above, the mapi.Save() is throwing an exception "{"Item has already been added. Key in dictionary: '__attach_version1.0_#00000001' Key being added: '__attach_version1.0_#00000001'"}"

2) If I comment out RemoveAt() and just call Add() i.e.
// mapi.Attachments.RemoveAt(0)
mapi.Attachments.Add("MapiCalResaved.msg", File.ReadAllBytes("MapiCalResaved.msg"))
- The result "RTFMsgWithMsg-Replaced.msg" has "MapiCalResaved.msg" at the original position of "MsgWithoutAttachment.msg" i.e. the text "Some text before message" is above "MapiCalResaved.msg"
- Embedded attachment "A.bmp" is pushed below the signature text

3) How can we insert the file attachment at a specific index ? the insert method accepts only MapiAttachment and not bytes or filename.
To workaround this
- I construct a temporary MapiMessage and add the attachment.
- Then use that MapiAttachment object to insert into the actual message
e.g. actualMapiMessage.Attachments.Insert(0, temporaryMapiMessage.Attachments[0]);
Is this the only solution ?
Reposting same message as there was "unexpected error" message.

---
Thank you, yes your solution did work for a simple case "one message with one message attachment".

I have more questions
1)See the attached RTFMsgWithMsg.msg, It contains one embedded message "MessagewithoutAttachment.msg" and one embedded attachment "B.bmp".
- Just with the code you have provided above, the mapi.Save() is throwing an exception "{"Item has already been added. Key in dictionary: '__attach_version1.0_#00000001' Key being added: '__attach_version1.0_#00000001'"}"

2) If I comment out RemoveAt() and just call Add() i.e.
// mapi.Attachments.RemoveAt(0)
mapi.Attachments.Add("MapiCalResaved.msg", File.ReadAllBytes("MapiCalResaved.msg"))
- The result "RTFMsgWithMsg-Replaced.msg" has "MapiCalResaved.msg" at the original position of "MsgWithoutAttachment.msg" i.e. the text "Some text before message" is above "MapiCalResaved.msg"
- Embedded attachment "A.bmp" is pushed below the signature text

3) How can we insert the file attachment at a specific index ? the insert method accepts only MapiAttachment and not bytes or filename.
To workaround this
- I construct a temporary MapiMessage and add the attachment.
- Then use that MapiAttachment object to insert into the actual message
e.g. actualMapiMessage.Attachments.Insert(0, temporaryMapiMessage.Attachments[0]);
Is this the only solution ?

Hi,


1. We have tested the same at our end and were able to reproduce the issue at our end. It has been logged as EMAILNET-35036 in our issue tracking system for further investigation by our product team. We shall update you here once there is some information available about this problem.

2. We have tested this issue as well and the position is changed. However, if we do the same using MS Outlook, the new attachment is also added at the end of the message body after the signature. So, other than the position, the behavior of the API is same.

3. There is no such method available to insert the attachment at a specific index. The behavior is same as that of step above and seems to be expected output other than the position of the attachment.

The issues you have found earlier (filed as EMAILNET-35036) have been fixed in this update.


This message was posted using Notification2Forum from Downloads module by Aspose Notifier.
(1)