Just to give some additional information...
In order to simply copy a message, with all the attachments, linked resources, etc. it basically required me to individually copy all the properties I wanted to be copied, iterate through all the collections of headers, attachments, LinkedResources, attachment LinkedResources, AlternateViews, etc. creating memorystreams, saving the object to a memory stream, then reseting the memory stream to the beginning, and creating a new object from the memory stream, all 1 at a time, building the new message manually from the original message. If you try writing higher level objects to a stream by saving them, you end up loosing data, because the save for the higher objects in the Aspose.Network.Mail namespace only seems to do a shallow save, instead of a deep save, so if you save a higher level object, you don't get all the data.
Here is an example of the CopyAttachment code:
protected Attachment CopyAttachment(Attachment a)
{
MemoryStream ms;
ms = new MemoryStream();
a.Save(ms);
ms.Seek(0, SeekOrigin.Begin);
Attachment na = new Attachment(ms, a.ContentType);
na.Name = a.Name;
na.NameEncoding = a.NameEncoding;
na.ContentId = a.ContentId;
na.TransferEncoding = a.TransferEncoding;
na.PreferredTextEncoding = a.PreferredTextEncoding;
return na;
}
I had to do a similar thing for all the parts of the message, in order for all the attachments and everything to come through.
I still have an issue with character encoding not coming through correctly in some cases causing certain characters which display in the orginal message to not come through correctly on the copied message, but I haven't figured that out yet.
If the Aspose library worked as expected I wouldn't have to do any of that. I should be able to do an accurate deep copy of a message with a single method call.
The shallow copy problem also extends to the following example.
While any normal user would think that if you call the method:
exchangeClient.SaveMessage(uniqueUri,messageSavePath)
It would give you the same data as:
exchangeClient.FetchMessage(uniqueUri).Save(messageSavePath)
That is anything but the case. The first method seems to work the best, and attempts to save the attachment data as well as the message data, although it still doesn't seem exactly correct. On the other hand, saving the MailMessage to a .eml file does not save any of the attachments. You get attachment names, but the contents are empty. I assume any linked resources are not saved either.
The other problem this creates is that if I want to retrieve a message, process it, and save a copy of it, as I did for my project, I had to retrieve the object from the exchange server twice. Once to fetch the MailMessage, so I could process it, and again to save the message using the ExchangeClient.SaveMessage() because while not perfect, was vastly better than the MailMessage.Save(), which seems almost useless. The doubles the number of hits on the Exchange server and increases network traffic due to having to pull the data from the server twice.
I realize that the entire email system and all the associated standards are complex, and ill conceived on many levels, which is what happens as a system evolves over time without any clear direction, however it is important as sellers of a library to help make sense of the chaos. That is why people buy a library to save them time in dealing with the complexities so they can focus on their particular problem. It therefore is extremely important that your API's not only work, but be consistant in behavior. This is especially important given the lack of any meaningfull and accurate documentation, and the fact that the obfuscated code makes it very difficult to try to figure out what the problem is, or what is going on when things do not work as expected.
The library has great potential, but there some key issues that can really cause users grief.
I have some other issues I've found as well, however I'll put in separate posts.
I'm using Aspose.Network.dll v5.0.0.0 for .NET 3.5
I'll look forward to these issues being resolved.
Thanks,
Rick