Free Support Forum -

Conversation ItemClasses


I’m using your fine component to process conversations with the ItemIds property to get the messageUri’s and iterate through the lists.

var cvsCollection = _service.FindConversations(sourcefolder);
foreach (var cvs in cvsCollection)
foreach (var msgUri in cvs.ItemIds)
var message = _service.FetchMessage(msgUri);

However when i use the ItemClasses property to determine the messageclass of the item it is only filled with all the unique message classes instead of all the classes in the same order of ItemIds. Is there any way to determine the ItemId messageclass ? (instead of resorting to irregular message headers and alternateviews)

Hi Jitte,

Thank you for using Aspose.Email and sorry for a delayed response.

We are currently analyzing this issue and will soon share our findings with you in this regard. Please feel free to share with us any additional findings if there is any at your end. We will make it part of our analysis and try to assist you as soon as possible. We are sorry for the inconvenience you are facing.

I thought i had a ‘dirty’ solution for this since MapiMessage also has a class property.
It seemed to work on almost all messages.

var message = _service.FetchMessage(msgUri);
var mapimessage = MapiMessage.FromMailMessage(message);

however a message with the class “IPM.Sharing” gets the class “IPM.Note” when use this.

how do i know this ? because there was only one conversation item and it had the ItemClass “IPM.Sharing”

Hi Jitte,

We are sorry for the inconvenience you are facing.

To further investigate this issue, we need elaboration of your requirements in detail. Specifically, if your ultimate aim is to process messages, you can consider using ListMessages and FindMessages of ExchangeWebServiceClient class for this purpose.

In addition, we would request you to please arrange a test account for us on your server and put the problematic messages in one of its folder so that we can carry out our testing with it. Also, please provide us your detailed runnable sample code that we can use to reproduce the issue at our end with your test account. We will try to assist you further as soon as possible and are thankful for your cooperation in this regard…

My aim is to acquire as much information on messages as possible before processing them and adding it as headers for later use. So FindMessages/Listmessages for example won’t provide me with the conversation id and in this case the appropriate messageclass.

I’m afraid there is no testing account available and code. However you can test it by processing a “IPM.Shared” class message. Through findconversations and converting those mailmessages messages to mapimessage you will notice the class difference.

Hi Jitte,

Thanks for providing more supporting material.

We have analyzed the information and re-produced the issue where IPM.sharing message class changes to IPM.Note when message is loaded into MailMessage and converted to MapiMessage using FromMailMessage function. We have passed this information to the development team and will write back you here as soon as some feedback is received regarding this issue.

Above mentioned issue is logged in our issue tracking system as NETWORKNET-33492.

We also tried to re-produce the earlier issue mentioned in first post at this thread. We created a conversation having different types of items like IPM.Sharing, IPM.Note in random order and tried to observe the ItemClasses property for determining the MessageClass of the item but we could not observe the data as there was some exception which could not be resolved to read the INBOX and SENT ITEMS folder (having this mixed type of conversation). We are trying to re-produce this issue and need your assistance. Could you please let us know the environment detail like Exchange Type and Version info. Also it will be helpful for us if you could provide us some screen shots of the debug windows or console where these ItemClasses value is displayed along with the order of items' MessageClass for which this ItemClasses is provided.

We are thankful for your patience and cooperation in this regard.

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

This message was posted using Notification2Forum from Downloads module by aspose.notifier.