0

I am using MigraDoc for PDF Exports and part of the application allows the user to Embed an image (MigraDoc.DocumentObjectModel.Shapes.Image) into a Document. The images exist in the database and I am not able to upgrade to the latest MigraDoc BETA that handles FileStream images from Memory. So, my solution is to read the images from the database and store them in a 'Temporary' folder in my Images folder and MigraDoc will reference the images there. Once the PDF has rendered then I will no longer need the image and will want to get rid of it.

The PDF Document is rendered as follows:

            PdfDocumentRenderer renderer = new PdfDocumentRenderer(true, PdfSharp.Pdf.PdfFontEmbedding.Always);
            renderer.Document = this.document;
            renderer.RenderDocument();

            byte[] pdfContents = null;
            using (MemoryStream stream = new MemoryStream())
            {
                renderer.PdfDocument.Save(stream, true);
                pdfContents = stream.ToArray();
            }

            return pdfContents;

and is eventually passed as a FileContentResult.

My problem is that I do not seem to be able to get rid of the files added to the PDF document at any stage of the process... They seem to be required up to and including the point I return the FileContentResult.

Is there a setting on the PdfDocumentRenderer (or anywhere else) that will embed the images instead of relying on them being in-situ until after the FileContentResult is rendered?

CJH
  • 1,266
  • 2
  • 27
  • 61
  • Are you using the WPF build of PDFsharp? Can you use "RC1" instead of "beta"? – I liked the old Stack Overflow Mar 15 '18 at 15:53
  • This is an MVC application using MigraDoc... Not using PDFSharp – CJH Mar 18 '18 at 00:19
  • @CJH MigraDoc uses PDFsharp to create PDF files. Are you using the WPF build of PDFsharp/MigraDoc or another build (GDI+ or Core)? Old WPF builds (2014 or earlier) keep image files locked. If you have problems with an old WPF build, then try a current WPF build or the old GDI+ build. – I liked the old Stack Overflow Mar 18 '18 at 21:32
  • Sorry... understand now. Um, I am pretty sure it is the GDI+ one (as I have seen that appear in some errors as I have been debugging with images). – CJH Mar 18 '18 at 23:00

1 Answers1

0

After the call to renderer.PdfDocument.Save the image files are no longer needed.

Actually the images should no longer be needed after the call to renderer.RenderDocument();.

Some background information
The WPF build of MigraDoc uses class BitmapSource to open the image. By default this class caches the images and version 1.32 used the default options and thus the image files remain locked even after disposing the MigraDoc image.
This unwanted side effect of caching was fixed in November 2014 - since then MigraDoc disables caching when opening images using class BitmapSource.
The GDI+ build of MigraDoc never had this caching problem.
If your company insists on using a version that was published four years ago then you will miss all the improvements and bug fixes that were applied since then.
Maybe the GDI build is the solution to this locking issue (assuming this question is about image files that remain locked when they are no longer needed).

I liked the old Stack Overflow
  • 20,651
  • 8
  • 87
  • 153
  • Strange as I am attempting to delete the images after these calls and it fails... The only thing I can think of is that I am only creating the images in code and not adding them as embedded resources of the project. Could that make a difference do you think? I shall investigate! – CJH Mar 18 '18 at 00:23
  • Sorry - only just read through the 'Background information'... I have been working to very tight deadlines but have been keen to go to the latest beta version.... Not least of all because of the ability to stream images from memory... (i.e. why I am doing this in the first place). Another reason I think! – CJH Mar 18 '18 at 00:26