You can simply upgrade API version using NuGet Package Manager and use a free 30-days temporary license in order to evaluate it. In case you face any issues, please share complete code snippet and sample files to replicate it. We will test the scenario in our environment and address it accordingly.
Hello,
This simple sample would hang forever:
https://1drv.ms/u/s!AkLThqAden-cgk2OpxLCLqR3ifp5?e=N4FQHI (solution for VS 2022 and .NET Framework 4.7.2). The folder “packages” with Aspose.Pdf 2021.8 inside is not included as it occupies about half a gigabyte. It should be restored manually.
Note that the report would be successfully created if FontSize is changed from 13 to 12 or 14. It seems that the engine has difficulties with splitting long words. The problem seems to be not fixed in Aspose.Pdf 2022.11.
An issue as PDFNET-53172 has been logged in our issue tracking system for further investigation on this case. We will look into its details and keep you posted with the status of its correction. Please be patient and spare us some time.
We are sorry for the inconvenience.
Hello,
Here is another sample: https://1drv.ms/u/s!AkLThqAden-cgk5oisYO5bKBEucn?e=iHNZf6. It is almost the same as the previous one but reflects another issue: report generation crashes with “IndexOutOfRangeException” on a very simple string of 3 characters.
Another ticket as PDFNET-53179 has been logged in our issue tracking system for analysis against this new case. We will look into details of it too and keep you posted with the status of its correction. Please be patient and spare us some time.
We are sorry for the inconvenience.
Hello,
Here is one more sample when Aspose hangs on call to “Save”:
https://1drv.ms/u/s!AkLThqAden-cgk-LkQOKz8HCOxSn?e=Q1Igyi.
This time it is related to page break, i. e. the case when a new page is created manually. Hanging doesn’t occur when the second record is added to the same page and table as the first one, or when font size is changed from 13 to 12 or 14.
The 4th bug is here:
https://1drv.ms/u/s!AkLThqAden-cglDAnZdnxs1jYFav?e=7vB1qA.
It was reproduced on the latest available version (22.11) with the trial license for PDF.NET. On the second step of the loop, Aspose crashes on saving with “System.ObjectDisposedException: ‘Cannot access a closed Stream.’”, though a new stream is created for every step.
https://1drv.ms/u/s!AkLThqAden-cglFJv63lsyBF_1o7?e=ivVgFC - this sample illustrates memory consumption. When built and started from the command prompt, it crashes with OutOfMemoryException at steps between 60 and 70 (a screenshot: https://1drv.ms/u/s!AkLThqAden-cglKVY-mAfvrkORHO?e=jcRzbT).
Below separate tickets have been logged in our issue tracking system for further investigation.
- PDFNET-53209
- PDFNET-53210
- PDFNET-53211
We will look into their details and let you know once they are resolved. Please be patient and spare us some time.
We are sorry for the inconvenience.
Try to use the File parameter of the Image instance inside method GenerateDataTableRowWithPicture to set the file name of image, instead of use stream
Image asposeImage = new Image { FixHeight = 148, FixWidth = 128, HorizontalAlignment = align, File = PictureFilePath, Margin = cellMargin };
The issues you have found earlier (filed as PDFNET-53172) have been fixed in Aspose.PDF for .NET 23.2.
Unfortunately this is not suitable for our use cases. As our data sources are primarily disk and phone images (including compressed, encrypted, archived etc.), we do not use physical files but work with streams instead.
Would you please try with 23.2 version using streams? We have improved the API in this version. In case issue still occurs, please let us know.
The issues you have found earlier (filed as PDFNET-53209) have been fixed in Aspose.PDF for .NET 23.5.
Please specify if the issue PDFNET-53210 has been fixed. I see it closed, but it is not clear what was the reason for closing.
Please try to use the File parameter of the Image instance inside method GenerateDataTableRowWithPicture to set the file name of image, instead of use stream
Image asposeImage = new Image { FixHeight = 148, FixWidth = 128, HorizontalAlignment = align, File = **PictureFilePath**, Margin = cellMargin };
This is neither the fix, nor the workaround. We specifically asked for the stream because in our case we do not work with files and this is a critical requirement. Please reopen the task and fix the issue on streams.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): PDFNET-54709
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Instead of re-opening the ticket, we have generated a new one as shared above. We will address your concerns in this ticket and let you know as soon as this ticket is also resolved. We apologize for the inconvenience caused.