Aspose components use the .NET MemoryStream


Hi Kashif,

If we were to use the aspose for java components instead of aspose for .NET would it have the same issues with OutOfMemory exceptions? The behaviour would depend on how you have authored the java components - whether (1) you write everything in .NET and then do some conversion of the .NET sources to get the java, or whether (2) your .NET and java sources are independent, with their behaviour kept in sync by human programmers.

If case (1) applies and the aspose for java implementation contains a direct translation of the .NET MemoryStream class then there’s no point us investigating further as we know it will fail exactly the same as the aspose for .NET implementation.

But if case (2) applies then (as long as you use a different algorithm to the .NET MemoryStream!) then an OutOfMemory is less likely.

In the light of these two cases, please advise whether using aspose for java instead of .NET would be a useful line of investigation for us.


Hi Brian,

Our Java APIs are auto-ported from th e.NET equivalent version of the API and, hence, the issue is expected to arise in Java version of the API as well.

From our discussions with our Product team, work is in progress on this issue irrespective of the support level. It is just that the complexity involved requires more time to investigate the problem further in detail and fix it. We’ll update you here as soon as there are some further updates available in this regard.


Hi Brian,

We have worked over this and would like to share our findings with you. After replacing MemoryStream on MemoryTributary, we get some benefit in loaded instanecs of message (approximately 20%) but reduces performance two times due to the allocation and composite arrays. We can implement the feature as loading a message this way by choise but we have no intention to compromise on API performance. Even though we fix the issue, it doesn’t guarantee complete fixing of this problem due to other issues as mentioned in sec p.1 here: which can’t be fixed for 32-bit system.


Thanks for the update Kashif. I do have several questions arising from this:

  1. When you say we get some benefit in loaded instanecs of message (approximately 20%) I have no idea what this means. Can you explain?
  2. Again when you say reduces performance two times I don't know what this means.
  3. You say We can implement the feature as loading a message this way by choise but I think you've missed the point that this is not email-specific behaviour. The error can occur anywhere any aspose component constructs a MemoryStream.
  4. In the prior point you said We can implement the feature. Does this actually mean you could implement the feature but haven't yet?
  5. You say we have no intention to compromise on API performance which is a commendable goal - however I'm certain if users had to choose between {code that throws an exception, stopping them from working entirely} and {code that runs slower under high load conditions} they'll choose the latter. Performance should degrade gracefully and gradually as the system load increases - not suddenly and unexpectedly fail.
  6. You say Even though we fix the issue does this mean you have fixed the issue? Or do you mean Even if we were to fix the issue…?
  7. I've pointed out before this does not just happen on 32-bit OS. I've reported it on 64-bit OS too. The point is, when .NET is built to target AnyCPU it can still run as a 32-bit process on a 64-bit OS. And if we use aspose components running in-process within an Office addin, then it will run as a 32-bit process.

I'm relieved that you've started looking at this issue, but I do think your code review needs to look much wider than email alone. And I'm still unclear about what changes, if any, are eventually going to be made to released binaries. Or is this still at the discussion and review stage?

How do you suggest we move on from here?


Hi Brian,

1. Refer to point 7 below.

2. In terms of performance, the API will become slower.

3. With respect to other products, Aspose.Words has already mentioned the update with you and they will follow it up with you along the time.

4. We have done some initial tests and the feedback was shared after these tests.

5. That is why we have requested your feedback in this regard.

6. That means the implementation decission has not been finalized yet in light of the results we have achieved for Aspose.Email API.

7. We understand that but you can see the limitations in the link above where we’ll be helpless.

For Aspose.Email, our team is still at the discussion and review stage and incorporation of this new memory stream is not yet finalized. We’ll update you here once there is some more information available in this regard.


Having the same issue with Aspose.PDF and memorystream… No solution provided either.


Hi Yale,

We are sorry for the inconvenience. Please note issues vary from document to document. We will appreciate it if you please share your sample code and input/output documents along with issue details. We will look into the issue and will guide you accordingly.

Best Regards,


Hi Brian,

We have investigated the issue and now can provide you hotfix to resolve this issue. Could you please inform if you need a hotfix for the issue logged under Id EMAILNET-35246?


Hi Kashif,

I would be interested in a hotfix - but before that, would you tell me what the changes are in the hotfix? Are you now using a different implementation of MemoryStream? Or have you avoided out-of-memory exceptions using some other technique?


Hi Brian,

We’ll share the details here with you as are received from our Product team.



In hotfix version, we are using RecyclableMemoryStream instead of standard .NET MemoryStream. Please see this article for further information in this regard.


Please tell me how I can get hold of the hotfix for evaluation.



We’ve forwarded the confirmation for a hotfix version to our Product team and will share it here with you as soon as it is available.


Is there any news on the hotfix? I’m keen to try it out.



We are very sorry for the inconvenience caused to you. The hotfix version got a little delayed due to the release of the revamped version of the API. It will be available for download by the end of this week. We’ll update you here as soon as it is available for download.



Please download the hotfix version from this link. Please note that the target .NET framework of application must be 4.0 or higher. Also, the hotfix uses Microsoft.IO.RecyclableMemoryStream.1.2.1 for .NET 4.0 that must be installed from Nuget. Please let us know your feedback once you test it at your end.


Hi Kashif,

Thanks for making the email hotfix available.

I'd like to know the claims you're making for the hotfix. What behaviour have you changed? I'd like to focus my testing on the new behaviour - it's pointless me testing behaviour that hasn't changed.

I also wondered why you'd chosen RecyclableMemoryStream over any other implementation, or even writing your own?

Also where should I place the RecyclableMemoryStream dll? In the same folder as the Aspose.Email.dll? Or in the GAC? Or somewhere else?



1. We have improved the working with large files at loading of MailMessage. We are positive that these changes in many cases will avoid the OutOfMemoryException for such large files.

2. Our product team tested several implementations, but the code with RecyclableMemoryStream showed the best result and that is the reason for choosing this in our implementation.

3. You project must have reference to Microsoft.IO.RecyclableMemoryStream.1.2.1 for .NET 4.0. Rest, you can place the dll anywhere for referencing.


Hi, we got out of memory exception recently as well. Do you consider to move this hotfix to release, or it’s just a fix. As this hotfix’s version is still 16.12, but the latest version is 17.4. or is the release version able to have better performance to handle the large message and attachments?



Could you please share if you got the OutOfMemory issue with the hotfix we provided or any other version? The hotfix version was provided to get your feedback. It is still based on the old namespace of the API whereas the latest versions of the API i.e. 17.3.0 onwards are based on improved namespace structure of the API. Please share your feedback with us about the usage of the hotfix version so that we can further discuss it with our Product team.