Some versions of Outlook create an MSG file which is incorrectly parsed by the Aspose Email library. In these cases, Aspose fails to parse the display name and file extension of embedded attachments.
Outlook 2010 14.0.7106.5003 (32-bit) works, but Outlook 2010 14.0.7106.5103 (32-bit) and Outlook 2013 (x64) do not.
Could you please provide us some example files that exhibit this issue? We’ll look into these and assist you further.
PS: We do a monthly product release of Aspose.Email that has fixes available for the reported bugs and may also include new features/enhancements. I would suggest you to use the latest version of Aspose.Email in your applications so as to avoid any bugs that were encountered in earlier versions.
Thank you for sending the sample files. We are currently investigating these at our end and will share our findings with you soon here. We appreciate your patience in this regard.
I have thoroughly investigated the sample files and found that there is difference in attachments of both the messages. Following are the findings:
John Testing New email - 5 attachments.msg
If we observe the attachments of this message, each attachment contains properties PR_ATTACH_EXTENSION_W and PR_DISPLAY_NAME_W. These two properties contain values “Attachment Extension” and “Display Name” respectively that are used by Aspose.Email to display the attachment’s display name and extension.
Test with 5 actual attachments.msg
If we observe each attachment of this message, it is found that above mentioned two properties are missing there. As Aspose.Email uses these two properties to depict the “Display Name” and “Extenstion” of the attachment, so it displays null in their absence
Hope it clarifies the issue that its not bug of Aspose.Email but difference in implementation of Outlook versions which add these properties with the attachments.
Please feel free to write us back if you have any other query in this regard.
If Aspose.Email is unable to reliably determine the extension and display name for all versions of Outlook, then these properties should be removed. As it is, users of Aspose.Email who must have access to these properties must find other ways of determining them, ways that work 100% of the time; therefore, these properties are not useful. At the very least, you should specify clearly in the documentation for which versions of Outlook these properties contain valid values. It appears that for all newer versions of Outlook, these properties never contain valid values.
Because these properties do not work reliably, I consider this a bug until they are removed or properly documented.