Urgent pls

[Guest]

I'm running this code to open a stream as pdf file:
Response.ContentType = "application/pdf";
try
{ mystream = someStream....;
byte[] myfile = mystream.ReadBytes((int)someStreamLenght);
myfile.Length.ToString();
Response.BinaryWrite(myfile);
}
finally
{
Response.Flush();
Response.Close();
mystream.Close();
}
but I run it in a 3 different machines it's telling me that the file is
corrupt or damaged.
and when running it in different machine that have the latest Acrobat 8.0
the document is opening fine!!!?
is this an issue with ASP? because I running VS 2005.

Cheers.

 

[Daniel]

Sounds like you need Acrobat 8 to make it work, i presume the file is an
acrobat 8 file or something? Try using a file that uses earlier versions of
acrobat and see what results you get. It may be that it needs acrobat or
some assemblies for it? I have nevr done what your attempting so that's the
best advice i can give.

 

[Marc Gravell]

is this an issue with ASP? because I running VS 2005.
No: your code.

OK, I doubt that your code really looks like that, as ReadBytes
doesn't normally take that signature... the problem is probably that
you are truncating the file; ReadBytes is only guaranteed to return
"some" data (or an EOF) - not "all" - and if you have undersized your
buffer you will get other problems.

The trick is to loop - something like:

public static long CopyStream(System.IO.Stream source,
System.IO.Stream destination) {
const int BUFFER_SIZE = 512;
long copied = 0;
byte[] buffer = new byte[BUFFER_SIZE];
int bytes;
while ((bytes = source.Read(buffer, 0, BUFFER_SIZE)) > 0)
{
destination.Write(buffer, 0, bytes);
copied += bytes;
}
destination.Flush(); // optional step
return copied;
}

Then call:

// capture result if you want to know the *real* length
CopyStream(someStream, Response.OutputStream);

(and close the response etc)

that do ya?

Marc

 

[Marc Gravell]

Have realised you are using BinaryReader, not (as name implied)
Stream; highlights that it is useful to see the *actual* code (i.e.
with variable declarations, and just the irrelevant bits snipped).

It is *possible* that Acrobat 8.0 is needed, but I think that it is
more likely that Acrobat 8.0 is just being more forgiving with
incorrectly terminated files or header / body size mismatches. Try
opening the file (directly off the file system, not via the web) on
one of the "broken" machines (i.e. not Acrobat 8.0). If it opens, then
it is your code. If it still doesn't open then either it needs 8.0,
else the file is genuinely knackered.

Aside: where possible, avoid big buffers; for a complex PDF with lots
of images etc this could consume buckets of memory and isn't very
scalable. The stream-based (small buffer) operations are far more
efficient. You can of course tweak BUFFER_SIZE to suit your scenario.

Marc

 

[Hans Kesting]

I'm running this code to open a stream as pdf file:

Response.ContentType = "application/pdf";
try
{ mystream = someStream....;
byte[] myfile = mystream.ReadBytes((int)someStreamLenght);
myfile.Length.ToString();
Response.BinaryWrite(myfile);
}
finally
{
Response.Flush();
Response.Close();
mystream.Close();
}
but I run it in a 3 different machines it's telling me that the file is
corrupt or damaged.
and when running it in different machine that have the latest Acrobat 8.0
the document is opening fine!!!?
is this an issue with ASP? because I running VS 2005.

Cheers.

By the way, if that PDF really lives as a file on your server, there is
also Response.WriteFile(..).

Hans Kesting