Memory Usage with Aspose.Page

I. Processing PS/EPS documents.
With a simple application, iterating 1000 times over the same input file and attempt transforming it into a image, it was noticed a continuous growth of memory allocated to the process. Here is the Main

namespace Application
{
class Program
{
static void Main(string[] args)
{
EPSRender.RegisterAsposeLicenses();
for (int i = 0; i < 1000; i++)
{
EPSRender.Render(@"c:\Temp\source.eps", @"c:\Temp\destination.jpg");
Console.WriteLine($"Done {i}...");
}
Console.WriteLine($"Done!!!");
Console.ReadKey();
}

And the EPSRender code (inspired from Page Description Language Converters | .NET):

public static class EPSRender
{
public static void RegisterAsposeLicenses()
{
var license = new License();
license.SetLicense("Aspose.Total.NET.lic");
Console.WriteLine("Aspose.Page license set successfully.");
}
private static readonly ImageSaveOptions bitmapOptions = new ImageSaveOptions()
{
JpegQualityLevel = 100,
SupressErrors = true
};
public static void Render(string inputFileName, string outputFileName)
{
FileStream psStream = new FileStream(inputFileName, FileMode.Open, FileAccess.Read);
PsDocument document = new PsDocument(psStream);
ImageSaveOptions options = new ImageSaveOptions(true);
ImageDevice device = new ImageDevice();
try
{
document.Save(device, options);
}
finally
{
psStream.Close();
}
device.Dispose();
psStream.Dispose();
GC.SuppressFinalize(document);
}

As it can be seen within the code, the Dispose and garbage collection was even forced after each iteration, hoping that this is going to clear things up. However, at the end of the 1000 iterations, the memory was significantly big with no sign of releasing. This is how the snapshot looks like:
The NuGet package used for this application was Aspose.Page v.20.7.0
Question: The PsDocument class does not have the IDispose interface. Is there a different way of releasing the resources allocated by it? Or this is in fact a memory leak?

II. Upgrading to the latest Aspose.Page 20.8.0.
Using the same sample application .Net Core console application, but this time with the latest Aspose.Page library available into the NuGet repository, the compilation ends up into a bunch of errors:
After looking into the folder where the libraries are stored, the size of the dll was zero.
If the application is having the reference to version 20.7.0 restored, everything comes back to normal.
Question: Is the support for .NET Core dropped for this library or is just a deployment issue?

@MarcomUSER1

We have also noticed this issue at our side and are working on fixing it. As soon as it is fixed, we will inform you.

We need to further investigate the feasibility of implementing IDispose interface. However, could you please share your sample PS file with us with which you were testing the scenario with 1000 iterations? We will further proceed to assist you accordingly.

Thank You for getting back. I am going to attach the eps file that was showing this memory issue.
source.zip (296.0 KB)

Also note, we are having similar issues with Aspose.SVG as well. After processing about 200 SVG files, we see that not all the memory is being cleaned after processing SVG. The amount of memory being used increases gradually after processing of each SVG file

@MarcomUSER1

The issue has been fixed in latest version of the API available over NuGet Gallery. You can please upgrade to the latest version and let us know in case you face any issue.

Regarding memory releasing issue, we are checking it and will get back to you shortly.

@MarcomUSER1

Would you please share the sample code snippet and sample SVG file with us to reproduce the issue.

I am attaching zip file with 2 svg files and a word document with the code

Notes:
Here is a simple svg file (aa.svg), the transformation is fast, if you convert it in a loop for 200 times, you will get an amount of about 300MB of not disposed memory.

Also SVG_MemoryError.zip (416.3 KB)
a more complex svg (car.svg) for which the converting took a few seconds, but the amount of undisposed memory is higher on each run.

@MarcomUSER1

We are looking into both scenarios and will get back to you soon.