Writing System.IO.Strea m derived from a DIME attachment to a file

[Scott, Killer of all Ninjas]

It seems incredulous to me that it is so difficult to write the
contents of a memory stream to a file. I'm certain that I'm missing
something simple.

I am retrieving a memory stream from a DIME attachment:

MyDimeService svc = new MyDimeService() ;
svc.CreateDimed Image();
if (svc.ResponseSo apContext.Attac hments.Count == 1)
{
System.IO.Strea m dimeStream =
svc.ResponseSoa pContext.Attach ments[0].Stream;
SaveStreamToFil e(ref dimeStream);
}

In SaveStreamToFil e I'm simply attempting to write the stream to a
file similar to the way it's done in the MSDN help:

private void SaveStreamToFil e(ref System.IO.Strea m pStreamToSave)
{
System.IO.FileS tream fs = new
System.IO.FileS tream(@"c:\imag es\new\new.gif" ,
System.IO.FileM ode.Create);
System.IO.Binar yWriter bw = new System.IO.Binar yWriter(fs);

for (int i=0; i<=pStreamToSav e.Length; i++)
{
bw.Write(pStrea mToSave.ReadByt e());
}
bw.Close();
fs.Close();
}
Unfortunately, my file ends up four times the size of the original.

There has to be some standard method of creating a binary file from a
stream.

I've looked through the newsgroups and really haven't found anything
other than the method I'm doing.

Any help would be greatly appreciated.

Thanks...

[Jon Skeet [C# MVP]]

Scott, Killer of all Ninjas <dm****@hotmail .com> wrote:

It seems incredulous to me that it is so difficult to write the
contents of a memory stream to a file. I'm certain that I'm missing
something simple.

I am retrieving a memory stream from a DIME attachment:

MyDimeService svc = new MyDimeService() ;
svc.CreateDimed Image();
if (svc.ResponseSo apContext.Attac hments.Count == 1)
{
System.IO.Strea m dimeStream =
svc.ResponseSoa pContext.Attach ments[0].Stream;
SaveStreamToFil e(ref dimeStream);
}
Why are you passing the stream reference by reference?
In SaveStreamToFil e I'm simply attempting to write the stream to a
file similar to the way it's done in the MSDN help:

private void SaveStreamToFil e(ref System.IO.Strea m pStreamToSave)
{
System.IO.FileS tream fs = new
System.IO.FileS tream(@"c:\imag es\new\new.gif" ,
System.IO.FileM ode.Create);
System.IO.Binar yWriter bw = new System.IO.Binar yWriter(fs);

for (int i=0; i<=pStreamToSav e.Length; i++)
{
bw.Write(pStrea mToSave.ReadByt e());
}
bw.Close();
fs.Close();
}
Using a using block or two would be much better - and there's actually
no need for a BinaryWriter either.
Unfortunately, my file ends up four times the size of the original.
Yes - that's because you're calling BinaryWriter.Wr ite(int) for each
byte of the original.
There has to be some standard method of creating a binary file from a
stream.

I've looked through the newsgroups and really haven't found anything
other than the method I'm doing.

The simplest way is to read chunks of data and write them out. It's
also more efficient than the above, it'll get the right length, it
doesn't require the Length property of the stream (which you may have
in this case, but not in others, such as with network streams), and it
also still closes the file stream even if an exception is thrown.
Here's some sample code:

using (FileStream stream = new FileStream (filename, FileMode.Create ))
{
byte[] buffer = new byte[32768];
int chunkLength;

while((chunkLen gth=pStreamToSa ve.Read(buffer, 0,buffer.Length )) > 0)
{
stream.Write (buffer, 0, chunkLength);
}
}

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Scott, Killer of all Ninjas]

Excellent.

Simple, straight forward. I was able to find something similar to
this shortly after I left my message, but there was a lot more code
involved.

That being said, I started by passing a .gif file through (for easy
verification of the destination file), and in either case, after I
create the file from the attachment, it is no longer a valid gif file.

I have tried it with the chunk size you had, with a much smaller one
(256), with a REALLY small one (1) and the one directly from the DIME
attachment (pDimgeAttachme nt.ChunkSize). None of this made any
difference in the destination file.

The file sizes vary slightly:

Source File Info: 124,742 bytes actual, 126,976 bytes on disk
Destination File Info: 123,961 bytes actual, 126,976 bytes on disk

This is how it comes across regardless of the chunk size

Any ideas? Thanks.

my new function:

private string SaveAttachment(
DimeAttachment pDimgeAttachmen t)
{

string sFileName = @"c:\images\new \" +
pDimgeAttachmen t.Id.ToString() .Split(':')[1].ToString();

using (FileStream stream = new FileStream (sFileName,
FileMode.Create ))
{
byte[] buffer = new byte[pDimeAttachment .ChunkSize];
int chunkLength;

while((chunkLen gth = pDimgeAttachmen t.Stream.Read(b uffer, 0,
buffer.Length)) > 0)
stream.Write (buffer, 0, chunkLength);
}
return sFileName;
}
-
DM

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in message >

Using a using block or two would be much better - and there's actually
no need for a BinaryWriter either.

Unfortunately, my file ends up four times the size of the original.

Yes - that's because you're calling BinaryWriter.Wr ite(int) for each
byte of the original.

There has to be some standard method of creating a binary file from a
stream.

I've looked through the newsgroups and really haven't found anything
other than the method I'm doing.

The simplest way is to read chunks of data and write them out. It's
also more efficient than the above, it'll get the right length, it
doesn't require the Length property of the stream (which you may have
in this case, but not in others, such as with network streams), and it
also still closes the file stream even if an exception is thrown.
Here's some sample code:

using (FileStream stream = new FileStream (filename, FileMode.Create ))
{
byte[] buffer = new byte[32768];
int chunkLength;

while((chunkLen gth=pStreamToSa ve.Read(buffer, 0,buffer.Length )) > 0)
{
stream.Write (buffer, 0, chunkLength);
}
}

[Jon Skeet [C# MVP]]

Scott, Killer of all Ninjas <dm****@hotmail .com> wrote:

Excellent.

Simple, straight forward. I was able to find something similar to
this shortly after I left my message, but there was a lot more code
involved.

That being said, I started by passing a .gif file through (for easy
verification of the destination file), and in either case, after I
create the file from the attachment, it is no longer a valid gif file.

I have tried it with the chunk size you had, with a much smaller one
(256), with a REALLY small one (1) and the one directly from the DIME
attachment (pDimgeAttachme nt.ChunkSize). None of this made any
difference in the destination file.

The file sizes vary slightly:

Source File Info: 124,742 bytes actual, 126,976 bytes on disk
Destination File Info: 123,961 bytes actual, 126,976 bytes on disk

This is how it comes across regardless of the chunk size

Any ideas? Thanks.

Hmm... no immediate ideas come to mind. Are you sure that the DIME
attachment has been created correctly to start with? (I'm afraid I have
very little knowledge of DIME myself.)

If you have a look at the original and final files with a binary
editor, does anything obvious strike you in terms of where they differ?
For instance, is there a load of header information at the start or
anything like that?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Scott, Killer of all Ninjas]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in message news:<MP******* *************** **@msnews.micro soft.com>...

Hmm... no immediate ideas come to mind. Are you sure that the DIME
attachment has been created correctly to start with? (I'm afraid I have
very little knowledge of DIME myself.)

If you have a look at the original and final files with a binary
editor, does anything obvious strike you in terms of where they differ?
For instance, is there a load of header information at the start or
anything like that?

I looked at the two files and the "new" file is actually completely
missing the GIF89a header. I'm not sure what the problem with it is.

I've actually looked into using BITS (Background Intelligent Transfer
Service) to do the file transfer since DIME has been such a hassle,
but BITS seems even more complicated, and the client has to have BITS
1.5 installed in order to do uploads.

Anyone with DIME Attachment experience know why my attachment is
missing the first ~496 bytes?
-
dm