nur der StreamWriter, der MemoryStream is ja unabhängig davon bzw. wird beim beenden des using-Blocks nicht berücksichtigt.

EDIT: ups, wohl bisschen falsch gelegen(siehe hier!) obwohls eigentlich nur logisch wäre...

referencesource.microsoft.com/…em/io/streamwriter.cs,236
Im Konstruktor wird stream entsprechend zugewiesen.

@Goldwing Studios Sieht nicht ganz so aus, da ​stream.Close im ​Dispose aufgerufen wird.

Grüße

@Trade mein Edit gesehen

@EaranMaleasi kein Ding

EaranMaleasi schrieb:

selbst testen.

Dies läuft:

Beachtet auch diese Konstruktor-Überladung des StreamWriters:

ObjectBrowser schrieb:

Public Sub New(stream As System.IO.Stream, encoding As System.Text.Encoding, bufferSize As Integer, leaveOpen As Boolean)
Member of System.IO.StreamWriter

insbesondere den letzten Parameter

@ErfinderDesRades auch bei using?

Mir ist das mit dem CryptoStream passiert. Ich habe da mit ILSpy nachgeschaut, was der CryptoStream beim Disposen macht, eine Klasse vom CryptoStream abgeleitet, Dispose überschrieben und das Verhalten nachgebaut (ohne halt den zugrundeliegenden Stream zu schließen). Das hat halt an manchen Stellen Reflection benötigt.

vlt für dich interessant die StreamContainer-Klasse aus TcpKommunikation + Networkstream

Die tut so, als sei sie ein Stream, aber passiert nix, wenn man die disposet. Solch kann man auch zwischenschalten, um den BaseStream offen zu halten.

Allerdings hab ich die Klasse inzwischen etwas weiter entwickelt.

Edit: Ups - überlesen!
jo, using und Disposen ist ja ein und dasselbe, ein using ist ja ein Try-Finally, und im Finally wird halt disposed

okay, @ErfinderDesRades überles meinen Post einfach...

Jepp - Statt Closen/Disposen (was intern dasselbe ist) kann man flushen, um die jeweiligen Puffer zu entleeren und wegzuschreiben. Flushen tut man die Streams, aber auch Writer haben oft einen Puffer, und können folglich auch flushen.
Aber nicht immer - Binary-Reader/-Writer zB scheint keinen Puffer zu haben. Der disposet auch nicht den Base-Stream.

Also die Geschichte ist schon iwie sinnvoll. Auch das BaseStreams mit-disposed werden (was ja der c++-Regel widerspricht: "zerstöre nur Objekte, die du auch erstellt hast") - hängt glaub mitte Pufferung zusammen:
Wenn etwa ein StreamReader einen Batzen Bytes gelesen hat, um daraus Textzeilen zu bilden, dann hat er immer mehr Bytes im Puffer, als er grade braucht - jedenfalls solange der BaseStream nicht EOF ist.
Wenn man den Reader also dispost, bevor sein BaseStream EOF ist, dann nimmt er logisch seinen Puffer-Rest mit ins Grab - er kann ihn ja nicht zurücktun in den Stream.
Folge ist, dass im Stream eine unbestimmbare Anzahl Bytes ausgelesen sind, aber nirgends verarbeitet. Wodurch ein Weiter-Lesen, etwa mit einem anderen Reader, ziemlich sinnlos wäre, denn da fehlt ja was am Anfang.

@ErfinderDesRades ist das dein Ernst?
oder hast du deine Brille verlegt?

3x überlesen/übersehen?

Goldwing Studios schrieb:

@ErfinderDesRades auch bei using?

Anscheinend hast du ein Problem mit deinen Augen.

jo, using und Disposen ist ja ein und dasselbe, ein using ist ja ein Try-Finally, und im Finally wird halt disposed

Also bevor du rum spamst lieber noch mal überprüfen ob man im Recht ist

wie mit @ErfinderDesRades besprochen, gehts um das "leaveopen"

is aber jetzt geklärt

EaranMaleasi schrieb:

Flush-Methode

und

RodFromGermany schrieb:

VB.NET-Quellcode

1. ms.Position = 0;