Weird behaviour with .NET constructor node and GZipStream compression

[Benjamin_C]

Hi Thierry,

Thanks for your reply. Please find attached the screenshot.

[Stinus Olsen]

Thierry, Benjamin

I have been very busy lately and completely forgot that I had to reply to this thread - sorry for that..

I did not find any solution to this issue and ended up disabling the compression of user data in the project alltogether!

@Thierry

I just chekked my own assemblies list and it looks exactly like Benjamins (as in 100% like his)..

ATB

Stinus

[ThiCop]

Hello Benjamin,

Thank you for this screenshot!

Can you also share the "extended list"?

With the extended list I mean the .NET assemblies you see when you uncheck the "Show only directly loaded assemblies".

Note that I am especially interested in the list you get after you hav opened your specific compression VI that uses the specific .NET Assembly.

Aside from this I also wanted to ask you if you are able to include the exact VI you are using at your side.

Can you also share with me the full error message you get (aside from the error code 1172)?

Which troubleshooting steps have already been performed from your side?

[Stinus Olsen]

Hi Thierry

I don't think it matters who is answering you - but in case Benjamin didn't send you anythin in a private message, please find my screen and code attached..

BR

Stinus

[Stinus Olsen]

Oh yeah - the full error message goes:

Invoke Node Error calling method System.IO.Compression.GZipStream.Read, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
    Inner Exception: System.InvalidOperationException: Reading from the compression stream is not supported.) <append><b>System.InvalidOperationException</b> in Get Whole GZipStream String.vi->Unzip GZipped String.vi

[ThiCop]

Hello Stinus,

Up to now I had not been succesful to reproduce it on my local pc.

But with my latest test today I was able to reproduce it on my local pc in NI LabVIEW 2013 SP1f4.

Tests earlier on in NI LabVIEW 2013 SP1 didn't allow me to reproduce it and I can currently not explain why the issues are now occuring at my side.

However, the same code in NI LabVIEW 2012 SP1 does work as expected and does not throw the error.

Everything (including the error message) seems to indicate that the error is sourcing from the "incorrect constructor" that does not set the compression mode correctly.

Can you tell me in which version you at latest succesfully could run the VI?

Was this in NI LabVIEW 2013 or in NI LabVIEW 2012?

PS: I will try to reproduce the issue on another (personal) test pc later on this evening.

[Benjamin_C]

Hi Thierry,

All my apologies for the late reply. I was so much busy this last days that I hardly looked at my mails.

Here is the screenshot that you asked for. This is what I have in memory when I open the VI shared by Stinus (I already have deleted my own VIs because I had to find a workaround to make it work for monday). As a workaround I had to build a C# DLL.

I can't tell you the exact message associated with the 1172 error code, but it was said that I couldn't have read access to the Gzip stream, obviously because the GZipStream object was created by default with in "Compress" mode.

I hope this can help you.

Regards.

[ThiCop]

Hello Benjamin and Stinus,

Sorry for not providing an update earlier on.

In the meanwhile I have been able to do some further tests this week-end.

If this is ok with you, then I would like to create an internal escalation concerning this?

I will use this Forum post as a public reference concerning this issue.

PS: As most contributors to this topic noted earlier on the issue seems to be in the constructor node.

Especially it seems like the additional constructor overloads in .NET Framework 4.5 (compared to version 4.0) cause the noticed/seen issues.

[Stinus Olsen]

By all means, fell free to do so..

I've kudoed you last post because I know how important it is to recognize and show appreciation of other peoples efforts, especially in our line of work!

I haven't marked it is solved (yet) as we still don´t know what the exact problem is - or even if it is a problem after all, and not just us doing stuff we shouldn't be doing..

Thank you for taking the time to look at this - thumbs up!  🙂

All the best

Stinus

[ThiCop]

Hello Stinus,

I was out of office (sick) yesterday, so my apologies for not getting back earlier.

I had started an internal escalation and based on the feedback I received a Corrective Action Request (CAR) will be filed.

I will keep you up to date about the Corrective Action Request number, so that you are able to track it later on.