I assume your're not always reading and writing to memory-streams.

That's just plain horrible, it only works on streams with known length,
and it isn't ensured to read the entire in-stream (in the general case
streams may not return as much data as asked for, even it is available).

I still don't understand these memory-streams..., do you really *need* a
memory-copy of the content of inStream?

This is quite a lot better. I prefer a do...while loop though.

You *should* read in a loop, since Read may not return the entire
content of the stream.

Here is how I usually do it:

using System.IO;
class StreamUtil
{
 public static void CopyStream(
   Stream input, Stream output,
   byte[] buffer, int offset, int count)
 {
   int read;
   do
   {
     read = input.Read(buffer, offset, count);
     if ( read > 0 )
       output.Write(buffer, offset, read);
   } while ( read > 0 );
 }
 public static void CopyStream(Stream input, Stream output, byte[] buffer)
 { CopyStream(input, output, buffer, 0, buffer.Length); }
 public static void CopyStream(Stream input, Stream output, int bufferSize)
 { CopyStream(input, output, new byte[bufferSize]); }
 public static void CopyStream(Stream input, Stream output)
 { CopyStream(input, output, 8*1024); }
 // ... more utils here
}
class Foo
{
 void DoingStuff() {
   // ...
   Stream input; // from somewhere
   Stream output; // from somewhere
   StreamUtil.CopyStream(input, output);
   // ...
 }
}

IMO you should use a loop. While it may not be needed when working
exclusively with MemoryStreams, it could be necessary for other type
of Streams.

That doesn't mean you have to read 2K at the time though. If the input
stream has a known length you can directly create a byte[] of the
correct size and keep reading into that. You can then construct the
output stream around that byte array with the MemoryStream(byte[])
constructor to avoid making a third copy of the data.

Mattias

One thing that has yet to be mentioned as a reason why its better to use the
looping methodology is large objects ...

if you use the simple read/write methodology you end up with a byte array
the size of the data being created. If this byte size is over a certain
limit (I forget what the exact number is off the top of my head but want to
say 85k ??? someone feel free to correct me) it is treated as a large object
and put on a special heap. Large objects have differing life cycles and are
not garbage collected in the same way as normal objects .. this can lead to
a possible memory usage attack by someone forcing this operation to happen
repeatedly ... I have never tried to take an app down in this way but I
would imagine that it is feasible.

Cheers,

Greg Young