Dekomprimieren mit GZipStream funktioniert im Debugger aber ohne Debugger nicht

Hallo,

ich möchte gzip-komprimierte Daten dekomprimieren, habe dabei aber einige merkwürdige Phänomäne bei folgendem Code:

byte[] cmpData = Convert.FromBase64String(cmpBase64String);
            
string outString = "";

using (MemoryStream decomStream = new MemoryStream(cmpData))
{
    using (GZipStream gzipStream = new GZipStream(decomStream, compressionMode.Decompress))
    {
        using (StreamReader sr = new StreamReader(gzipStream))
        {
            outString = sr.ReadToEnd();
        }
    }
}

Der outString ist leer. Wenn ich allerdings im Debug-Modus auf der StreamReader-Zuweisung stoppe und dabei in das gzipStream-Objekt hineinschaue, dann sehe ich dass er darin Daten hat. Gehe ich dann einen Schritt weiter, hat auch der StreamReader Daten und der outString wird gefüllt. Schaue ich beim Debuggen nicht in das Objekt, wird der outString bzw. der StreamReader nicht gefüllt.
Wer wüsste dafür eine Erklärung?

Gruß
Tilo

Hallo TiloS,

bist du dir sicher, dass es ohne Debugger nicht geht? Hast du also insbesondere direkt nach der Zuweisung an outString mal dessen Wert ausgegeben?

herbivore

Schaue ich beim Debuggen nicht in das Objekt

Das heißt du debuggst zwar, aber du lässt dir den Inhalt nicht anzeigen?
Dann machst du noch irgendwas mit den Streams falsch. Hast du dir ein Beispiel gesucht wie man das GZip handhabt? Möglicherweise fehlt noch ein Flush oder Close, das dann automatisch passiert sobald der Stream mit ToString() seinen Inhalt anzeigt.
Probier mal sowas aus.

Hallo,

danke für die Antworten.

Ich habe mal ein paar Screenshots zusammengefügt. Ich muss direkt vor dem auslesen in den StreamReader hineinschauen, ansonsten wird der outString nicht gefüllt, und und ist auch bei einer Ausgabe nicht gefüllt.

Ich vermute auch, dass es irgendwas mit der Handhabung des GZipStream ist, habe aber noch nicht herausgefunden was.

Gruß
Tilo

Ich weiß nicht wieso, ich habs auch nicht genauer angeschaut.....
Aber alle Beispiele, die ich so in Google kurzerhand finde, machen es mehr oder weniger einheitlich folgendermaßen:

public static string Decompress( string cmpBase64String )
{
    var byteArray = Convert.FromBase64String( cmpBase64String );
    System.Text.StringBuilder sB;

    using ( var sr = new System.IO.Compression.GZipStream( new System.IO.MemoryStream( byteArray ), System.IO.Compression.CompressionMode.Decompress ) )
    {
        // Reset
        byteArray = new byte[ byteArray.Length ];

        // Decompressing
        var rByte = sr.Read( byteArray, 0, byteArray.Length );

        // Transform to String
        sB = new System.Text.StringBuilder( rByte );

        for ( var i = 0 ; i < rByte ; i++ )
        {
            sB.Append( ( char ) byteArray[ i ] );
        }
    }

    return sB.ToString( );
}

Du könntest Dir mit den teilweise doppelten usings selbst in die Suppe spucken.
Würdest Du FxCop darüber laufen lassen, würde er es auch als kritisch markieren.

Hallo,

ich kann leider auch nicht sagen was da schief läuft, aber folgendes funktioniert einwandfrei (egal ob Debug oder nicht): (Compress/Uncompress Methoden entnommen von String compression using GZipStream)

[TestClass]
public class UnitTest1
{
	[TestMethod]
	public void Test_Success()
	{
		var s = Compress("Hello World");
		Assert.AreEqual("Hello World", Decompress(s));
	}

	public static byte[] Compress(string text)
	{
		using (var ms = new MemoryStream())
		{
			using (var zip = new GZipStream(ms, CompressionMode.Compress))
			using (var writer = new StreamWriter(zip))
				writer.Write(text);
			
			return ms.ToArray();
		}
	}

	public static string Decompress(byte[] compressed)
	{
		using (var ms = new MemoryStream(compressed))
		using (var zip = new GZipStream(ms, CompressionMode.Decompress))
		using (var sr = new StreamReader(zip))
		{
			return sr.ReadToEnd();
		}
	}

}

So jetzt hab ich's.

Es lag nicht an der Dekomprimierung, sondern an der Komprimierung. Dort wurden 2 Zeichen am Ende abgeschnitten und damit hatte die Dekomprimierung Schwierigkeiten. Dort stand der Reader beim ReadToEnd schon an der Endposition. Beim direkten nochmaligen ReadToEnd war der outString dann gefüllt.

Die Lösung war aber die Komprimierungsmethode anzupassen. Mit der von "Sarc" hat es dann funktioniert.

Danke.
Gruß
Tilo

Aber auch für Sarc's Snippet gilt: CA2202: Objekte nicht mehrmals verwerfen