HOWTO: Aspose.PDF for .Net direct-to-file mode with any Stream

Aspose.PDF Product Family
1

Dear Aspose.PDF for .NET team,


Please track the length of direct-to-file output instead of using Stream.Length. Also, please do not cast the stream passed into the Pdf(Stream) constructor as a FileStream later on, which I believe to be the cause of the following exception (version 4.1.1.0):

System.ArgumentNullException was unhandled by user code
Message=“Value cannot be null.\r\nParameter name: output”
Source=“mscorlib”
ParamName=“output”
StackTrace:
at System.IO.BinaryWriter…ctor(Stream output, Encoding encoding)
at System.IO.BinaryWriter…ctor(Stream output)
at Aspose.Pdf.Document.۔.ۛ(Stream ۝)
at Aspose.Pdf.Xml.ྒྷ.ྔ(Pdf Ә)
at Aspose.Pdf.Sections.Add(Section section)
at Aspose.Pdf.Xml.ᘴ.ᘵ(Pdf ᅄ, XmlTextReader ඿)
at Aspose.Pdf.Xml.᪪.᧻(᧵ ൸, XmlTextReader ඿)
at Aspose.Pdf.Xml.᧵.᧿(XmlTextReader ᨀ)
at Aspose.Pdf.Xml.᧵.᧾(XmlDocument ᅄ, XslTransform ᧽)
at Aspose.Pdf.Xml.᧵.᧻(Pdf ᧼, XmlDocument ᅄ, XslTransform ᧽)
at Aspose.Pdf.Pdf.BindXML(Stream xmlStream, Stream xslStream)
…

Until these changes are made, developers interested in direct-to-stream mode can try something like the following shim:

// Hide HttpResponse.OutputStream from Aspose PDF.NET v4.1.1 direct-to-file mode (MIT License)
public class HideStreamAsFileStreamForAsposePDFDirectMode : System.IO.FileStream
{
// TODO: better way to pacify FileStream constructor?
private static string FilenameRequiredForParentFileStream = System.Reflection.Assembly.GetExecutingAssembly().Location;
private System.IO.Stream stream;
private long countBytesWrittenForAsposePDFDirectMode;

public HideStreamAsFileStreamForAsposePDFDirectMode(System.IO.Stream streamToHide)
: base(FilenameRequiredForParentFileStream, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.ReadWrite)
{
base.Close();
this.stream = streamToHide;
}

public override void Close() { this.stream.Close(); }
public override bool CanWrite { get { return this.stream.CanWrite; } }
public override long Length { get { return this.countBytesWrittenForAsposePDFDirectMode; } }
public override void Write(byte[] buffer, int offset, int count)
{
this.stream.Write(buffer, offset, count);
this.countBytesWrittenForAsposePDFDirectMode += count;
}
}

Sample Usage:

var Pdf = new Pdf(new HideStreamAsFileStreamForAsposePDFDirectMode(Response.OutputStream));

Thanks!

~JS

2

Hello Jed,

Sorry for replying you late.

We're looking into the details of this problem and will get back to you with the status of correction, shortly.

We apologize for your inconvenience.

3

This post was not necessarily in regards to a problem; my intention was to explain how Aspose.PDF for .NET users can use direct-to-file mode with any .NET Stream type. (I have specifically tested this HideStreamAsFileStreamForAsposePDFDirectMode class with Aspose.PDF for .NET v4.1.1 and the ASP.NET HttpResponse.OutputStream.)


In the beginning of the post I explain the two adjustments required for future Aspose.PDF for .NET versions to be able to support direct-to-stream with any .NET Stream (not just FileStream) without a shim class.

~JS

4

Hello Jed,

Thanks for sharing the information.

We've already logged the requirement of using MemoryStream object with Aspose.Pdf for .NET, when creating PDF document in Direct-to-File mode. The issue is logged as PDFNET-12951 in our issue tracking system. Once the feature is supported, we would be pleased to update you with the status of correction.

Your patience and cooperation is greatly appreciated in this regard.

5

The issues you have found earlier (filed as 12951) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.
(3)