GZipStream.CompressString TypeLoadException under CF2

Aug 16, 2009 at 2:48 PM

Hi again,

When I use the GZipStream.CompressString under WM5/CF2 i got TypeLoadException.

I use the following code under regular enviroment and under CF.  The regular test pass succefully, the CF test gave me the TypeLoadException exception.

public bool CompressTest()
{
            bool bResult = false;
            try
            {
                string s1 = "abcde 12345 abcde 12345 abcde 12345 abcde 12345";
                //StringBuilder sb = new StringBuilder();
                //for (int i = 0; i < 200; i++)
                //    sb.Append(s1);
                //s1 = sb.ToString();
                byte[] ba = GZipStream.CompressString(s1);
                string s2 = GZipStream.UncompressString(ba);
                bResult = s1 == s2;
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message + "\nstack trace=\n"+ex.StackTrace);
            }
            return bResult;
        }
}

 

When I took the code of the CompressString from http://dotnetzip.codeplex.com/Thread/View.aspx?ThreadId=65306, i saw that the Exception raise on the constructor of GZipStream.

Did I miss something?

 

 

Coordinator
Aug 16, 2009 at 8:52 PM

Can you give me the stacktrace?

The last time someone reported an exception on WM5, it was within the GZipStream constructor, and it occurred because the install of WM5 did not have the iso-8859-1 code page built in.   You can read about that prior case.  Could that be possible in your case?

The full stacktrace would likely give us some input. 

 

Aug 17, 2009 at 10:54 AM

The stacktrace end with the call to the CompressTest(), no additional info.

I try to compress simple text. no special chars or compressed format. i'm not sure it the same case.

The problem is with the WM5/6 enviroment? (i'm using WM6, not WM5. my mistake ...). I'll try to test it on a CE5 device (it won't help me much, but maybe it can lead us to somewhere ...)

 

 

 

Coordinator
Aug 17, 2009 at 3:57 PM

right, well stacktraces normally DO end with the call you've just made.  The question is, what are the other methods on the stack? 

The problem I referenced was not related to special characters.   Read about it and you'll see.

You said you weren't sure that it was the same case. Neither am I; the stacktrace would probably tell us.