Incorrect date being read in MapiMessage.FromFile(msgfile)

@Andre123,

Please share your sample file with us for further investigation at our end. We have tested this with sample message and latest version of API, and the dates are similar to as shown by MFCMapi. We’ll look into it and assist you accordingly.

The error is specific to any particular email message , it occurs in all instances for all our sites for all email message.
Some sites are using exchange 365 and other host there own exchange server for mail.
18.4.0 doesn’t exhibit the issue
I have attached a sample RE_ Re Finalised Template.zip (127.1 KB)
message BUT as I have said…it doesn’t relate to any particular message

@Andre123,

Please check our findings here Times.png (92.0 KB)
as we tested this issue at our end. We don’t see any difference of the API output as compared to shown by MFCMapi or Outlook Spy. You can also see the code sample in the attached screen shot. If you are trying different code sample than this, please share your runnable code with us for further investigation at our end.

Ok Thanks
As I have already mentioned and posted the code that I used to read the out look message.
It not rocket science. On examining the output via the VS debugger the dates are wrong…period
We will stay on 18.4 where the issue is not current and will cancel any further renewal subscription to Aspose when they fall due. There are many API’s available most of which cost considerable less than Aspose and the time it will take us to remove Aspose will not be great

@Andre123,

We regret the inconvenience you are facing.

The times returned by API are in UTC as observed in MFCMapi/OutlookSpy. Earlier, we were comparing the results of API output with these standard software and sharing the results with you. We compared the results of version 18.4 and 18.6 and there is a difference in these two times. We are currently investigating it as to why this change occurred during transition from 18.4 to 18.6 version and will soon update you with our findings here.

@Andre123,

We have logged this issue as EMAILNET-39051 for further investigation at our end and will try to include the fix in the upcoming version of API i.e. 18.7. We’ll update you here once there is some information or a fix version available in this regard.

The issues you have found earlier (filed as EMAILNET-39051) have been fixed in this update. This message was posted using BugNotificationTool from Downloads module by kashif.iqbal

Whilst I appreciate you finally have acknowledged that there was a bug however It will not change our mind to move away from aspose. To compound the issue you have have created a dependency in 18.7.0 to netstandard2 An install of 18.7 results in our project suddenly requiring most of the dependencies for net 4 as pre-requisites
Thank you very much for wasting my time trying to fix the code up and before you suggest we have made a mistake in the install in selecting the correct net 4 dll to use …we haven’t.

A post was split to a new topic: Email address configured with account can’t be changed

@Andre123,

Please accept our sincere apologies for your unpleasant experiences with the API due to the issues you have faced.

Regarding the requirements of dependencies, could you please share which .NET Framework you are targetting? Some dependencies are result of known issues with .NET Framework 4.7 and 4.7.1 and are fixed with .NET 4.7.2 by following these steps. A more relevant discussion here can give you further details about the dependencies involved and how to avoid them.

In any case, we are here to help you with your issues to the maximum possible extent. Issues do arise and we try to fix them at our earliest to avoid problems at our valued customer’s end as for us, customer’s satisfaction is of utmost importance. Please share your feedback with us in light of above discussions for further assistance from our end.

the issue occurs Pre-requesents.png (6.1 KB)
with 18.7.0 email .dll when it is added to a framework 4.6.1 project. It forces the project to include framework pre-requisites as per attached screen shot. This does NOT happen with 18.4.0 version or any other of the dll.s we are currently using eg word,excel,slides,pdf

18.x is being added/upgraded to the project by nu-get package manager from within the project

VS 2017 on windows 10 64

@Andre123,

Can you please share which software you used to observe these dependencies? Meanwhile we are already looking into it at our end.

@Andre123,

We have tried to reproduce this at our end by creating a simple console application and adding the API from Nuget, but were not able to observe any such dependency in Project Properties->Publish->Application Files. We need further assistance from you in reproducing the exact scenario at our end and assist you accordingly. We appreciate your cooperation in this regard.

Of course not Just like you could not find the bug with regard to time and date on an out look message. Never mind you have lost us as a customer

@Andre123,

We regret the inconvenience caused to you. The fact is that we have created a simple console application by including the DLL from Nuget and were not able to observe the problem as shown in the screenshot shared with you. That is why we requested you to share the steps with us for reproducing the problem at our end and assist you further. Our customers are our top priority and we assure you that we’ll further look into it after the listing of steps from your end. We hope you will reconsider your decision and give us a chance to serve you better.

I have already explained how the issue arises
" the issue occurs Pre-requesents.png 3 (6.1 KB)
with 18.7.0 email .dll when it is added to a framework 4.6.1 project. It forces the project to include framework pre-requisites as per attached screen shot. This does NOT happen with 18.4.0 version or any other of the dll.s we are currently using eg word,excel,slides,pdf

18.x is being added/upgraded to the project by nu-get package manager from within the project

VS 2017 on windows 10 64

A simple look at the project references shows the additional dependency included after the nuget package manager has installed the update

@Andre123,

We checked this with both 18.4 and 18.7, and found that both require System.Text.Encoding.CodePages.dll. Is that the one you wanted to mention? If so, it is required in version 18.4 as well and is no difference than the latest version 18.7. Comparison of both version 18.4 and 18.7 are also shown in here: AE 18_4 vs 18_7.png (133.5 KB)

@Andre123

We are sorry for the inconvenience.
We have looked into the issue of additional dependencies and found that it is not an Aspose.Email problem, but a well-known .NET Framework issue.

The reason is that .NET 4.7.1 is the first .NET Framework to actually contain .NET Standard 2.0 APIs. But the .NET 4.6.1, 4.6.2, 4.7 used shims. In other words, .NET Framework 4.7.1 has built-in support for .NET Standard 2.0 whereas it is not actually implemented by .NET Framework 4.6.1, 4.6.2 or 4.7. The more details can be found on .NET Standards in Microsoft docs.

It means that every time .NET Standard NuGet package is referenced, it will pull entire .NET Standard bunch of assemblies only if version of .NET Framework is lower than v4.7.1. This is done by build logic shipped in VS 2017 and the CLI which is also available as extension for VS 2015.

Applications targeting .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries. This situation occurred because the .NET Standard 2.0 specs was finalized after .NET Framework 4.6.1 was released. So, .NET Framework 4.7.1 is the first .NET Framework release after .NET Standard 2.0, enabling us to provide comprehensive .NET Standard 2.0 support.

Moreover, you may find the workaround discussed in the following thread to prevent copying additional files.

Thank you for that reply
Unfortunately today is the first time I have seen it…I have complained on a number of occasion that despite checking the box to receive notification I dont receive them.
I appreciate the effort you have gone to trouble shoot this issue
Andre

@Andre123

Thank you very much for your feedback. You are always welcome and please feel free to write back to us if you have any query in future.