Constructive feedback

Aspose.Email Product Family
1

Hello,
Seems different Aspose products are being developed by total different teams, with no unique standards for the whole devs/teams.

There’s a critical / severe lack of consistency between Aspose controls’ properties/methods etc.

Compare these:

Email.FileFormatType.Unknown
Cells.FileFormatType.Unknown

Imaging.FileFormat.Undefined > Why Undefined instead of Unknown

Words.LoadFormat.Unknown

Zip.ArchiveInfo.ArchiveFormatInfo.Format

Zip does not have Unknown at all:

To check the unknown the worst way is choosen, Null or Nothing!

Or Mht/Mhtml is Mht in Email, while it’s Mhtml is Words/Cells:

Email.FileFormatType.Mht
Cells.FileFormatType.MHtml
Words.LoadFormat.Mhtml

Many crazy things like that…

I have to confess that Aspose Words is the best and highest quality control of the collection.

Compare release notes of Words:

or Cells etc…

With Email:

My bad luck, after a lot of time developing my app using Aspose Email and reporting 100+ bugs and critical missing features, no idea when the Email will become operational and usable for me.

5~8 minor bug fixes per month (and 1~3 features) means MIGHT be able to use it in 1~3 years, if new [preventing bugs are not added in the upcoming builds…

Wish they spent a little time on Email, like Words or Cells…

Finally, Aspose Html, does not support .Net Framework at all, a minimum of .Net Framework 4.0+ (4/ 4.5/ 408) is one of the most used development markets yet.

2

@australian.dev.nerds,

We greatly appreciate your valuable input/feedback. Rest assured, we have taken note of your concerns and are currently engaging in internal discussions across various teams to address the issues that you have raised in your post.

We will keep you updated with the measures we take regarding your mentioned issues and APIs naming uniformity.

We apologize for the inconvenience caused!

1 Like
3

Thanks for your kind response, I’ve forgot to mention one important item:

In email systems, comparing:

RFC-822 based Mime Email files (.EML)
Class MailMessage | Aspose.Email for .NET API Reference
This can have 2 different body parts: HTML and Plain Text

vs

Ole2 based MAPI message files (.MSG)
Class MapiMessage | Aspose.Email for .NET API Reference
This can have 3 different body parts: HTML and Plain Text + RTF Rich Text

MapiMessage class is OK as expected with 3 properties to get and set the 3 body parts:
.Body Plain Text
.BodyHtml
.BodyRtf

Now, let’s see how MailMessage class handles 2 body parts:
.Body
.HtmlBody
.HtmlBodyText Does not exist in help!
.GetHtmlBodyText
.SetHtmlBody

4 properties/methods to get/set Html body part while only 1 is needed, the problem?

The only .Body property which works to get/set Plain Text body part does not work as expected, what’s the expectation? To conform with ALL other email SDKs around the world!

.Body returns the plain text part which is OK, but if plain text part does not exist, it will return a string parsed version from Html body, while it must be an empty string or null if plain text part does not exist!

A developer might ask himself why we have 4 methods to get Html body part? What’s the difference and which one to use? It makes confusion as never seen before!
And worst, while so many methods for Html body part, not even 1 working property for Plain text part?!

This is the lack of consistency I mentioned before! Perhaps different developers added those over the time, with no unique logical supervision!

4

@australian.dev.nerds,

Sorry, but we’ve discussed all this with you before. And we created the EMAILNET-40936 ticket at your request, in order to address this issue further.
Also, following the discussions, we’ve provided you with code example to check whether the plain text body exists in the message or not.
FYI, the .HtmlBodyText is marked as obsolete and should be removed soon.

Thank you.

1 Like
5

Thanks, just one thing: MapiMessage body properties are nicely in alphabetical order, all 3 start with Body, do you think it’s wise to have MailMessage following the same schema? I mean .BodyHtml instead of .HtmlBody? 2 advantages: same as Mapi, and in alphabetical order, when being used come up together after each other, much more clear.

And TgzReader.GetTotalItemsCount returns the correct number of inner items, while TgzReader itself is not returning all items, you’ve got any news about its fix timeframe? :slight_smile:

6

Hello, thanks, as you mentioned calendar properties will be added to the next build, just checking if these are included?

CalendarReader.IsMultiEvents
CalendarReader.Count / EventCount

2 properties which I already suggested, and my code below:

Dim Count As Integer = 0
Dim MyCalendarReader = New CalendarReader(InputCalendar, ASPLoadSetICS)
If MyCalendarReader IsNot Nothing Then
 While MyCalendarReader.NextEvent
  Count = Count + 1
  If Count > 1 Then IsMultiEvents = True
 End While
End If
... If MyTotalCount > 1 Then IsMultiEvents = True ...
... Return Count ...
7

In the case of the MAPI, it may make sense to follow the established naming convention, where properties start with “Body” (for example, PidTagBodyHtml canonical property). Aligning with this convention can provide a consistent and familiar experience for developers already familiar with MAPI.
However, in MailMessage, we have already established its own naming conventions.

Unfortunately, we can’t give you a timeframe on TgzReader because it’s not a high priority. We’ll probably plan it for the next 6 months.

8

It will be added in an upcoming release.