Weird behaviour with .NET constructor node and GZipStream compression

[Stinus Olsen]

Hi all

I am experiencing a weird error in a small piece of code, which by the way used to run fine without any problems.

My goal is to use a .NET MemoryStream object as a base stream for a .NET GZipStream object and decompress a GZip'd string input - simple and cheap.

Getting back to the project after a couple of months not working on it, I find the unzip VI to fail in decompressing any compressed data strings - that includes strings that I compress and copy-paste directly from the compression VI by hand..

The resulting error is the well known generic code 1172 error, with a description of: "Reading from the compression stream is not supported."

However - I can run the same code on a different computer, and the VI successfully decompresses the string without any hickups!

Looking at the constructor node of the GZipStream I see two checkmarks in the method selector - is this an error or is it caused by the prototype of the constructor methods to be the same?

Any ideas that can point me in the right direction on solving this is more than welcome..

I should mention that during the project's recent shelf time - I did install all .NET updates available through WIndows Update AND updated LabVIEW to 2013 SP1 (13.0.1f2 32-bit).

I run my dev environment in a virtual machine (vmware) but I don't think that's the cause of the error.

My OS is Windows 7 x64 on both the host as well as the guest..

BR and thanks in advance

Stinus Olsen

[mikeporter]

This is curious. The GZipStream class is supposed to exist in System.IO.Compression but all I find in there on my x64 Win7 machine are classes called ZipArchive.

But in any case, my gut reaction is if you can track down why you have the two check, you will fix your problem. Have you tried recreating the constructor?

Mike...

[tyk007]

---

@StinusO wrote:

Hi all

I am experiencing a weird error in a small piece of code, which by the way used to run fine without any problems.

My goal is to use a .NET MemoryStream object as a base stream for a .NET GZipStream object and decompress a GZip'd string input - simple and cheap.

Getting back to the project after a couple of months not working on it, I find the unzip VI to fail in decompressing any compressed data strings - that includes strings that I compress and copy-paste directly from the compression VI by hand..

The resulting error is the well known generic code 1172 error, with a description of: "Reading from the compression stream is not supported."

However - I can run the same code on a different computer, and the VI successfully decompresses the string without any hickups!

Looking at the constructor node of the GZipStream I see two checkmarks in the method selector - is this an error or is it caused by the prototype of the constructor methods to be the same?

Any ideas that can point me in the right direction on solving this is more than welcome..

I should mention that during the project's recent shelf time - I did install all .NET updates available through WIndows Update AND updated LabVIEW to 2013 SP1 (13.0.1f2 32-bit).

I run my dev environment in a virtual machine (vmware) but I don't think that's the cause of the error.

My OS is Windows 7 x64 on both the host as well as the guest..

BR and thanks in advance

Stinus Olsen

---

GZipStream does indeed exist in that namespace from Framework 2.0 onwards (http://msdn.microsoft.com/en-us/library/system.io.compression.gzipstream(v=vs.110).aspx).

The constructors you have shown is valid for .Net Framwork 4.5 (latest). LabVIEW 2013 also supports CLR 4.

However this is not true for .Net Framework 3.5 (http://msdn.microsoft.com/en-us/library/system.io.compression.gzipstream.gzipstream(v=vs.90).aspx). It only has two constructor overloads - the ones supporting CompressionLevel are missing. When you look at the MSDN page you can click on the version selector to see the difference.

It's hard to tell what happened. My guess is that LabVIEW got a little confused when the constructors changed (chances are your version of the .Net Framework in the VM got "upgraded" with Windows Updates to 4.5 which supports more overloads) even though it looks like you are using the one that existed in 3.5. LabVIEW often gets confused with .Net enums and probably tried updating to the first available overload that matched (since the enum is basically a number).

Try looking at the .Net assemblies in memory (under the View menu if I remember correctly) and see what CLR LabVIEW has loaded and what versions of System.dll (where the System.IO.Compression namespace is physically housed) are loaded on both of your computers. It's quite possible that your "working" computer is actually running 3.5 framework and is therefore not confused over which overload you actually wanted.

The suggestion to simply replace the constructor node with a new one will probably have sorted you though 

[Stinus Olsen]

Hi guys

Thanks a million for the replies - very appreciated!

 - and sorry for my late reply, I've been pretty busy doing another customer project simultaneously..

I tried to replace all and every one of the constructers in the code (only three actually) - but to no avail.

It seems there is something going wrong with LabVIEWs interpretation of the CLR 4.0 constructors!

Even if I launch LV fresh, create an empty VI and insert a new GZipStream constructor from the System.IO.Compression namespace, it gives me the one with the CompressionLevel input, even though I clearly select the CompressionMode one.

Trying to change it through the context menu dropdown box yields the same double-ticks as show in the previous picture.

I have been forced to disable my file compression strategy for the moment being and cannot afford to use much more time on this - but it bothers me BIG time to leave unsolved issues like this open - especially when I know that theres a pretty big chance its somehow related to the development environment on this particular machine.. *grrrr*  🙂

[ThiCop]

Hello StinusO,

Have you already tried this at your side?

https://decibel.ni.com/content/docs/DOC-7200

[Stinus Olsen]

Hi Thierry

Yes, I certainly did! - it was actually the first thing I did.

And that VI - the Decompress one - causes the exact same error, which lead me to the conclusion that the error was, and still is, local to my environment only.

It too shows the double tickmarks in the constructor node dropdown selector.

With that information gained however, my limited knowledge of the interaction between LabVIEW and .NET stops me from narrowing the error further down, hence my initial post here 🙂

(sorry for not pointing my trail of error tracking out in more detail before)

Have you got any ideas I could or should try out?

(apart from the obvious of reinstalling the VM - which aint going to happen!) 😄

[ThiCop]

Hello Stinus,

Can you share a screenshot of the .NET Assemblies in memory?

Please open one of the example VIs and go to "View > .NET Assemblies in Memory"

At my side I have the following ones (see attachment) in memory (and it runs without errors).

[tyk007]

An oddball question - check to see if you have a LabVIEW.exe.config file located in your LabVIEW folder in Program Files. If you do, delete it and re-start LabVIEW.

[Benjamin_C]

Hi Stinus,

I am running into the same issue. Did you find a fix?

Thanks in advance! 

[ThiCop]

Hello Benjamin,

Can you share which .NET Assemblies you have in memory? (via a sceenshot of the Window mentioned earlier on)