Put things in one end and receive it from the other end in the same order

This would be a reasonable definition of a stream, and after all these years I still sometimes find myself falling into this mental trap for a moment. But that's not how Streams work in .NET.

Instead, think of an I/O driver: you can write to it, you can read from it, you can seek. Sometimes you can do only a subset of these things.

The implementation behind the Stream abstraction then interacts with a file, a network connection, or in the case of MemoryStream simply with a junk of ... well, Memory.

Usually it makes sense to mentally separate your Streams into read-streams and write-streams. Behind a read-stream is some functionality that allows you to read something from somewhere, while write streams allow you to write something somewhere. The real purpose of a Stream is to allow you not to think about what you're reading from or writing to.

Put things in one end and receive it from the other end in the same order

This would be a reasonable definition of a stream, and after all these years I still sometimes find myself falling into this mental trap for a moment. But that's not how Streams work in .NET.

Instead, think of an I/O driver: you can write to it, you can read from it, you can seek. Sometimes you can do only a subset of these things.

The implementation behind the Stream abstraction then interacts with a file, a network connection, or in the case of MemoryStream simply with a chunk of ... well, memory.

Usually it makes sense to mentally separate your Streams into read-streams and write-streams. Behind a read-stream is some functionality that allows you to read something from somewhere, while write streams allow you to write something somewhere. The real purpose of a Stream is to allow you not to think about what you're reading from or writing to.

Put things in one end and receive it from the other end in the same order

This would be a reasonable definition of a stream, and after all these years I still sometimes find myself falling into this mental trap for a moment. But that's not how Streams work in .NET.

Instead, think of an I/O driver: you can write to it, you can read from it, you can seek. Sometimes you can do only a subset of these things.

The implementation behind the Stream abstraction then interacts with a file, a network connection, or in the case of MemoryStream simply with a junk of ... well, Memory.

Usually it makes sense to mentally separate your Streams into read-streams and write-streams. Behind a read-stream is some functionality that allows you to read something from somewhere, while write streams allow you to write something somewhere. There real purpose of a Stream is to allow you not to think about what you're reading from or writing to.

Put things in one end and receive it from the other end in the same order

This would be a reasonable definition of a stream, and after all these years I still sometimes find myself falling into this mental trap for a moment. But that's not how Streams work in .NET.

Instead, think of an I/O driver: you can write to it, you can read from it, you can seek. Sometimes you can do only a subset of these things.

The implementation behind the Stream abstraction then interacts with a file, a network connection, or in the case of MemoryStream simply with a junk of ... well, Memory.

Usually it makes sense to mentally separate your Streams into read-streams and write-streams. Behind a read-stream is some functionality that allows you to read something from somewhere, while write streams allow you to write something somewhere. The real purpose of a Stream is to allow you not to think about what you're reading from or writing to.